INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Jobs

Best practice for mutually dependent classes

Best practice for mutually dependent classes

(OP)
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

unit uMachine;

interface

uses
  uWidget;

type
  TMachine = class
  private
    FWidgets: TWidgetList;
  public
    // ... snip lots of properties ...
    property Widgets: TWidgetList read FWidgets;
  end; 

CODE

unit uWidget;

interface

uses
  uMachine;

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

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?

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Resources

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close