How do I prevent a derived class from "Shadowing"?

[Larry Woods]

I have a method in my base class that I want ALL derived classes to use.
But, I find that I can create a "Shadow" method in my derived class that
"overrides" the method in my base class. Can't figure out what attribute to
put on the base class method to prevent this.

TIA,

Larry Woods

 

[Jay B. Harlow [MVP - Outlook]]

Larry,
The only "sure fire" way to prevent a subclass from using Shadow on a method
is to prevent the sub class in the first place via the NotInheritable
keyword.

Considering one of the main reasons for Shadows is to prevent changes in new
versions of base classes from breaking existing subclasses, I think not
having an attribute is more of a good thing then a bad thing. Otherwise
class libraries could release new versions, that had such an attribute and
suddenly break existing code!

What you can do in your code is assign your object to a variable of your
base type, then call you method, assuming the method is not overridable, you
are guaranteed that your version will be called and not the Shadowed
version.

Hope this helps
Jay

 

[Larry Woods]

Thanks, Jay.

Looks like Shadow is a "feature" I could do without. Seems to pretty much
eliminates the possibility for guaranteeing the encapsulation of code in a
base class, right?

Larry

 

[Jay B. Harlow [MVP - Outlook]]

Larry,
Its a matter of perspective.

Looks like Shadow is a "feature" I could do without. Seems to pretty much
eliminates the possibility for guaranteeing the encapsulation of code in a
base class, right?

Wrong! :-|

The way I view it guarantees the encapsulation of code in both the base &
the derived classes! Calling the method on a variable of the derived class
will call the code that is encapsulated in the derived class, calling the
method on a variable of the base class (with a derived object) will call the
code that is encapsulated in the base class!

In other words every place you need to ensure that you are calling the base
version use a base variable! Which is then dependant of the actual type of
object you are dealing with!

For example:

Public Class Base
Public Sub ImportantMethod()
End Class

Public Class Derived : Inherits Base
Public Shadows Sub ImporantMethod()
End Class

Dim anObject As Base = New Derived
anObject.ImportantMethod()

In the above Base.ImportantMethod is called guaranteed! Granted it sounds
like you are using:

Dim anObject As Derived = New Derived
anObject.ImportantMethod()

Which ensures that the Derived.ImportantMethod is called, which I hope you
realize is equally important!!!! Especially when I defined
Derived.ImportantMethod in version 1 of my project, then
Base.ImportantMethod got defined in version 2 of my project, and changing
Derived.ImportantMethod will not be covered by your financial backers even
with Refactoring (http://www.refactoring.com).

I get the impression you see Derived.ImportantMethod as a clever ploy your
junior programmers can use to circumnavigate you base class design. This is
where code reviews are useful, using automated tools if possible, one of the
many Code Critics available, would identify it and you can deal with it at
that level, unless this instance falls into the versioning issue in which
case you can keep the Shadows.

Of course in your code review, you could just open the project & do a find
in files for "Shadows" instead of purchasing a Code Critic, however a Code
Critic can ensure other standards are adhered to.

Hope this helps
Jay

 

[Jay B. Harlow [MVP - Outlook]]

Doh!

In other words every place you need to ensure that you are calling the base
version use a base variable! Which is then dependant of the actual type of
object you are dealing with!

Should read "Which is then independent of the actual type of object you are
dealing with"

Jay

 

[Peter Huang]

Hi Larry,

I think no one can force the derived classes to call the base class's
method. If you let someone derive form you, they can change their
interface. Anyone deriving from them will indeed inherit their behavior.
The person writing the derived class's code can decide which method to
call. They are writing the code, after all.

If you are really concerned about people deriving from the class, you
should make it NonInheritable,
What is the senario? Maybe there is a better solution.

Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Larry Woods]

O.K., Jay.

So how do I GUARANTEE that my base methods are ALWAYS used by the derived
classes? My example is a pricing algorithm that is implemented through a
method in the base. Regardless of the derived class I want to be assured
that the author of the derived class CANNOT override the pricing method in
the base.

How do I do this?

TIA,

Larry

 

[Larry Woods]

I agree, Peter.

Please see my response to Jay.

TIA,

Larry

 

[Jay B. Harlow [MVP - Outlook]]

Larry,

So how do I GUARANTEE that my base methods are ALWAYS used by the derived
classes?

I'm Sorry. Did you read any of what Peter or I said? Peter and I both told
you to Guarantee it you use NotInheritable!

Something like:
Public NotInheritable Class PricingAlgorithm

Public Function Calculate(input As Decimal) As Decimal
End Function
End Class

If NotInheritable is not an option there is NO Guarantee.

I then attempted to explain why there is No Guarantee.

Hope this helps
Jay

 

[Peter Huang]

Hi Larry,

According to my last post, since the based class can be inherited, then it
is reasonable for the programmer to write his own method with the same name
with in base class.
I think this is be design.

Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.