Modifier mixture

[AD]

Hi,

I have a base class that is inherited often, and I am struggeling to
chose the correct access modifiers.

What I am trying to do is to force all inherited classes to have a
function of the same name as one of the functions in base class (like
an abstract function), but I would also like to add a body to the
function in the base class (like a public/private/protected function),
how would I go about it?

public class BaseClass
{
public BaseClass() {}
public/abstract bool SomeFunction(){return false;} //This is where
the problem lies
}

public class DerivedClass : BaseClass
{
public DerivedClass():base() {}
public bool SomeFunction(){return false;}
}

 

[Jon Skeet [C# MVP]]

I have a base class that is inherited often, and I am struggeling to
chose the correct access modifiers.

What I am trying to do is to force all inherited classes to have a
function of the same name as one of the functions in base class (like
an abstract function), but I would also like to add a body to the
function in the base class (like a public/private/protected function),
how would I go about it?

You can't.

What exactly are you trying to achieve? One pattern is to have one
concrete method, and an abstract one which is called by the concrete
one.

 

[AD]

You can't.

What exactly are you trying to achieve? One pattern is to have one
concrete method, and an abstract one which is called by the concrete
one.

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.

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.

Does this make any sense?

 

[Jon Skeet [C# MVP]]

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.

Well, I'm not sure what you mean by a virtual class here...

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.

Well, you can have a protected method that all the implementations can
call for the common things.

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.

Does this make any sense?

I have to say, I'm not sure that inheritance is the best course here. I
tend to be wary of overuse of inheritance. See
http://msmvps.com/jon.skeet/archive/2006/03/04/inheritancetax.aspx
for more information on this.

However, I don't see that you need a copy of the class, even if you do
use inheritance. If you want a concrete class which has "dummy"
implementations, you can always create one which implements the
abstract methods from the base class.

 

[Larry Lard]

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...)

 

[AD]

So do you want instances of the base class to be createable or not?


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.


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...)


--
Larry Lard
(e-mail address removed)
The address is real, but unread - please reply to the group
For VB and C# questions - tell us which version

Hi Larry,

Thanks for your post. From your example what I would like is for
BoringDerivedClass to cause a compilation error because it did not
override SomeMethodImplementation (like a abstract declaration would),
but I would like to have code in the SomeMethodImplementation function
in the base class (like a virtual declaration would allow for) like you
have.

Basically I would like for every derived class of my base class to
contain certain behavioural functions, but because my base class is not
a true abstract class, I need to have code in the base class' function
as well.