I've been trying to think of the right way to design relationships
between objects with different desired lifetimes that raise events.
If an event source is a relatively permanent object and the event sink
is on an object that can come and go, what is the proper way to deal
with adding and removing the handler to the event list? Should the
event sink make sure to remove itself from the source's event list
before all other references to it are released? My problem is
determining a good way to disconnect the event sink from the event
source at an appropriate time. When some parent object creates a
child object, and the child object connects to an event source, then
the parent releases the child object, the only remaining reference to
the child object is the event source. So it stays alive (I'm
guessing) but will never get used again. What's the right way to get
rid of it? "Dispose" doesn't seem like the right answer because
that's supposed to be for un-managed resources and there's nothing
un-managed about this. Do I need to add a "Disconnect" method to
every child object that finds itself in this situation and explicitly
disconnect the child objects before I set the reference to null.
Should I make some sort of custom event delegate that uses a weak
reference so that the child object can die even though there is an
event handler connected to it?
Perhaps this is better explained with a specific example. I have a
wrapper class that pulls together a Direct3D Device and a collection
of textures and manages them as a unit. I have another class
"FrameCache" that manages a collection of "frames". A frame consists
of a reference to a texture, an index into the texture representing
cell from within it, and a matrix defining how that texture's cell is
drawn transformed on the screen. The frame cache is somewhat
temporary and there can be many frame caches connected to the same
display. There can also be many frame caches and many frames within a
cache that are connected to the same texture object. I'm thinking
that the frame cache will want to connect to the diplay device's reset
event so that it can force a re-load of the textures referenced by its
frames at that time. Why would the frame cache do this and not the
display you ask? Because only textures that are needed by some active
frame cache should be reloaded.
This is not the only example. I have event sinks all over my
application that are removing themselves from event sources' lists as
they are disposed because they have a shorter lifetime than the event
source. This is just the first time I've run into a case where I'm
not even dealing with a disposable object and I don't think I should
be. I'm thinking there must be another right answer.
So to summarize the questions involved:
1. Does a delegate / event source keep its "target" object alive (the
object that is the "container" of an event handler) even when there
are no other references to that target object? (I assume the answer to
this is yes)
2. In cases where the container/target object is referenced *only* by
such an event source, what is a good way to clean-up (good design),
assuming that the lifetime of the source is significantly longer than
that of the sink/target?
