Statics and inheritance

[Andrew Ducker]

Let's say I have a root class called RootBusinessSer vice
and I then want to have 25 business service classes based off of it.

And each class has a property that's shared between all instances of it
- called 'State'. I therefore want all of them to have a static
property State.

However, I can't declare this static property in RootBusinessSer vice -
because if I do, the subclasses will all point to that single property.

So I have to declare it in each individual class. 25 times.

Not only that, but if I want it to come up in intellisense for all
subclasses of RootBusinessSer ver, I need to create a get/set in the
root, and override it in each subclass to point to the 'local' static
property.

Is this right, or am I missing a really easy way to have a static
property automatically exist in all subclasses of a given class?

Cheers,

Andy D

[Samuel R. Neff]

As long as you're accessing the data through an instance of a base
class and not through the base class itself, then one option is to use
a static dictionary in the base. Something along these lines..

class Base {
private static IDictionary _stuff = new Hashtable();
public object Stuff {
get {
return _stuff[this.GetType()];
}
set {
_stuff[this.GetType()] = value;
}
}

class A : Base {}
class B: Base {}

With this architecture, the base will declare a single property which
will get and set a value that is shared across instances of a
particular type.

HTH,

Sam

On 31 May 2005 05:29:55 -0700, "Andrew Ducker" <an****@ducker. org.uk>
wrote:

Let's say I have a root class called RootBusinessSer vice
and I then want to have 25 business service classes based off of it.

And each class has a property that's shared between all instances of it
- called 'State'. I therefore want all of them to have a static
property State.

However, I can't declare this static property in RootBusinessSer vice -
because if I do, the subclasses will all point to that single property.

So I have to declare it in each individual class. 25 times.

Not only that, but if I want it to come up in intellisense for all
subclasses of RootBusinessSer ver, I need to create a get/set in the
root, and override it in each subclass to point to the 'local' static
property.

Is this right, or am I missing a really easy way to have a static
property automatically exist in all subclasses of a given class?

Cheers,

Andy D

[Michael Voss]

Andrew Ducker wrote:

[...snip...]

And each class has a property that's shared between all instances of it
- called 'State'. I therefore want all of them to have a static
property State.

However, I can't declare this static property in RootBusinessSer vice -
because if I do, the subclasses will all point to that single property.

So I have to declare it in each individual class. 25 times.

Not only that, but if I want it to come up in intellisense for all
subclasses of RootBusinessSer ver, I need to create a get/set in the
root, and override it in each subclass to point to the 'local' static
property.

[...snip...]

That's why some other languages implement things like "class instances
variables" - class (static) variables being inherited by all subclasses, but
not with a shared content. Each subclass has its own value, and access
methods aren't necessary outside the base class.

The inventors of c# (and java, btw) "borrowed" a lot of things from other
languages, but "forgot to borrow" some very nice features of them.

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Well, if you declare it in Root then you are implying that ALL the derived
classes share the very same value.
If you happen to have the same escenario on each of the derived classes,
then you would have to do the same thing on each one, remember each of them
happen independely of the others.

Not very complicated to do in any case.

cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Andrew Ducker" <an****@ducker. org.uk> wrote in message
news:11******** **************@ g47g2000cwa.goo glegroups.com.. .

Let's say I have a root class called RootBusinessSer vice
and I then want to have 25 business service classes based off of it.

And each class has a property that's shared between all instances of it
- called 'State'. I therefore want all of them to have a static
property State.

However, I can't declare this static property in RootBusinessSer vice -
because if I do, the subclasses will all point to that single property.

So I have to declare it in each individual class. 25 times.

Not only that, but if I want it to come up in intellisense for all
subclasses of RootBusinessSer ver, I need to create a get/set in the
root, and override it in each subclass to point to the 'local' static
property.

Is this right, or am I missing a really easy way to have a static
property automatically exist in all subclasses of a given class?

Cheers,

Andy D

[Andrew Ducker]

You're a genius! I just ripped out code from 25 places and replaced it
with that code.
Well, actually I added in a null check, giving me this:

public BusinessCallSta te CurrentState
{
get
{
object possibleState = states[this.GetType()];
if (possibleState == null)
return BusinessCallSta te.Uncalled;
else
return (BusinessCallSt ate)possibleSta te;
}
set
{
states[this.GetType()] = value;
}
}

But generally speaking that was perfect!

Cheers,

Andy D

[Nick Malik [Microsoft]]

this raises an interesting design question.

With this scenario, every subclass of the base (direct or indirect) has
access to this dictionary object.
Have you achieved encapsulation?

From a pure design standpoint, haven't you coupled the base class to the
existence of each of its children (if not the active awareness of them)?

To be honest, I'm not sure. Please share your opinions.

The design suggested is effectively a non-thread-safe Singleton. (Note that
the Singleton pattern doesn't require that only one element exist. It
requires that the creation of the element be managed. The GoF book
specifically mentions the possibility of using the Singleton to manage a set
of objects, not just a single one.)

To reduce coupling in the design, I would suggest that you could have your
state managed by a StateManager object that implements this mechanism,
rather than by the base class itself. Also, see Jon Skeet's page on
Singletons.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Samuel R. Neff" <in**********@n ewsgroup.nospam > wrote in message
news:ju******** *************** *********@4ax.c om...

As long as you're accessing the data through an instance of a base
class and not through the base class itself, then one option is to use
a static dictionary in the base. Something along these lines..

class Base {
private static IDictionary _stuff = new Hashtable();
public object Stuff {
get {
return _stuff[this.GetType()];
}
set {
_stuff[this.GetType()] = value;
}
}

class A : Base {}
class B: Base {}

With this architecture, the base will declare a single property which
will get and set a value that is shared across instances of a
particular type.

HTH,

Sam

On 31 May 2005 05:29:55 -0700, "Andrew Ducker" <an****@ducker. org.uk>
wrote:

Let's say I have a root class called RootBusinessSer vice
and I then want to have 25 business service classes based off of it.

And each class has a property that's shared between all instances of it
- called 'State'. I therefore want all of them to have a static
property State.

However, I can't declare this static property in RootBusinessSer vice -
because if I do, the subclasses will all point to that single property.

So I have to declare it in each individual class. 25 times.

Not only that, but if I want it to come up in intellisense for all
subclasses of RootBusinessSer ver, I need to create a get/set in the
root, and override it in each subclass to point to the 'local' static
property.

Is this right, or am I missing a really easy way to have a static
property automatically exist in all subclasses of a given class?

Cheers,

Andy D

[Samuel R. Neff]

The dictionary itself is private to the base class, so the children
don't have access to it except for their specific value (as defined by
their type). In the example I just made it "object" but obviously it
could be anything. The base class can even enforce that it is a
specific state type.

The base class is not really coupled to the existence of child items
because the base class itself has it's own shared object based on its
own type. Any number of derived classes can be written and each will
have its own shared store.

The only real coupling issue I see is if a child class has its own
child class and they wish to share a static store--that is not
possible in this implementation. It is achievable, but is more
complicated and was not specifcied as a requirement in the original
question.

This is closer to a Flyweight than a Singleton. I'll have to go back
and re-read the GoF text on Singleton for managing multiple instances
because my understanding is that is the exact definition of a
Flyweight--also defined by GoF.

It's not thread safe but the original question was not related to
threading--it was how to achieve shared values across instances and
still have the member defined in the base class and inherited.
Thread-safety can be added and is not a core component of the question
or answer.

Thanks,

Sam
On Tue, 31 May 2005 09:57:45 -0700, "Nick Malik [Microsoft]"
<ni*******@hotm ail.nospam.com> wrote:

this raises an interesting design question.

With this scenario, every subclass of the base (direct or indirect) has
access to this dictionary object.
Have you achieved encapsulation?

From a pure design standpoint, haven't you coupled the base class to the
existence of each of its children (if not the active awareness of them)?

To be honest, I'm not sure. Please share your opinions.

The design suggested is effectively a non-thread-safe Singleton. (Note that
the Singleton pattern doesn't require that only one element exist. It
requires that the creation of the element be managed. The GoF book
specifically mentions the possibility of using the Singleton to manage a set
of objects, not just a single one.)

To reduce coupling in the design, I would suggest that you could have your
state managed by a StateManager object that implements this mechanism,
rather than by the base class itself. Also, see Jon Skeet's page on
Singletons.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik