At 6:34 PM +1000 8/22/01, Luke Wigley wrote:
>
>
>I agree with Mark. The difficulty for me is establishing effective lines of
>communication between the various objects that respect the principles that
>accessors tend to indicate sloppy encapsulation, and that 'mutual references
>are evil'.
>
>Leaving aside the 'mutual references' issue (which still confuses me),
I have heard this statement about 'mutual references being evil' many
times. But I say that there is nothing wrong with it, and in fact
it can be extremely desirable and useful. If you want two objects to
communicate with each other directly, the only way to do it is for
each to hold a reference to the other.
Here is a good example. Imagine a manager object X and an object
that it manages Y. In fact X instantiates Y. When X instantiates Y,
it passes the variable "me" as a parameter. The new object Y, takes
the value that was passed in for "me" from X and stores it in a
property variable, let's call the property variable, poParent
(property object Parent). When the "new" call returns, the newly
created object Y, passes back it's object reference to the parent X.
The X object can then save this reference away in a property
variable, let's call it poChild (property object Child). Given this
setup, whenver the parent object, X, wants to send a message to the
child object, it uses the property variable poChild. And whenever
the child object Y, wants to send a message to the parent object, X,
it uses its property variable poParent.
I have built many systems like this and there is no problem with
them. Typically, I have a situation where I have a single manager
object, like X above, and I create multiple child objects like Y. In
that case, instead of the manager object having a single property
like poChild, it maintains a list of object references like ploChild
(property which is a list of object references).
The only trick is that when the time comes to get rid of object X, it
must pass on the message to any and all of its created child objects
that they are about to be destroyed. They must clear out their
reference to the parent object (set poParent = VOID) before they are
eliminated. Then the parent object must clear out references to any
and all of its children before it is destroyed.
Here's some skeleton code (off the top of my head):
-- X (Manager object)
property ploChild
on new me
ploChild = []
return me
end
on mCreateNewChild me
oNewChild = new(script "Y", me)
append(ploChild, oNewChild)
end
-- generalized method called when we're about to die
on mCleanUp me
nChildren = count(ploChild)
repeat with i = 1 to nChildren
oChild = ploChild[i]
oChild.mCleanUp() -- give each child a chance to clean itself up
ploChild[i] = void
end repeat
end
-- Y (Child object
property poParent
on new me, oParent
poParent = oParent
return me
end
on mCleanUp me
poParent = VOID
-- if this object had created any other objects, it would pass the
mCleanUp message on here.
end
For more information this, see my book at: http://www.furrypants.com/loope
Hope this helps.
Irv
--
Lingo / Director / Shockwave development for all occasions.
(Home-made Lingo cooked up fresh every day just for you.)
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
