470,594 Members | 1,530 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,594 developers. It's quick & easy.

Hiding inherited members

Hi all,

Is there a way to hide a member in a subclass that has been inherited from a
base class?

Lets leave aside any issues regarding whether its a good idea for a moment.
Here's an example similar to what I'm thinking about.

Lets suppose I make a class called RoleCollection.

RoleCollection inherits and extends the functionality of ArrayList.

ArrayList implements a public method called RemoveAt().

I may want to guard against the user of my base class depending on that
method. Maybe i can't be arsed implementing it and just want to hide the
fact that it exists. I could return an OperationNotImplementedException or
something but I'm wondering if its possible to do method hiding.

Ok. Now you can flame me on what a bad idea it is.

Let the flaming scorn begin

tce
Nov 22 '05 #1
6 2314
thechaosengine <sh856531@microsofts_free_email_service.com> wrote:
Is there a way to hide a member in a subclass that has been inherited from a
base class?
You can hide a member in terms of defining a new member with the same
name, but you can't make a member "go away" as it were.
Lets leave aside any issues regarding whether its a good idea for a moment.
Here's an example similar to what I'm thinking about.

Lets suppose I make a class called RoleCollection.

RoleCollection inherits and extends the functionality of ArrayList.

ArrayList implements a public method called RemoveAt().

I may want to guard against the user of my base class depending on that
method. Maybe i can't be arsed implementing it and just want to hide the
fact that it exists. I could return an OperationNotImplementedException or
something but I'm wondering if its possible to do method hiding.
No, you can't.
Ok. Now you can flame me on what a bad idea it is.


Here's why it's a bad idea:

ArrayList al = myRoleCollection;

Now ArrayList *does* have RemoveAt(), so the compiler *must* allow you
to call it.

It's linked to Liskov's Substitutability Principle - Google for some
references on that

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 22 '05 #2
Just to add to Jon's answer:

If you don't want your child object to be usable by anyone who knows how to
handle an ArrayList, then don't inherit from ArrayList. Simply create an
Arraylist within your object and expose the methods that you want to expose.
This is a key principle of good design anyway (favor composition over
inheritance).

--- Nick

"thechaosengine" <sh856531@microsofts_free_email_service.com> wrote in
message news:O9**************@TK2MSFTNGP11.phx.gbl...
Hi all,

Is there a way to hide a member in a subclass that has been inherited from a base class?

Lets leave aside any issues regarding whether its a good idea for a moment. Here's an example similar to what I'm thinking about.

Lets suppose I make a class called RoleCollection.

RoleCollection inherits and extends the functionality of ArrayList.

ArrayList implements a public method called RemoveAt().

I may want to guard against the user of my base class depending on that
method. Maybe i can't be arsed implementing it and just want to hide the
fact that it exists. I could return an OperationNotImplementedException or
something but I'm wondering if its possible to do method hiding.

Ok. Now you can flame me on what a bad idea it is.

Let the flaming scorn begin

tce

Nov 22 '05 #3
Not in contradiction with the others, however it seems to me that shadows
(in VBNet) is what you ask.

http://msdn.microsoft.com/library/de...keyShadows.asp

You can see this behaviour when you look at the background property of the
picturebox. It is there because it comes from Control, however it does
nothing.

I hope this gives some idea's

Cor

"thechaosengine" <

Is there a way to hide a member in a subclass that has been inherited from
a base class?

Lets leave aside any issues regarding whether its a good idea for a
moment. Here's an example similar to what I'm thinking about.

Lets suppose I make a class called RoleCollection.

RoleCollection inherits and extends the functionality of ArrayList.

ArrayList implements a public method called RemoveAt().

I may want to guard against the user of my base class depending on that
method. Maybe i can't be arsed implementing it and just want to hide the
fact that it exists. I could return an OperationNotImplementedException or
something but I'm wondering if its possible to do method hiding.

Ok. Now you can flame me on what a bad idea it is.

Let the flaming scorn begin

tce

Nov 22 '05 #4
Thanks everyone.

I know why its a bad idea. I was just wondering if it was possible.

Thanks again

Simon
Nov 22 '05 #5
I agree what was already said. When you don't want to follow the interface
of the base class then it means that your derived object "IS NOT A" base
type object. It can be true that "IT HAS" a base class object and therefore
I would recommend you to create a composite -- including base object to be a
member of your new class.

Regards,
David.

"thechaosengine" <sh856531@microsofts_free_email_service.com> wrote in
message news:O9**************@TK2MSFTNGP11.phx.gbl...
Hi all,

Is there a way to hide a member in a subclass that has been inherited from
a base class?

Lets leave aside any issues regarding whether its a good idea for a
moment. Here's an example similar to what I'm thinking about.

Lets suppose I make a class called RoleCollection.

RoleCollection inherits and extends the functionality of ArrayList.

ArrayList implements a public method called RemoveAt().

I may want to guard against the user of my base class depending on that
method. Maybe i can't be arsed implementing it and just want to hide the
fact that it exists. I could return an OperationNotImplementedException or
something but I'm wondering if its possible to do method hiding.

Ok. Now you can flame me on what a bad idea it is.

Let the flaming scorn begin

tce

Nov 22 '05 #6
"thechaosengine"
<sh856531@microsofts_free_email_service.com> wrote:
Hi all,

Is there a way to hide a member in a subclass that has been inherited from a
base class?

Lets leave aside any issues regarding whether its a good idea for a moment.
Here's an example similar to what I'm thinking about.

Lets suppose I make a class called RoleCollection.

RoleCollection inherits and extends the functionality of ArrayList.

ArrayList implements a public method called RemoveAt().

I may want to guard against the user of my base class depending on that
method. Maybe i can't be arsed implementing it and just want to hide the
fact that it exists. I could return an OperationNotImplementedException or
something but I'm wondering if its possible to do method hiding.

Ok. Now you can flame me on what a bad idea it is.

Let the flaming scorn begin

tce


What always amazes me is the number of people who claim to
practice OOP and yet have not heard of the Liskov
Substitution Principle (1988):

http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple
http://www.objectmentor.com/resources/articles/lsp.pdf

Its paraphrased as "subtypes must be substitutable for their
basetype."

That being said, hiding inherited members is simply absurd.

The fact that the practice all of a sudden seems useful is
usually indicative of overuse of inheritance - to counteract
that:

- Refactor the inherited "interface" into two or more actual
interfaces.

- implement only those interfaces required in the new type
and reuse the supertype through containment and delegation.

See also:
Uses and Abuses of Inheritance
http://www.gotw.ca/publications/mill06.htm
http://www.gotw.ca/publications/mill07.htm
Nov 22 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by thechaosengine | last post: by
7 posts views Thread by Tron Thomas | last post: by
10 posts views Thread by Jacob | last post: by
4 posts views Thread by Dan | last post: by
7 posts views Thread by OpticTygre | last post: by
14 posts views Thread by lovecreatesbea... | last post: by
9 posts views Thread by Torben Laursen | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.