Where do you place your unit uses?

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.

40 thoughts on “Where do you place your unit uses?


  1. 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!

    Like


  2. 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!”

    Like


  3. 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.

    Like


  4. 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.

    Like


  5. 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

    Like


  6. 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.

    Like


  7. 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. )

    Like


  8. 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.

    Like


  9. 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.

    Like


  10. 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

    Like


  11. 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.

    Like


  12. 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.

    Like


  13. 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?

    Like


  14. 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.

    Like


  15. 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.

    Like


  16. 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

    Like


  17. 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).

    Like


  18. 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).

    Like


  19. 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.

    Like


  20. 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.

    Like


  21. 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….

    Like


  22. 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.

    Like


  23. 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.

    Like

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.