A class structure question

[Sid Price]

Hello,

I have a problem trying to figure out the following design issue. I have a
base class and a number of classes derived from that base. A method in the
base class covers 90% of the functionality required for all classes, however
I need to have that 10% functionality that is left in the derived classes.
What I would like to do is have the method in the base class be able to call
the method in the derived classes, it should do this according to the actual
class that was instantiated.

For example: The base class is "bClass", and there are two derived classes
"Class1" and "Class2". The method "Test" in bClass needs to call
"OtherMethod" in either Class1 or Class2. If I instantiate an object of type
Class1 and call "Test" I need it to call "OtherMethod" in Class1. Can this
be done?

Thanks,
Sid.

 

[Scott M.]

How about using the "MyClass" keyword?

 

[Tom Shelton]

Hello,

I have a problem trying to figure out the following design issue. I have a
base class and a number of classes derived from that base. A method in the
base class covers 90% of the functionality required for all classes, however
I need to have that 10% functionality that is left in the derived classes.
What I would like to do is have the method in the base class be able to call
the method in the derived classes, it should do this according to the actual
class that was instantiated.

For example: The base class is "bClass", and there are two derived classes
"Class1" and "Class2". The method "Test" in bClass needs to call
"OtherMethod" in either Class1 or Class2. If I instantiate an object of type
Class1 and call "Test" I need it to call "OtherMethod" in Class1. Can this
be done?

Thanks,
Sid.

It almost sounds like you need to create an abstract class (MustInherit
in VB.NET). It would look something like:

Option Explicit On
Option Strict On

Imports System

Module Module1

Sub Main()
Dim bc1 As TheBaseClass = New ChildClass1
Dim bc2 As TheBaseClass = New ChildClass2

bc1.TheSubThatCallsTheMethod()
bc2.TheSubThatCallsTheMethod()

End Sub

Private MustInherit Class TheBaseClass
Protected MustOverride Sub TheAbstractMethod()


Public Sub TheSubThatCallsTheMethod()
' do stuff
Me.TheAbstractMethod()
'do more stuff
End Sub
End Class

Private Class ChildClass1
Inherits TheBaseClass

Protected Overrides Sub TheAbstractMethod()
Console.WriteLine("Inside ChildClass1")
End Sub
End Class

Private Class ChildClass2
Inherits TheBaseClass

Protected Overrides Sub TheAbstractMethod()
Console.WriteLine("Inside ChildClass2")
End Sub
End Class

End Module

HTH

 

[Cor Ligthert [MVP]]

Price,

Reading your message I had the same idea of Tom about the mustInherit.
However at the end I had the idea that this would not be always needed, you
are only asking about the possibilitie to override (as Tom shows nicely) or
to shadow members. However without that mustInherit is Tom's sample as well
very good.

See for Shadows this, you use it the same as overriding but the base class
is than not any more used at all for that member (be aware by this at what
level you use it, how you use interfaces and how you cast).
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vblr7/html/vakeyShadows.asp

I hope this helps,



Cor

 

[Fabio]

For example: The base class is "bClass", and there are two derived classes
"Class1" and "Class2". The method "Test" in bClass needs to call
"OtherMethod" in either Class1 or Class2. If I instantiate an object of
type Class1 and call "Test" I need it to call "OtherMethod" in Class1. Can
this be done?

Define OtherMethod as abstract in bClass (that should be named ClassBase and
not bClass).
In Class1 and Class2 if you need special behavior do an override of
OtherMethod.

 

[Sid Price]

It almost sounds like you need to create an abstract class (MustInherit
in VB.NET).

That looks like it does exactley what I need, thank you Tom.
Sid.

 

[Phill W.]

I have a problem trying to figure out the following design issue. I have a
base class and a number of classes derived from that base. A method in the
base class covers 90% of the functionality required for all classes, however
I need to have that 10% functionality that is left in the derived classes.
What I would like to do is have the method in the base class be able to call
the method in the derived classes, it should do this according to the actual
class that was instantiated.

For example: The base class is "bClass", and there are two derived classes
"Class1" and "Class2". The method "Test" in bClass needs to call
"OtherMethod" in either Class1 or Class2. If I instantiate an object of type
Class1 and call "Test" I need it to call "OtherMethod" in Class1. Can this
be done?

Two ways:
(1) If you really want two methods ("Test" and "OtherMethod"):

Class bClass
Public Sub Test()
' 90% of test Code
Me.OtherMethod()
End Sub
Public Overridable Sub OtherMethod()
' Do Nothing
End Sub
End Class

Class Class1
Public Overrides Sub OtherMethod()
' Do the other 10%
End Sub
End Class

(2) Or, if you're not too bothered about having two methods, you can use
what I call "extending" (overriding, but then re-using the base class'
implementation), as in

Class bClass
Public Overridable Sub Test()
' 90% of the job
End Sub
End Class

Class Class1
Public Overrides Sub Test()
MyBase.Test() ' 90%

' Now, do the other 10%
End Sub

End Class

HTH,
Phill W.

 

[Scott M.]

Two ways:

(1) If you really want two methods ("Test" and "OtherMethod"):

Class bClass
Public Sub Test()
' 90% of test Code
Me.OtherMethod()
End Sub
Public Overridable Sub OtherMethod()
' Do Nothing
End Sub
End Class

Having a method that does nothing is a bad design idea. It's like putting a
button on a remote control that does nothing.

(2) Or, if you're not too bothered about having two methods, you can use
what I call "extending" (overriding, but then re-using the base class'
implementation), as in

Extending is what everyone else calls it as well.

 

[Phill W.]

Having a method that does nothing is a bad design idea. It's like putting a
button on a remote control that does nothing.

In itself, it does nothing, but it provides a "hook" for a derived class
to do something else .. er .. instead.

Extending is what everyone else calls it as well.

That's a relief. There's enough terminology around already without me
inventing any more of it ;-)

Regards,
Phill W.

 

[Scott M.]

Having a method that does nothing is a bad design idea. It's like

In itself, it does nothing, but it provides a "hook" for a derived class
to do something else .. er .. instead.

This is still a bad design interface. Since we don't know *if* a derived
class will even want to do *something* with this method, we are adding a
method for the sake of adding a method.