[fpc-pascal] How to have smaller units

[Martin Frb]

On 28/11/2025 22:58, Amir via fpc-pascal wrote:
> Hi,
>
>  One of the main thing bothering me while developing projects in 
> Pascal is that my units are getting huge in size! The main reason is 
> that the nice property that the classes could access each other 
> private members if they are defined in the same unit motivates/forces 
> me to define a lot of classes in the same unit. Then, all the 
> functions/procedures implementation must go into the same unit. I know 
> I can use inc file but I do not like it! The other option is to use 
> "Cracker" pattern, in Delphi, which is fine but seems like a hack!
>
>   In C++, the concept of header files vs c++ files is helpful. In 
> Golang, one could implement the functions for a class in several 
> files, as long as they are in the same directory (namespace).
>
>   Wondering if there is a solution for this in Object-Pascal?

You don't need the entire classes in the same unit.

Introduce baseclasses, that have access to each others fields

TBarBase = class;

TFooBase = class
private
   function GetBarFieldSomeThing(ABar: TBarBase): TSomeType;
end;

TBarBase = class
private
   procedure DoBeforeGettingSomeThing; virtual; abstract;
   function GetFieldSomeThing: TSomeType;
// and vice versa
   function GetFooOtherStuff(AFoo: TFooBase);
end;

Those methods are just field accessors. They do not do any work.

If you need work to be done, then call an abstract method.
e.g. GetFieldSomeThing can call DoBeforeGettingSomeThing if the actual 
TBar class needs to do work.

Then TFoo and TBar can go into 2 separate units and don't need to know 
anything of each other.

----------------
That works, with twin (dual) relations. But it introduces limits.

The other option is that each class can have "interfaces/api-accessors" 
(class or interface),  and control to whom it gives them.

That is in the unit for TBar you also have TBarFooAPI (you can have many 
different ones).

TBarFooAPI has everything public that TFoo needs.
But it can only be created by TBar. So TBar can decide who get it. Then 
you only need one connection between the 2 classes, to exchange the 
access object.
TBarFooAPI is a token to access TBar.

To make sure only TBar can created it => create an abstract base.
Then have an implementation section sub-class that implements 
everything. Since it is implementation section, only TBar can see it, 
and create it. But the instance can be given away, and since the methods 
are all virtual/overrides, they can be accessed by knowing the public 
abstract base class.
(May also work with nested class declarations)