I think I have a solution to some problems that occur in OO design. The problems occurs when a method can be implemented that provides a great functionality for a specific class, but which it is not valid for its subclasses without extra work. The classic examples in C++ would be serialize.
void serialize(ostream&); A class can always implement serialize(), but it's children will have to override the method with their own definition, which will probably call parent::serialize(), then go on to copy any added fields. If they forget, the class does not return the right data (it loses the extra fields). The solution: even though the method is public, make it possible to mark the implementation as non-inherited. In other words, B will inherit the signature for clone() from A, but if the user attempts to link against B::clone() they had better implement it -- such a call will not resolve to A::clone(). If B wants to just use A's version they can just call A.serialize() in their method body. It's not a private method, it just requires developer attention one way or the other to derive from the class. I think this would make inheritance in OO design a lot less brittle. Note that constructors (in C++ anyway) already have this property -- they aren't inherited by default (except the default constructor). This is because methods like serialize, toString(), constructors, opCmp, etc are 'holistic' in the sense that they address all elements of a class and it is probably an error if they miss one. Other methods like increaseRefCount() or getName() are field-wise operations that deal with a few select member variables. Kevin
