Hiding inherited members

  • Thread starter Thread starter thechaosengine
  • Start date Start date
T

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
 
thechaosengine said:
Is there a way to hide a member in a subclass that has been inherited from a
base class?
Click to expand...

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.
Click to expand...

No, you can't.
Ok. Now you can flame me on what a bad idea it is.
Click to expand...

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
 
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
 
Thanks everyone.

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

Thanks again

Simon
 
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"
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
Click to expand...

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
 
Back
Top