By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,264 Members | 1,718 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,264 IT Pros & Developers. It's quick & easy.

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

P: n/a
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
Nov 20 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
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" <la***@lwoods.com> wrote in message
news:u5**************@TK2MSFTNGP10.phx.gbl...
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

Nov 20 '05 #2

P: n/a
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]" <Ja************@msn.com> wrote in message
news:e7**************@TK2MSFTNGP11.phx.gbl...
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" <la***@lwoods.com> wrote in message
news:u5**************@TK2MSFTNGP10.phx.gbl...
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


Nov 20 '05 #3

P: n/a
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

"Larry Woods" <la***@lwoods.com> wrote in message
news:en**************@TK2MSFTNGP11.phx.gbl... 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]" <Ja************@msn.com> wrote in message
news:e7**************@TK2MSFTNGP11.phx.gbl...
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" <la***@lwoods.com> wrote in message
news:u5**************@TK2MSFTNGP10.phx.gbl...
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



Nov 20 '05 #4

P: n/a
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

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:uP**************@TK2MSFTNGP09.phx.gbl... 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

"Larry Woods" <la***@lwoods.com> wrote in message
news:en**************@TK2MSFTNGP11.phx.gbl...
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]" <Ja************@msn.com> wrote in message news:e7**************@TK2MSFTNGP11.phx.gbl...
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" <la***@lwoods.com> wrote in message
news:u5**************@TK2MSFTNGP10.phx.gbl...
> 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
>
>



Nov 20 '05 #5

P: n/a
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.

Nov 20 '05 #6

P: n/a
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

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:OS*************@TK2MSFTNGP11.phx.gbl...
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

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:uP**************@TK2MSFTNGP09.phx.gbl...
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

"Larry Woods" <la***@lwoods.com> wrote in message
news:en**************@TK2MSFTNGP11.phx.gbl...
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]" <Ja************@msn.com> wrote in message news:e7**************@TK2MSFTNGP11.phx.gbl...
> 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" <la***@lwoods.com> wrote in message
> news:u5**************@TK2MSFTNGP10.phx.gbl...
> > 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
> >
> >
>
>



Nov 20 '05 #7

P: n/a
I agree, Peter.

Please see my response to Jay.

TIA,

Larry

"Peter Huang" <v-******@online.microsoft.com> wrote in message
news:yh**************@cpmsftngxa07.phx.gbl...
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.

Nov 20 '05 #8

P: n/a
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

"Larry Woods" <la***@lwoods.com> wrote in message
news:uL**************@TK2MSFTNGP11.phx.gbl... 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

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:OS*************@TK2MSFTNGP11.phx.gbl...
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

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:uP**************@TK2MSFTNGP09.phx.gbl...
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

"Larry Woods" <la***@lwoods.com> wrote in message
news:en**************@TK2MSFTNGP11.phx.gbl...
> 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]" <Ja************@msn.com> wrote in message
> news:e7**************@TK2MSFTNGP11.phx.gbl...
> > 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" <la***@lwoods.com> wrote in message
> > news:u5**************@TK2MSFTNGP10.phx.gbl...
> > > 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
> > >
> > >
> >
> >
>
>



Nov 20 '05 #9

P: n/a
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.

Nov 20 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.