> My honest answer would be to suggest that you shouldn't write code like
> that :-) You don't want to create such dependencys between your classes
> -- it makes reuse too tricky.
>
> What's your real-world example? Perhaps we can think of a more elegant
> solution to the problem.
Circular references are a means of tightly binding structure into your classes.
This structure can usually be implemented at a higher level than the data.
EG
// IN ONE UNIT
TCollection
property Items[Index :Integer]:TCollectionItem;
end;
TCollectionItem
property Collection :TCollection;
end;
// In another unit
TMyCollectableItem = class(TCollectionItem)
property MyDataField :String;
end;
Implementing Collections would have been considerably more limited were it not for
taking all advantage of tight binding at this level and polymorphism to allow
diversity.
NB: We do this a lot and most design patterns require strategies... Forms can be done
this way too in D4 - binding a data object to the dialog in the same unit and then
inheriting
from that dialog and data object has saved considerable development through code
reuse
and adding new controls and interface code to the parent form is a snap with
judicious use
of alignment/anchor properties to prevent any messing up of child forms... ;)
On the above mention of form inheritance... Always have *ALL* child forms open when you
make changes to the parent - delphi doesn't go looking for them in your project so the
DFM
files can get out of sync... a minor danger given the benefits...
--
Aaron Scott-Boddendijk
Jump Productions
(07) 838-3371 Voice
(07) 838-3372 Fax
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
