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
9  1768 
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
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
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
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
>
>
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.
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
> >
> >
>
>
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.
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
> > >
> > >
> >
> >
>
>
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: tertius |
last post by:
Is there a better way to append certain chars in a string with a
backslash that the example below?
chr = "#$%^&_{}" # special chars to look out for
str = "123 45^ & 00 0_" # string to...
|
by: Istvan Albert |
last post by:
Paul McGuire wrote:
> Please reconsider the "def f() :" construct. Instead of
> invoking a special punctuation character, it uses context and placement,
> with familiar old 's, to infuse the...
|
by: BJörn Lindqvist |
last post by:
I think it would be cool if you could refer to instance variables
without prefixing with "self." I know noone else thinks like me so
Python will never be changed, but maybe you can already do it...
|
by: James A. Donald |
last post by:
I am contemplating getting into Python, which is used by engineers I
admire - google and Bram Cohen, but was horrified to read
"no variable or argument declarations are necessary."
Surely that...
|
by: Klaus Löffelmann |
last post by:
Hi,
maybe it's already too late, but what is the deal with overwriting
Object.Equals.
I have to use "overrides overloads" to really overwrite the correct
'version' of equals, even if a single...
|
by: Dave Taylor |
last post by:
I'm trying to derive a class from a typed DataSet to add some methods to one
of the DataTables. I would like to keep the names the same in the derived
class as in the base class, so I have used...
|
by: JohnR |
last post by:
In it's simplest form, assume that I have created a usercontrol,
WSToolBarButton that contains a button. I would like to eventually create
copies of WSToolBarButton dynamically at run time based...
|
by: utab |
last post by:
Dear all,
Is there a clear distinction how to decide which functions to be
members of a class and which not
How is your attitude (Your general way from your experiences ...)
"If the...
|
by: Jeremy J Starcher |
last post by:
While reading c.l.j, I've noticed that some people prefer and indeed even
recommend the use of "window.alert()" over "alert()".
I can't find any technical reason to make this distinction, and...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
