Where do you place your unit uses?
Over the years, I’ve come to preferring to place my uses in the Interface section only, even if its types, constants or methods only are used in the implementation section.
What is your practice, and why do you prefer one pattern over the others – or why would you recommend against one of these patterns?
unit Test;
interface
uses
ThisUnit, ThatUnit;
implementation
end.
vs
unit Test;
interface
uses
ThisUnit;
implementation
uses
ThatUnit;
end.
AS. I think units and even in a sense packages are obsolete TP4 remnants. They should have been unified with objects long ago, and ‘uses’ and ‘with’ too.
Implementation section is analogue of private object section. It is said when introducing new members one should start with private only uplifting them when absolutely necessary. So preventing classes from becoming intertwined and intimately coupled.
Working with a legacy app, which is IfDef-ridden spaghetti, with same units compiled into different EXEs and DLLs in different subsets, i was taught to appreciate this approach, hard way. Circular references through types and thus units too are so many and deep, there can be no reasonable graph outlined. Splitting logically related functions into many sparcely located units just because “these routines can be compiled into this isolated BPL” does not feel right, but at least is something.
So, yes, keep as much as you can private(implementation only), as long as you can. For the sake of compatibility and adaptability by loose coupling. And screw DPKs that still so many years later do not have private units!
I am also preferring the second option, as I am with Michael Thuma regarding circular references, too. One major reason for this option in my case: I can see immediately when I can stay in the implementation part when eliminating references or change implementations, while a unit in the interface section signals “You have to change the interface part to get rid of it! This will most likely affect other units, too!”
Arioch The Actually, using interface uses section prevents you from having circular references. Implementation section is the one that allows circularity.
Just a note: I use the Uses Report in Peganza Pascal Analyzer to identify the candidates for moving to the interface section. The task itself is easily done with Ctrl-Alt-Shift-Up (or Down) from MMX Code Explorer, which moves the unit under the cursor to the other section.
b) of course. To prevent unwanted dependencies between units in the Interface section that someone can accidentally make. If two units have interlinks in the Interface section, it makes sense to think about re-organizing of the code in an application, maybe to merge these units into one. Or to extract the interlinked part to a separate unit.
I put Delphi’s units in the Interface part because they will never use my own code.
for my own units I put them at the lowest level as possible to avoid circular references
sometimes, I use a class helper in the implementation part to transtype a member to a specific type instead of placing the unit in the interface part (once again to avoid circular reference)
unit Unit1;
type
TForm1 = class(TForm1)
procedure Button1Click(Sender: TObject);
private
FSomeThing: TObject;
end;
implementation
uses
Unit.Something;
type
TForm1Helper = class helper for TForm1
function SomeThing: TSomething; inline;
end;
function TForm1Helper.Something: TSomething;
begin
Result := TSomething(FSomething);
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
ShowMessage(Something.Value);
end;
you can use this to acces to the MainForm from a Frame with TMainForm(Owner) for instance.
The other option is to add Interfaces
My reason for putting everything in the interface section is that it is, as Dalija Prasnikar points out, the only way to effectively enforce prevention of circular references.
Lars Fosdal I wish the VCL sources would have followed this scheme right from the beginning. The circular references in there are just horrible.
Paul TOTH “I put Delphi’s units in the Interface part because they will never use my own code.”
Actually you can put them in the Implementation part and they will not use your code too. )
T n T yes, but they can not be any circular reference at all and I can see the immediat depency (VCL/FMX/RTL/Winapi) of my code at one place.
Paul TOTH It’s a different argument. But instead of introducing dependencies into the interface section, we can use GExperts to easily see the used units. Also I’d suggest Thomas Mueller to highlight interlinked units in the lists in the Uses Clause Manager, may be with bold font.
One more argument against dependencies in the Interface section: when typing in this section, IDE will not display unnecessary autosuggestions (Ctrl-Space), which will also reduce the chance of accidental errors.
I prefer using interface section for all. This way it is easier for me to see what all dependencies are. For my own code this also prevents me from making accidental circular references which usually point to bad design.
I use implementation section (very rarely) only and only if I have some circular dependencies where getting rid of them would be more trouble than it is worth.
Dalija Prasnikar i was talking about circular references in data types and classes, as they hurt me the most
Michael Thuma packages contain units, unit contain types and routines. Both can be seen as namespaces/classes. FPC even has unit global properties.
From the perspective public contract vs internal implementation details it seems the same
Arioch The Yes, I figured that out. But using implementation section for uses clause can drive you toward such intertwined classes, while using interface section can actively help you to prevent some of those.
Unless, you are talking about declaring types in implementation section which is completely different topic.
I use the interface section mainly.
This is to ensure that all units which my code depends on have been initialized before my own initialization section runs.
By the way I highly recommend this brilliant expert:
github.com – rfrezino/RFindUnit
Lars Fosdal Circular references are best avoided by good design. With SOLID development circular unit references should be an extremely rare possibility anyway.
One other reason for putting units in the implementation section uses clause are that all the ones under your control are in one place for you to manage. The Interface uses clause suffers from Delphi injecting units. Of course sometimes classes are needed in the Interface method declarations leaving you no choice.
Larry Hengen Wouldn’t it be great if we could declare a class in the interface section with only the public and protected members and add the private stuff in an extended declaration in the implementation part?
Uwe Raabe It’s an interesting suggestion…kind if a different take on partial classes. Not sure if that would make it more difficult to understand the class as a whole. Personally I am not the biggest fan of partial classes and extension methods as relevant code in multiple places makes maintenance harder IMHO.
The units in the Interface section are mainly required to satisfy types referenced in the Interface section. I do my best to put units that aren’t required there in the Implementation section.
I have seen libraries that have minimal units specified in either one, and not even units in the project. Instead, they rely on search paths being set up properly to load up everything implicitly. I do not like this approach at all.
Implementation when it makes sense, not when it is simply possible (this choice is not available, I cannot vote).
Larry Hengen True that, but not all devs even know what SOLID means. Then you have to find other ways.
Is there an option for “I wish there weren’t separate interface/implementation sections”?
Joseph Mitzen You cannot have that 🙂
Joseph Mitzen {$INCLUDE xxx} like #include in C
Larry Hengen delphi form designer injects unit ( messing with order and grouping ) in units with, ahem, forms and datamodules.
There is an opinion, along MVC, that forms should be ends of the design, with all the data classes snd types be in non-visual units. Not that i succeed in this approach myself. But then the units where Delphi does mess would be of little relevance structure-wise and being end leafs would be free from circular dependencies anyway
Joseph Mitzen I think the compiler (with enough smarts) could automatically handle not having two sections, or, alternatively, be able to suggest were what might belong (probably requiring yet another keyword).
Is that like header includes?
I tend to place all uses in the interface section, but some references have to be defined in implementation to avoid circular – which is just the way things are. It would probably be a good feature to remove that old concept, because the parser knows everything after the first pass anyways – so its just an old rule lingering – it havent had any real value after object pascal stopped having a C backend (read: an eternity ago).
If the resource is only used as part of the implementation, I put the uses in the implementation. If it is required as part of the interface definition, I include the unit there. I think its probably from the days when I used Modula-2 with its separate definition and implementation modules. As an aside, I loved Modula-2 at the time I first started using it.
I prefere to place the unit where it is required. A part of hidding the implementation if you prefer. By choosing carefully the scope it’s easier to track down used units and replacing them without harming the code. In fact I try to avoid placing unit in the interface. I like my units as:
unit MyTest;
interface
Type
TMyClass = Class
end;
implementation
uses Sysutils;
{… some code requiring sysutis ..}
This way I know exactly what is required to “interface” with that class.
Mike Versteeg As John Lennon once coded….
Imagine there’s no interface section
It’s easy if you try
No implementation section below it
But it would still be Delphi
Imagine all the people
Not telling unit users what they can’t do….
Imagine there’s no initialization section
It isn’t hard to do
Sections come from COBOL
Circa 1962
Imagine all the people
using units with nothing to hide….
You may say I’m a dreamer
But I’m not the only one
They hide nothing in Python
and IEEE Spectrum ranks it number one
Imagine not using properties
For every dang integer and real
If you’re not assigning methods
I don’t get it; what’s the deal?
Imagine all the people
Embracing YAGNI….
You may say I’m a dreamer
But I’m not the only one
I hope someday we’ll see
A Delphi compiler with passes more than one
Imagine no hidden classes
I know marc hoffman thinks that’s heresy
He must have added 17 class modifers to Oxygene
Including “Not_Even_Howard_Carter_Could_Unseal_Me”
Imagine RemObjects
Letting all the classes be free…
Imagine class methods
Not being separated from their definition
You may think separation is better
I think that’s just superstition
Imagine knowing how a class works
Without hitting page-down, page-down, page-down….
You may say I’m a dreamer
But I’m not the only one any more
marc hoffman made this possible
In Oxygene 8.4….
If a unit exports nothing that could be required in interface sections of other units I would prefer to always use the unit in implementation sections. If a unit exports something that could be required in interface sections of other units (types, constants) I would prefer to always use the unit in interface sections.
And I never write circular dependent units.
Sergey Kasandrov How do you know that you don’t do it by accident?
Lars Fosdal Use a proper static analysis tool on a regular basis. The Unit Dependency Analyzer as part of MMX Code Explorer can tell you that pretty fast.
Uwe Raabe Wouldn’t it be nice if tools like this were built in.
Lars Fosdal Like any bug – fix it when you find it.
Lars Fosdal Basically, yes. On the other hand, if I recall what has happened to a couple of other addons acquired and then orphaned, I am pretty fine with the current situation.
Haven’t really thought about this much but I tend to veer towards reduction of exposure among units so as far as possibe, I go for implementation section.