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 Path: utzoo!attcan!uunet!mcsun!cernvax!chx400!ugun2b!cui!anders From: anders@cui.unige.ch (BJORNERSTEDT Anders) Newsgroups: comp.lang.ada Subject: Re: Integrating concurrent & O-O programming Message-ID: <478@cui.unige.ch> Date: 23 Nov 89 14:56:34 GMT References: <7062@hubcap.clemson.edu> <1667@osc.COM> Reply-To: anders@cui.UUCP () Organization: University of Geneva, Switzerland List-Id: In article <1667@osc.COM> tma@osc.UUCP (Tim Atkins) writes: >In article <7062@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes: >> ...consider the interference that occurs between class inheritance >> and encapsulation when subclasses are allowed to access freely the >> instance variables of the parent class [Sny86]. In this case we may >> say that support for inheritance diminishes the degree of encapsulation >> that was achieved without inheritance... > >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? It does break encapsulation. Whether or not this is desirable is another matter. If you make the distinction between specification and implementation of classes and considder inheritance of specifications as the primary thing then you do want encapsulation. But if inheritance of implementation (including representation) is the primary thing then you dont want encapsulation. Note: You may have both inherritance of specification and inheritance of implementation at the same time, in fact this is what you get by default in nearly all existing oo-languages. The question then becomes what you want to emphasize: the inheritance of an abstract datatype or the inheritance of a concrete datatype ? The programmer implementing a supertype may not be the same person as the programmer implementing the subtype and may not want implementors of subtypes to build in dependencies on, or make assumptions about, the internal representation of the supertype (same arguments as always for encapsulation). Thus, yes the instance contains "instances" of the parent structure, and yes this is totally local to the object, but you may still want encapsulation (or partitioning) internally in the object. If inheritance of specification is the emphasis you may still have default inheritance of implementation. This just means that the implementor of the subtype is liberated of the job of providing the implementation for the supertypes. It does not mean that the implementor of the subtype can "poke arround" in the implementation of the supertype. Anders --------------------------------------------------------------------- Anders Bjornerstedt E-mail: anders@cuisun.unige.ch Centre Universitaire d'Informatique 12 rue du Lac, CH-1207 Geneva --------------------------------------------------------------------- Tel: 41 (22) 787.65.80-87 Fax: 41 (22) 735.39.05 Home: 41 (22) 735.00.03 Telex: 423 801 UNI CH ---------------------------------------------------------------------