When I declare a subclass, I'm saying that A isa B. Making this work generally requires that A and B cooperate to some extent. At a minimum, the author of A needs to know what methods B is likely to expect to see overridden. Missing some of them may mean that your object behaves weirdly. Sometimes you need access to class data. In many languages the subclass implementor has access to special protected functions, and needs to know when they are supposed to be called. All of this may need updating if the parent module changes. And so on.
In short, the concept of "isa" represents reasonably tight coupling between components. Some of the tightness is accidental - such as the result of the visibility of the implementation in Perl. But some is intrinsic to what OO is. If you're unwilling to accept this coupling, then you probably shouldn't be subclassing.
Remember that OO provides a series of potential compromises between reducing duplication of information and reducing coupling. It is good to not duplicate information. It is good to have loose coupling. Those goals are good because each avoids a difficult problem. Unfortunately they naturally conflict, reducing duplicate information naturally couples things together.
Among those potential compromises, inheritance is the choice that gives the best opportunity for removing duplication of information. But at a natural cost of tighter coupling.
In reply to Re^4: Private Methods Meditation
by tilly
in thread Private Methods Meditation
by theAcolyte
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |