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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,7f8fc37d854731d6 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,7f8fc37d854731d6 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,7f8fc37d854731d6 X-Google-Attributes: gid114809,public X-Google-Thread: 109fba,7f8fc37d854731d6 X-Google-Attributes: gid109fba,public X-Google-Thread: 10461e,7f8fc37d854731d6 X-Google-Attributes: gid10461e,public From: Alan Lovejoy Subject: Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Date: 1996/11/08 Message-ID: <3283BB94.2D82@concentric.net>#1/1 X-Deja-AN: 195374814 references: <32813322.41C6@kyebek3.kjist.ac.kr> <55pqr5$136a@grimsel.zurich.ibm.com> <328109CD.6685@concentric.net> <55v177$ufo@grimsel.zurich.ibm.com> content-type: text/plain; charset=us-ascii organization: Modulation mime-version: 1.0 newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.smalltalk,comp.ai x-mailer: Mozilla 2.01Gold (Win95; U) Date: 1996-11-08T00:00:00+00:00 List-Id: Paul_Gover@uk.ibm.com wrote: > > In <328109CD.6685@concentric.net>, Alan Lovejoy writes: > > ... > >The architecture and design of a program is a function of what **objects** it contains and > >how they interact. What classes these objects may or may not be instances of is a separate > >issue--a fact which becomes obvious in a Self program, for example. What matters is the > >**interface** supported by each object, and the **role** each object plays in the program. > >Note that two objects may support the same interface, but be instances of different > >classes and/or play different roles. > > > >Class inheritance is an abstraction mechanism for code sharing. It has nothing much to do > >with architecture or design of a program. Proof: any program using class inheritance can > >easily be converted into a completely equivalent program where all the leaf classes are root > >classes: one simply duplicates all the inherited methods in each leaf class. > > ... > > Alan, If you restrict your statements above to "architecture" or "analysis" I'd be in > complete agreement. However, I disagree when it comes to design; this might be a > difference in our view of where to separate design from coding. My view is that design > includes implementation detail such as inheritance. I most certainly consider that > "OO development methods" should address it. I think you've hit the nail on the head. I do distinguish between "design" and "coding". To me, the "design" of a program is a language-independent abstraction. Implementation inheritance is a coding issue. It's about how to express the program in a programming notation with the least amount of code duplication and/or the least amount of code changes when requirements change. > I think from your statement about converting to equivalent programs indicates you > consider implementation to be outside the scope of the design (since you describe two > different implementations for the same design); in that case, do you think that > questions of inheritance and so forth are not part of the development method? I think implementation inheritance is overemphasized. Many seem to think that the class hierarchy **is** the design! As I noted in another post: the same class hiearchy may permit the specification of many different programs, each with a different architecture and design. > I think this is dangerous; in your example, the coverted program has large amounts of > duplicated code, so making changes is harder because the programmer has to find all > occurrences of the duplicated code, and we have lost one of the benefits of OO. Hey, I'm not saying that inheritance is not a good thing! Far from it! Yes, the "converted program" has those problems, but I wasn't recommending that programs be coded that way, but rather pointing out that they could be. I was hoping that contemplation of that fact would illuminate the difference between design, class hiararchies and implementation inheritance. The issues that a design methodology should address with respect to implementation inheritance would be questions such as the following: * Just because two objects have the same behavior may or may not mean that they should inherit the shared behavior. The methodology should provide the guidance needed to resolve this issue (is the fact that the behavior is the same simply accidental, or does it depend upon some reliable invariant? How likely is it that a changed requirement will necessitate changing the behavior of one of the objects, but not the other?). * When should delegation be used instead of inheritance? * When should the Strategy pattern be used instead of inheritance? However, implementation inheritance should be treated as a refinement of the design, not as the body and soul of it. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|