Factory creation - when to destroy?

[Matt B]

Subject is probably poorly worded, but bear with me as I describe the
situation that has me puzzled.

I create "Save" objects from a Save "factory" class. Many different
windows access this method to get their save object. I do this
because I am interested from the save factory when any of the many
windows uses that save object. I keep these save objects in a list in
the factory class that is iterated through when any one of them
saves.

My problem is that now, I need to know when it will no longer be used
by the window that requested the save object (the window is closed,
for example), so that I can remove it from the list and destroy it.

The only thing I could come up with is that in each window, on
closing, I would call a method on that save object that would let the
factory class know that I am done with it. But that seems like a bad
idea. I'm really not sure how else to make this happen. Is this just
poor design?

 

[Nicholas Paldino [.NET/C# MVP]]

Matt,

I personally don't think so. You are basically subscribing with the
call to the factory class, and when you are done, you need to unsubscribe.
A method here which does that seems reasonable in this case.

If you are sharing the instances between windows, then you will need to
reference count the objects as you hand them out to different windows (so
that when a window calls to unsubscribe, it doesn't wipe out the object that
another window is using, or at least, invalidate it in relation to your
factory).

 

[Peter Duniho]

[...]
My problem is that now, I need to know when it will no longer be used
by the window that requested the save object (the window is closed,
for example), so that I can remove it from the list and destroy it.

The only thing I could come up with is that in each window, on
closing, I would call a method on that save object that would let the
factory class know that I am done with it. But that seems like a bad
idea. I'm really not sure how else to make this happen. Is this just
poor design?

Not necessarily, I think.

How tied to the window (I assume by "window" you mean an instance of a
Form-based class) is the save object? Is it really specific exactly to
the window? If so, when you instantiate the save object, do you
actually have a reference to the window instance?

If all of those answers are "yes", then it seems to me it would be
reasonable for the factory or save object to subscribe a method to the
window's FormClosed event. When that event is raised, you would then
have the factory discard the save object.

If the instances are not so closely tied to each other, then yes...it
would probably be a bad idea to have them refer to each other that way.

So, it depends. But I don't see anything that clearly argues against
something like that.

Pete

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Subject is probably poorly worded, but bear with me as I describe the
situation that has me puzzled.

I create "Save" objects from a Save "factory" class. Many different
windows access this method to get their save object. I do this
because I am interested from the save factory when any of the many
windows uses that save object. I keep these save objects in a list in
the factory class that is iterated through when any one of them
saves.

My problem is that now, I need to know when it will no longer be used
by the window that requested the save object (the window is closed,
for example), so that I can remove it from the list and destroy it.

The only thing I could come up with is that in each window, on
closing, I would call a method on that save object that would let the
factory class know that I am done with it. But that seems like a bad
idea. I'm really not sure how else to make this happen. Is this just
poor design?

You can use the IDisposable interface when you want to control the life
time of an object. This is usually used when the life time of an object
needs to be controlled because it uses unmanaged resources, but usage
isn't limited to that.

As your object doesn't contain any unmanaged resources, you don't need a
Finalizer, which is often used when implementing IDisposable. As you
keep a list of the objects, they would never be finalised anyway.

Using IDisposable is the same thing that you are talking about, only you
call the method Dispose, and make the class inherit IDisposable.

One advantage is that you can use a using block to create and dispose
the class:

using (Save save = Save.Create()) {
... use the save object
}

This will automatically call the Dispose method at the end of the block.