On 25-Nov-2008, at 10:58 PM, Vassili Bykov wrote:
And thus the fragile superclass problem is born.
:-)
The thing is, there are two overlapping but different perspectives here. From an object-centric view, sure, any state or behavior is there in the object and where in the hierarchy it comes from is a minor detail.
However, as far as the code goes, we are talking about distinct chunks of code, potentially written, maintained and updated by different people. A subclass depends on the superclass in the same way that code using a library is a dependent of that library's API. Managing that dependency has maintainability repercussions, and weakening it is a good thing.
If my memory isn't failing me too much I seem to remember going to a talk about a dozen years ago by Adele Goldberg where she talked about the need to form contracts between producers and consumers of class definitions.