Non monotonous inheritance

[roshinitraj]

In monotonic inheritance, a subclass can add new properties and/or property values. In non-monotonic inheritance, one can change what’s inherited: either to replace/override (i.e., modify) or to cancel (i.e., delete) an inherited property value.

Which are the languages that support non-monotonic inheritance?
How can non-monotonic inheritance be implemented in java?

Found that when deletion is required in specialization it can be done in 2 ways. For example, Bird super-class and Penguin child class should not contain the fly() function. The 2 ways are:
1. Create a more “faithful” hierarchy: Create a class bird and 2 children flying-bird and non-flying-bird and derive penguin from non-flying-bird.
2. Redefine “fly” so that it generates a runtime error:
void error(const string & msg);

class Penguin : public Bird {
public:
virtual void fly() { error(“Penguins can’t fly!”);
};

Are there any other ways of doing this (deleting an inherited attribute)?

[ProgramThis]

Polymorphism.

If you have a parent class that has inherited values then you do exactly what you are referring to:

A.) create sub classes to break it down further, or
B.) simply overriding the method/attribute and giving it the meaning that relates to your specific object.

If there is a method fly() in the parent class, simply override it in the child class and do something (throw an error or, like you did, print a message saying "not possible", or however you want to handle it). Through the use of Polymorhpism, the JVM will know exactly which fly() method to call and you will not have penguins flying all over the place.

[keang]

You could use interfaces or a combination of a base class and interface(s). eg if the Bird class only defined methods that were common to all birds then those Birds that can fly could implement an interface that defines the fly() method. This interface could also be used by other flying creatures such as Bats, Flying Squirrels etc.

[dlorde]

Overriding a method to do nothing or return an error generally indicates a design failure - a breach of the Liskov Substitution Principle/Design By Contract (http://en.wikipedia.org/wiki/Liskov_substitution_principle). Unfortunately, you can't always avoid this (especially when extending legacy code). The Null Object (http://en.wikipedia.org/wiki/Null_Object_pattern) pattern can be useful when a null implementation is required. When you know in advance that your objects will have multiple and varying implementations of a feature, you can implement separate interfaces, e.g. Flyer, Swimmer, Runner, etc., or use a generic Movement or Locomotion interface - the precise technique depends how they will be used in the application.

In program design a lot depends on the particular context you're dealing with. Quite often you may be modelling objects from the real world, but always in a restricted domain, where only certain aspects of the real-world objects are relevant. If you are a bird food supplier, you would probably be interested in whether the birds are seed eaters, fruit eaters, fish eaters, carrion eaters, etc. You might not be interested in their method of locomotion. In general, once you've identified what is and what is not relevant and within your problem domain, you can do a better job of the architecture to reduce these problems to a minimum.

Any programming problem can be solved by adding a level of indirection...
Anon.

[roshinitraj]

Thanks for the replies.

[timhoustontx]

Sorry, you just can't do what you are asking, period.

The best you can do is use some other pattern to emulate this behavior. A good candidate is ChainOfResponsibility -- altering the change is analogous to changing a class's inheiritance.