Design Question

[JT]

Hi,

I have designed my object hierarchy in the following way and I'm just
wondering if there is a better way to do this because I've encoutered a
blocker when it comes to disposing.

I have a generic class A which takes some parameters at construction.
I have static classes B & C each of which creates an instance of A and pass
in different parameters.

A is internal and sealed.
B & C are public and used by clients of my framework.

My problem is that I need to dispose of the instance of A inside B & C
because it creates some disposable objects. However since B & C are static I
can't implement IDisposable.

Have I designed my objects incorrectly or is there a solution for this. It
should be noted that B & C are long lived objects and will only be disposed
of when the application shuts down.

Thanks in advance for any suggestions.

 

[JT]

Well the problem is objects B & C contain references to A. These instances
of A need to be disposed of when B or C are no longer required. The condition
is known, it is when dispose is called on the class that uses B or C. However
given that B & C are static and therefore can't be IDisposable how do I call
dispose through to the instance of A they both hold?

I could have a static method called Dispose on B & C even though they are
not IDisposable and that in turn could call dispose on A.

I'm just wondering if that is the best way to do this or if the design could
change.

I'm not sure you need anymore information. I guess this would be a common
situation anywhere a static class holds references to instance members
(static of course)

e.g.

public static class C
{
private static A _instance;

public static void Initialise(string someParam)
{
if(_instance == null)
{
_instance = new A(someParam);
}
}

public static void DoSomething()
{
if(_instance != null)
{
_instance.DoSomething();
}
}

}

[...]
My problem is that I need to dispose of the instance of A inside B & C
because it creates some disposable objects. However since B & C are
static I
can't implement IDisposable.

Have I designed my objects incorrectly or is there a solution for this.
It
should be noted that B & C are long lived objects and will only be
disposed
of when the application shuts down.

There's not enough information in your post for anyone to say whether your
design is correct or not.

But as far as the actual question goes, I don't really understand what
you're asking. If you "need to dispose of the instance of A", then
presumably you have some specific condition that is met when you need to
do that. So, when that condition is met, just call Dispose() on the
instance of A.

If you don't have a well-defined, specific condition when you need to
dispose of the instance of A in each class B and C, then yes...you have a
fundamental problem with your design. Once you fix that, then you'll
easily be able to dispose of A at the right time.

Pete

 

[JT]

The reason I don't expose A directly is 2 fold, I only ever want one instance
of A to exist per process, you could say a singleton but a parameterised one
since B & C can both hold an instance albeit a different one.

Also A has quite a complicated interface and B & C simplify this and expose
a simple interface.

I did read somewhere though that you shouldn't have a method called dispose
unless you implement IDisposable.

Looks good enough. Another thing that come to mind would be to expose just A
as you seems to have your C Class just delegate operations to A so A could
perhaps be used directly ?

As someone else said earlier typically this is hard to answer as we have not
idea about why you designed things this way to start with...

But being able to have " close"," dispose"," unload" or whatever you called
your pseudo-dispose method looks already a good step wiht your current
design...

--
Patrice

Well the problem is objects B & C contain references to A. These
instances
of A need to be disposed of when B or C are no longer required. The
condition
is known, it is when dispose is called on the class that uses B or C.
However
given that B & C are static and therefore can't be IDisposable how do I
call
dispose through to the instance of A they both hold?

I could have a static method called Dispose on B & C even though they are
not IDisposable and that in turn could call dispose on A.

I'm just wondering if that is the best way to do this or if the design
could
change.

I'm not sure you need anymore information. I guess this would be a common
situation anywhere a static class holds references to instance members
(static of course)

e.g.

public static class C
{
private static A _instance;

public static void Initialise(string someParam)
{
if(_instance == null)
{
_instance = new A(someParam);
}
}

public static void DoSomething()
{
if(_instance != null)
{
_instance.DoSomething();
}
}

}

[...]
My problem is that I need to dispose of the instance of A inside B & C
because it creates some disposable objects. However since B & C are
static I
can't implement IDisposable.

Have I designed my objects incorrectly or is there a solution for this.
It
should be noted that B & C are long lived objects and will only be
disposed
of when the application shuts down.

There's not enough information in your post for anyone to say whether
your
design is correct or not.

But as far as the actual question goes, I don't really understand what
you're asking. If you "need to dispose of the instance of A", then
presumably you have some specific condition that is met when you need to
do that. So, when that condition is met, just call Dispose() on the
instance of A.

If you don't have a well-defined, specific condition when you need to
dispose of the instance of A in each class B and C, then yes...you have a
fundamental problem with your design. Once you fix that, then you'll
easily be able to dispose of A at the right time.

Pete

 

[JT]

Ok, thanks for your help guys.

I think I'll go ahead and delegate the dispose also.

p.s. I did think about designing an interface and returning this reference
to the client but there is also a little additional functionality in B & C
other than pure delegation.