OK, to some extent I have managed to answer my own question - but only
for the simplified example I gave, not for my actual code.
I can solve the example problem by using subclasses or interfaces. By
keeping some of the functions out of the base class, I can remove all
cyclic dependencies. This may or may not be good design, but I'd rather
not be forced to do this - it's an imperfect solution at best.
Unfortunately there is a different case where this solution cannot be
applied anyway.
In my real-world case I have a single global manager, for which I am
using a static object. Having more than one instance of this object
would be bad, so it has to be static. This class spawns sub-objects,
which must occasionally perform a callback to the static class - this
happens because the sub-objects are listening to timed events not
initiated by the static class.
Because the static class has to spawn these objects itself (they are
private members) and the objects have to call back to the static class,
the cyclic dependency cannot be removed. I can't use interfaces here,
because you can't pass a reference to a static object (it has no "this"
- even though it does exist in RAM, so maybe it _should_ have one).
The only solution I can think of for this is to make the container class
nonstatic, but wrap it inside a static interface (then maybe try to find
some way to make the object a singleton without making it static). In
theory, this is a pretty good solution, because it removes the
dependency on a static (global = bad) class, making the objects more
general purpose, but they _aren't_ general purpose objects, so in
reality its just adding bloat for no good reason.
Surely I'm not the first person to run into this problem? If anyone has
come up with some different ideas I'd really like to know.
- Robert
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
