AD said:
Hi Jon, thanks for the post
What I'm trying to do is to use a class as an abstract class, but still
be able to use the class as a normal class. This is sounding like a
virtual class, but with the virtual class overrides are optional.
My current design is that my base class carries the "generic"
functionality of most applications developed by our company, so when it
is inherited it exposes that functionality to all consumer classes. Now
I would also like my base class to enforce certain functions in all
consumer classes (for example a function called "Install" that will
create all SQL Stored procs used by the module) to improve consistancy
across classes and open up some reflection possibilities.
So do you want instances of the base class to be createable or not?
The only way I see this happening is creating a copy of my base class
as a true abstract class and consumer inheriting that, but that would
cause code duplication that I'm trying to avoid.
As suggested, it sounds like you may want something like this (air code):
class BaseClass {
public BaseClass() { } // base class is instantiable
public void SomeMethod()
{ SomeMethodImplementation(); }
protected virtual void SomeMethodImplementation()
{ DoDefaultStuff(); } // not shown
}
class InterestingDerivedClass : BaseClass {
public InterestingDerivedClass : base() { } // derived class is of
course instantiable
protected override void SomeMethodImplementation()
{ base.SomeMethodImplementation(); // do the standard stuff
DoDerivedStuff(); // not shown
}
}
class BoringDerivedClass : BaseClass {
public BoringDerivedClass : base() { } // derived class is of
course instantiable
}
Now, people calling SomeMethod on a BaseClass, or on a descendant (such
as BoringDerivedClass) that does not override SomeMethodImplementation,
will get the DoDefaultStuff behaviour. People calling SomeMethod on a
subclass such as InterestingDerivedClass will get that class's
DerivedStuff (and the DefaultStuff, if that base. call is left in).
Both -DerivedClasses *have* a public void SomeMethod() method, as far as
reflection is concerned, but only one has chosen to change the behaviour
of it from that proposed by the base class.
If you don't actually need BaseClass to be instantiable, make it and
SomeMethodImplementation abstract.
Does this make any sense?
I find it can be useful when doing stuff like this to first work out
what the object model 'looks like from outside' - that is, write some
*client* code that will attempt to use the as-yet-uncreated objects.
This will very often dictate exactly what the design needs to be. (This
sort of thinking eventually leads one to test-driven development, which
I constantly intend to really spend some time on...)
