Hiding inherited members

[thechaosengine]

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

[Jon Skeet [C# MVP]]

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

[Nick Malik]

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

[Cor Ligthert]

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

[thechaosengine]

Thanks everyone.

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

Thanks again

Simon

[David Pokluda]

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

[UAError]

"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