getting around circular references in Delphi

Question

Is there a way of getting around circular unit references in Delphi?

Maybe a newer version of delphi or some magic hack or something?

My delphi project has 100 000+ lines of code mostly based on singleton classes. I need to refactor this, but that would mean several months of "circular reference" hell :)

Answer 1

I've been maintaining close to a million lines of legacy code for the past 10 years so I understand your pain!

In the code that I maintain, when I've encountered circular uses, I frequently have found that they are caused by constants or type definitions in unit A that are needed by unit B. (Sometimes it's also a small bit of code (or even, global variables) in Unit A that is also needed by unit B.

In this situation (when I'm lucky!) I can carefully extract those parts of the code into a new unit C that contains the constants, type definitions, and shared code. Then units A and B use unit C.

I post the above with some hesitance because I'm not an expert on software design and realize there are many others here who are far more knowledgeable than I am. Hopefully, though, my experience will be of some use to you.

Answer 2

1. It seems you have quite serious code design issues. Besides many signs of such issues, one is the circular unit reference. But as you said: you cannot refactor all the code.
2. Move all what is possible to the implementation section. They are allowed to have circular references.
   • To simplify this task you can use 3rd party tools. I would recommend Peganza Pascal Analyzer - it will suggest what you can move to the implementation section. And will give you many more hints to improve your code quality.

Answer 3

Use the implementation section uses whenever possible, and limit what's in the interface uses clause to what has to be visible in the interface declarations.

There is no "magic hack". Circular references would cause an endless loop for the compiler (unit A requires compiling unit B which requires compiling unit A which requires compiling unit B, etc.).

If you have a specific instance where you think you cannot avoid circular references, edit your post and provide the code; I'm sure someone here can help you figure out how to get it fixed.

Answer 4

There is many ways to avoid circular references.

1. Delegates. Way too often, an object will execute some code that should be done in an event instead than being done by the object itself. Whether it is because the programmer working on the project was too short on time(aren't we always?), didn't have enough experience/knowledge or was just lazy, some code like this eventually end up in applications. Real world exemple : TCPSocket component that directly update some visual component on the application's MainForm instead of having the main form register a "OnTCPActivity" procedure on the component.

2. Abstract Classes/Interfaces. Using either of them allow to remove a direct dependance between many units. An abstract class or an interface can be declared alone in its own unit, limiting dependancies to a maximum. Exemple: Our application has a debug form. It has uses on pretty much the whole application as it displays information from various area of the application. Even worse, every form that allows to show the debug form will also also end up requiring all the units from the debug form. A better approach would be to have a debug form which is essentially empty, but that has the capacity to register "DebugFrames".

   TDebugFrm.RegisterDebugFrame(Frame : TDebugFrame);

   That way, the TDebugFrm has no dependancies of its own (Except than on the TDebugFrame class). Any and all unit that requires to show the debug form can do so without risking to add too many dependancies either.

There are many other exemple... I bet it could fill a book of its own. Designing a clean class hierarchy in a time efficient fashion is pretty hard to do and it comes with experience. Knowing the tools available to achieve it and how to use them is the 1st step to achieve it. But to answer your question... There is no 1-size-fit-all answer to your question, it's always to be taken on a case by case basis.

Answer 5

Similar Question: Delphi Enterprise: how can I apply the Visitor Pattern without circular references?

The solution presented by Uwe Raabe uses interfaces to resolve the circular dependency.

Answer 6

I found a solution that doesn't need the use of Interfaces but may not resolve every issues of the circular reference.

I have two classes in two units: TMap and TTile.

TMap contains a map and display it using isometric tiles (TTile).

I wanted to have a pointer in TTile to point back on the map. Map is a class property of TTile.

Class Var FoMap: TObject;

Normaly, you will need to declare each corresponding unit in the other unit... and get the circular reference.

Here, how I get around it.

In TTile, I declare map to be a TObject and move Map unit in the Uses clause of the Implementation section.

That way I can use map but need to cast it each time to TMap to access its properties.

Can I do better? If I could use a getter function to type cast it. But I will need to move Uses Map in the Interface section.... So, back to square one.

In the Implementation section, I did declare a getter function that is not part of my class. A Simple function.

Implementation

Uses Map;

Function Map: TMap; Begin Result := TMap(TTile.Map); End;

Cool, I thought. Now, every time I need to call a property of my Map, I just use Map.MyProperty.

Ouch! Did compile! :) Did not work the expected way. The compiler use the Map property of TTile and not my function.

So, I rename my function to aMap. But my Muse spoke to me. NOOOOO! Rename the Class Property to aMap... Now I can use Map the way I intented it.

Map.Size; This call my little function, who typecast aMap as TMap;

Patrick Forest

Answer 7

Modelmaker Code Explorer has a really nice wizard for listing all the uses, including cycles.

It requires that your project compiles.

I agree with the other posters that it is a design issue.
You should carefully look at your design, and remove unused units.

At DelphiLive'09, I did a session titled Smarter code with Databases and data aware controls which contains quite few tips on good design (not limited to DB apps).

--jeroen

Answer 8

I gave a previous answer but after some thinking and scratching I found a better way to solve the circular reference problem. Here my first unit who need a pointer on an object TB define in unit B.

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, b, StdCtrls;

type

  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }

  public
    { Public declarations }
    FoB: TB;
  end;

var
  Form1: TForm1;



implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  FoB := TB.Create(Self);
  showmessage(FoB.owner.name);
end;

end.

Here the code of the Unit B where TB has a pointer on TForm1.

unit B;

interface

  Uses
    dialogs, Forms;

  type
    TForm1 = class(TForm);

    TB = class
     private
       FaOwner: TForm1;
     public
       constructor Create(aOwner: TForm);
       property owner: TForm1 read FaOwner;
    end;

implementation
  uses unit1;

  Constructor TB.create(aOwner: TForm);
  Begin
    FaOwner := TForm1(aOwner);

    FaOwner.Left := 500;
  End;//Constructor
end.

And here why it compiles. First Unit B declare the use of Unit1 in the implementation section. Resolving immediately the circular reference unit between Unit1 et Unit B.

But to allow Delphi to compile, I need to give him something to chew on the declaration of FaOwner: TForm1. So, I add stub class name TForm1 who match the declaration of TForm1 in Unit1. Next, when come the time to call the constructor, TForm1 is able to pass itself has the parameter. In the constructor code, I need to typecast the aOwner parameter to Unit1.TForm1. And voilà, FaOwner his set to point on my form.

Now, if the class TB need to use FaOwner internally, I don't need to typecast it every time to Unit1.TForm1 because both declaration are the same. Note that you could set the declaration of to constructor to

Constructor TB.create(aOwner: TForm1); but when TForm1 will call the constructor and pass itself has a parameter, you will need to typecast it has b.TForm1. Otherwise Delphi will throw an error telling that both TForm1 are not compatible. So each time you call the TB.constructor you will need to typecast to the appropriate TForm1. The first solution, using a common ancestor, his better. Write the typecast once and forget it.

After I posted it, I realized that I made a mistake telling that both TForm1 were identical. They are not Unit1.TForm1 has components and methods that are unknown to B.TForm1. Has long TB doesn't need to use them or just need to use the commonality given by TForm you're okay. If you need to call something particular to UNit1.TForm1 from TB, you will need to typecast it to Unit1.TForm1.

I try it and test it with Delphi 2010 and it compiled and worked.

Hope it will help and spare you some headache.