Hiding inherited members

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

thechaosengine - 30 Nov 2004 14:25 GMT

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

Reply to this Message

Jon Skeet [C# MVP] - 30 Nov 2004 14:33 GMT

> 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.
[quoted text clipped - 9 lines]
> 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

Signature

Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Reply to this Message

Nick Malik - 30 Nov 2004 15:44 GMT

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

> Hi all,
>
[quoted text clipped - 20 lines]
>
> tce

Reply to this Message

Cor Ligthert - 30 Nov 2004 15:55 GMT

Not in contradiction with the others, however it seems to me that shadows
(in VBNet) is what you ask.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vblr7/html/vake
yShadows.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?
[quoted text clipped - 18 lines]
>
> tce

Reply to this Message

thechaosengine - 30 Nov 2004 16:46 GMT

Thanks everyone.

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

Thanks again

Simon

Reply to this Message

David Pokluda - 30 Nov 2004 20:43 GMT

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.

> Hi all,
>
[quoted text clipped - 20 lines]
>
> tce

Reply to this Message

UAError - 30 Nov 2004 22:48 GMT

"thechaosengine"
<sh856531@microsofts_free_email_service.com> wrote:

>Hi all,
>
[quoted text clipped - 20 lines]
>
>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

Reply to this Message

Hiding inherited members

Free Magazines