A well-know shortcoming of traditional class hierarchies is that they are bad when it comes to model the real world. As an example, trying to represent animals species with classes. There are actually several problems when doing that, but one that I never saw a solution to is when a sub-class "looses" a behavior or properties that was defined in a super-class, like a penguin not being able to fly (there are probably better examples, but that's the first one that comes to my mind, having seen "Madagascar 2" recently).
On the one hand, you don't want to define for every property and behavior some flag that specifies if it is at all present, and check it every time before accessing that behavior or property. You would just like to say that birds can fly, simply and clearly, in the Bird class. But then it would be nice if one could define "exceptions" afterward, without having to use some horrible hacks everywhere. This often happens when a system has been productive for a while. You suddenly find an "exception" that doesn't fit in the original design at all, and you don't want to change a large portion of your code to accommodate it.
So, is there some language or design patterns that can cleanly handle this problem, without requiring major changes to the "super-class", and all the code that uses it? Even if a solution only handle a specific case, several solutions might together form a complete strategy.
[EDIT] Forgot about the Liskov Substitution Principle. That is why you can't do it. Assuming you define "traits/interfaces" for all major "feature groups", you can freely implement traits in different branches of the hierarchy, like the Flying trait could be implemented by Birds, and some special kind of squirrels and fish.
So my question could amount to "How could I un-implement a trait?" If your super-class is a Java Serializable, you have to be one too, even if there is no way for you to serialize your state, for example if you contained a "Socket".
So one way to do it is to always define all your traits in pair from the start: Flying and NotFlying (which would throw UnsupportedOperationExceiption, if not checked against). The Not-trait would not define any new interface, and could be simply checked for. Sounds like a "cheap" solution, in particular if used from the start.
