Hiding inherited classes

[Dan]

I have a need to make a set of classes that all share the same public
methods, some implementation and some data. So, I made an abstract
base (BaseClass) with an interface (IBaseClass) and a handful of
inherited classes. The static method calls the ctor of the appropriate
inherited class and returns it as type IBaseClass. There are no new
methods or properties in the inherited classes and public clients never
need to know which inherited class they have. From reading some posts
on this board I think I may have gone the wrong way here. Maybe I
should make BaseClass not abstract and plug in classes representing
different implementations. The code would not be all that different
(rearrange some stuff) because the plug-ins would be mostly the same as
the inherited members now. So, I'm curious if there are any design
gurus who would like share an opinion on this.

Current Design (drastically simplified)

interface IBaseClass
{
void DoStuff();
}

public abstract BaseClass : IBaseClass
{
static IBaseClass MakeIBaseClass(string behaviorInfo)
{
switch (behaviorInfo)
{
case "A":
return new InhA() as IBaseClass;
break;
case "B":
return new InhB() as IBaseClass;
break;
}
public void DoStuff()
{
//Do common stuff
_DoStuff()
}
protected abstract void _DoStuff()
}

And to keep this from going on forever, I'm sure you can see the
inherited classes (InhA, InhB, etc.) would have their own
implementations of _DoStuff. They also override some public base
properties, hold some of their own data and have different ctors.

Should I go to a plug-in (I guess delegation/containment) design over
this? Any advice would be greatly appreciated.

TIA,
Dan

 

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

Dan,

I have this exact problem, which I believe to be a slight shortcoming in
the language. I don't like the idea of exposing public methods either when
I am implementing an interface, and I have tried to use the same pattern
that you are trying to use now.

There are only two ways to get around it. The first is what you are
doing, having the interface implementation call a protected virtual method
which is overriden by the derived class. I think that this is the best
solution for what you want to do.

The second is to actually expose the method as an implicit interface
implementation, marking it as virtual on the base class. This way, you can
override it on the derived class, and still have the interface
implementation call that method.

Hope this helps.

 

[Dan]

Thanks Nicholas. It helps to have someone confirm I haven't gone
completely sideways.

I would like to see a way to override protected abstract/virtual
methods of a base class in a more private way. Kind of a reverse
protected. Where an override method in a child class could be seen
only by the virtual/abstract member of the parent class. I'm sure that
is bad OO design or something. Basically trying to improve
encapsulation (exposing members only to those related classes that need
them) through more private inheritance. In the same vein I was excited
to see that in 2.0 I can give different protection levels to gets vs.
sets in a property. If I have to write a get, I want to restrict it as
much as possible.

Thanks again,
Dan

 

[Mohammad]

Dan,

I think that marking the leaf classes with the "internal" access
modifier would sort of achieve most of what you want.

I suppose you could als go a little farther and use the strategy
pattern.

 

[Jeff Louie]

I would get rid of the switch and use a dynamic class factory.

Regards,
Jeff
switch (behaviorInfo)