On Thu, Dec 3, 2009 at 10:15 PM, Kevin Bealer <[email protected]> wrote: > 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.
Trouble is you have no idea exactly what behavior other classes are going to extend. It may not require reimplementing serialize, for instance. Like subclassing to implement ref-counting or something. I don't think you can determine up front which methods need to be overridden and which do not. It depends entirely upon how the subclass is going to extend the base class. --bb
