johnson@p.cs.uiuc.edu (11/26/89)
Tim Atkins comments on the claim that inheritance violates encapsulation and says that he doesn't believe it. Brian Gilstrap responds: >Class A inherits from class X. In many OO programming languages if not >most that means that A gets to access X's local data items. Thus, if X >had a data item 'foo', code from class A could directly access 'foo'. >This means that class doesn't just depend upon the interface of X but >also depends upon the implementation of X. This means that if X changes, >A may have to change (and anything which is a descendant of X including >all of A's descendants). This tends to make those classes near the root >of an inheritance heirarchy become "rigid" very quickly, since changes >can "ripple" down the heirarchy. This is viewed as a bad thing since the >whole point of OO is to avoid "ripples" which propagate through a software >system. Although this is technically correct, I don't think it has much practical effect. The major problem in C++ is that one often needs to change the return types or argument types of classes, or one needs to add a new function to a class. This is changing the interface. The interface that a class presents to a subclass is much broader than that which it presents to a client. I am a strong believer in abstract classes, which depend on their subclasses to make a number of key design decisions. Abstract classes don't usually have many instance variables, so changing them is not a big problem. Most interesting changes to an abstract class are really changes to the interface. If it were possible to hide lots of information in a class, then that class probably should have been reused as a component rather than as a superclass. Ralph Johnson -- University of Illinois at Urbana-Champaign