From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.misc:7453 comp.object:469 comp.lang.ada:2970 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!swbatl!uucibg From: uucibg@swbatl.UUCP (3929) Newsgroups: comp.misc,comp.object,comp.lang.ada Subject: Re: Integrating concurrent & O-O programming Message-ID: <978@swbatl.UUCP> Date: 22 Nov 89 22:08:05 GMT References: <7062@hubcap.clemson.edu> <1667@osc.COM> Reply-To: uucibg@swbatl.UUCP (Brian Gilstrap - UCI - 5-3929) Organization: Southwestern Bell Tele. Co. - Advanced Technology Lab - St. Louis List-Id: In article <1667@osc.COM> tma@osc.UUCP (Tim Atkins) writes: >I have heard this before and, frankly, I don't get it. The subclass >has inherited data structure definition from the parent class. Therefore >its instances will contain instances of the parent data structure. This >is totally local to the object! Only the definition was inherited. Why >is this a bad thing? Why does it break encapsulation? I understood the >encapsulation wrt data provided by OO techniques to simply state that instance >data should not be accessed directly but only through a method defined on >the class. Therefore, inheritance does not seem to break encapsulation. > >I would appreciate it if someone could set me straight here. As I understand your question, here is (one of) the rub(s): 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. Note that some languages help provide solutions for this. For example, C++ has the concepts of public, protected, and private items in a class, to help in restricting access to data members. When this is combined with the ability to inline functions, you can provide interface routines for every data member that is meant to be accessable in an efficient manner and thus hide the implementation from sub-classes without taking a major performance hit. (By the way, I'm still not totally sold on C++ but this aspect is certainly nice). Thanks, -------------------------------------------------------------------------------- Brian R. Gilstrap ...!{ texbell, uunet }!swbatl!uucibg OR uucibg@swbatl.UUCP One Bell Center +---------------------------------------------------------- Rm 17-G-4 | "Winnie-the-Pooh read the two notices very carefully, St. Louis, MO 63101 | first from left to right, and afterwards, in case he had (314) 235-3929 | missed some of it, from right to left." -- A. A. Milne -------------------------------------------------------------------------------- Disclaimer: Me, speak for my company? You must be joking. I'm just speaking my mind.