|laziness, impatience, and hubris|
This has been a debate in the OO community for some time. The initial paper on this subject was "Encapsulation and Inheritance in Object-Oriented Programming Languages". The only discussion I recall seeing in a normal book on programming was Effective Java by Joshua Bloch. There are several examples of "bad" things happening in the real world. The highest profile one I remember was an upgrade of Java's Servlet classes. Many early servlet applications were created by inheriting from Sun's Java classes. Well, with the upgrade, certain portions of the class internals were changed, causing the base API to return differing values between the versions. So, to upgrade, many people had to rewrite their applications. Bloch and others argue that this can be avoided by encapsulating classes in many cases, especially if you have no control over the other class (i.e. you have the class from a vendor but not the code for it). This topic is still open to debate, and there are many cases where one is much more applicable than others.
In reply to Re: Re: Often Overlooked OO Programming Guidelines