Is there a way in Delphi of defining a class's methods across multiple files ? I have a form that's horrendously big (close to 100k lines) and I'd like to split it up.

Edit : Class helpers are not a good tool in this case because you won't be able to set methods from the helper class as event handlers, which means you'll have to make "forwarding" event handlers, adding a lot of complexity.

CodePudding user response：

What I have done in the past is to split my files as definition and implementations.

ClassA.PAS

unit ClassA;

type
//Class Definition

implementation

{$ ClassA.IMP}

It does not matter how many include files you have. As far as the compiler is concerned, it's just one long length of code. You can put each method in a different file if you wish. You can use any extension at all. I preferred to use IMP (not PAS) for the includes to deter junior programs from poking sticky fingers in.

When they look at the PAS file, they see the class definition, which is all they need for their task.

You can even nest include files, that is, call another include file from an include file. But that would get messy. I have used nested include files to structure compiler defines, company wide, application wide, etc. Where the application defines file would include the company defines.

CodePudding user response：

There is no way to directly achieve what you are asking for, other than breaking the form code up into a number of smaller include files (as suggested by Rohit's answer).

However, composing a form (or any other source file) in Delphi from a collection of include files will solve one problem whilst introducing many more, possibly far worse than the original problem.

All may not be lost, though it is difficult to suggest alternatives without knowing more about the form in question. But here are a couple of ideas...

Page/Tab Control "Re-Parenting"

If it is a form with a page/tab control with many tabs each of which with a large number of controls and code, then one alternative might be to break the individual tabs out into individual forms with the content dynamically re-parented into the main form as required (either on demand or as part of form initialisation).

This could be as simple as providing a Panel control in each "child" form and setting the Panel.Parent to the corresponding tab control sheet (the controls parented onto the panel will "go with it". Use alClient alignment on the panel and corresponding alignment or anchor settings on the controls to preserve "responsive" layout when the control parent panel is moved from the "design-time" form to the "run-time" tab control.

The event handling and other code related to those controls would continue to reside in the decomposed "child" forms.

Caveat: You don't mention if this is a VCL or FMX project. I have used the above approach successfully with very large VCL projects in the past, but I have no idea if FMX supports the approach.

Business Objects

If there is no obvious UI decomposition that is possible, but the form contains a large amount of business logic, then it may be possible to simply refactor the business logic out into a business object (or objects).

Limit the form code to dealing with user interaction and UI updates and move all of the non-UI code out into separate files.