Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Best practice for mutually dependent classes

Status
Not open for further replies.

Griffyn

Programmer
Jul 11, 2002
1,077
AU
Hi all,

I have a two base classes that need to refer to each other in their interface: TMachine and TWidget. TMachine maintains (amongst lots of other properties) a list of TWidget objects, and each TWidget descendent has methods that make a slew of modifications to the properties in it's owning TMachine object. There are hundreds of TMachine descendent classes, and hundreds of TWidget descendent classes.

Code:
[b]unit[/b] uMachine;

[b]interface[/b]

[b]uses[/b]
  uWidget;

[b]type[/b]
  TMachine = [b]class[/b]
  [b]private[/b]
    FWidgets: TWidgetList;
  [b]public[/b]
    [navy][i]// ... snip lots of properties ...
[/i][/navy]    [b]property[/b] Widgets: TWidgetList [b]read[/b] FWidgets;
  [b]end[/b];
Code:
[b]unit[/b] uWidget;

[b]interface[/b]

[b]uses[/b]
  uMachine;

[b]type[/b]
  TWidget = [b]class[/b]
  [b]private[/b]
    FOwner: TMachine;
  [b]public[/b]
    [navy][i]// ... snip lots of abstract methods ...
[/i][/navy]    [b]property[/b] Owner: TMachine [b]read[/b] FOwner;
  [b]end[/b];

How should I best structure this?

I initially went about putting all of the TMachine classes into unit uMachine, and all the TWidget classes into unit uWidget, but that creates a circular unit reference. Each Machine has to know about it's widgets, and each widget needs to know about it's owning machine.

The easy fix would be to combine TMachine and TWidget into one massive unit that would end up being around 20,000 lines of code. I would prefer not.

Another easy fix would be to use typecasting, so that each TWidget only knows that it's owner is a TObject, and not a TMachine. Because the typecasting is all handled in the implementation section, there's no circular unit reference. This is what I'm leaning towards, but again, I would prefer not.

What other options are there that I haven't thought of?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top