disabling parent's functions when inheriting ..?

[Spacecowboy_J]

Hi,
I have a very annoying JAvA exercise to do in which one class needs to be an "exdends"-child of a parent. The child should NOT have functions avaliable though that the parent does have. As in .. the parent has a function called pair() .. this function should not be callable for the child. I can modify the parent as well as the child however much I like .. both have to be non-abstract classes though, and if possible, the inheritance should be direct.
As far as I can tell, I can't really tell the child that it doesn't have functions its parent has. am I missing a loophole?

Thanks.

[randomjunk]

Declare pair() as a private method in the super class (parent).

The subclass (child) then won't be able to call this method. Also if the subclass were to create it's own pair() method this would not interfere/effect/or have anything to do with the pair() method of the superclass.

This excercise seems to be teaching you about access modifiers. I suggest you go through your notes to see if you've actually been told about them... it would help.

[dlorde]

The public interface of a class is inherited and exposed by its subclasses. There's nothing you can do to change that, because although you can override methods in the subclass to give wider access, you can't restrict access. This is why a subclass is said to have an 'is-a' relation to the superclass - it is a superclass type (possibly extended). This is known as the Liskov Substitution Principle, which basically says that any subclass reference can be substituted wherever a superclass reference is used.

If this behaviour is not what you want (i.e. you don't want to expose some public superclass methods), then inheritance is not the correct technique to use.

A common technique is to use containment (the Adapter pattern), where your class holds an instance of what would have been the superclass as a private field, and declares methods that forward to this contained instance. This way, you can expose only those methods of the contained instance that you want, and you have the opportunity of changing the names and behaviour to better fit your exact requirements. However, since your class is not a subclass of the original, it can't be used where a reference to the original is expected.

The Java SDK sometimes uses a horrible hack to get around this problem and simply overrides any undesirable superclass methods to simply throw an UnsupportedOperationException when they are called. This is poor design and breaks the LSP, but I guess an ugly compromise is sometimes easier than doing it right...

The Java SDK Stack class is an example of inheritance incorrectly used instead of containment - it subclasses Vector and so exposes all Vector's public methods.

Inheritance is often overused by novices - to a man with a hammer, everything looks like a nail...

[cjard]

Hi,
I have a very annoying JAvA exercise to do in which one class needs to be an "exdends"-child of a parent. The child should NOT have functions avaliable though that the parent does have.

In summary of what dlorde notes; you cant really do this (or you shouldnt) because then, it means that the child is not actually an extension of it's parent.. Suppose you have a Vehicle and a Car. A Car is an extension of Vehicle, but if a Vehicle can be driven and a Car cannot, then how can you assert that a Car is a Vehicle?