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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,7f8fc37d854731d6 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,7f8fc37d854731d6 X-Google-Attributes: gid1108a1,public X-Google-Thread: 10461e,7f8fc37d854731d6 X-Google-Attributes: gid10461e,public X-Google-Thread: 114809,7f8fc37d854731d6 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,7f8fc37d854731d6 X-Google-Attributes: gid103376,public From: Paul_Gover@uk.ibm.com Subject: Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Date: 1996/11/08 Message-ID: <55v177$ufo@grimsel.zurich.ibm.com>#1/1 X-Deja-AN: 195259787 references: <32813322.41C6@kyebek3.kjist.ac.kr> <55pqr5$136a@grimsel.zurich.ibm.com> <328109CD.6685@concentric.net> organization: IBM Warwick Development Group reply-to: Paul_Gover@uk.ibm.com newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.smalltalk,comp.ai Date: 1996-11-08T00:00:00+00:00 List-Id: 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 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 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. Paul Gover IBM Warwick Development Group Mumbling for myself, not IBM