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.1 required=5.0 tests=BAYES_05,INVALID_MSGID 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: 114809,7f8fc37d854731d6 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,7f8fc37d854731d6 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,7f8fc37d854731d6 X-Google-Attributes: gid1108a1,public X-Google-Thread: 10461e,7f8fc37d854731d6 X-Google-Attributes: gid10461e,public From: rmartin@oma.com (Robert C. Martin) Subject: Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Date: 1996/11/12 Message-ID: #1/1 X-Deja-AN: 196046375 references: <32813322.41C6@kyebek3.kjist.ac.kr> <55pqr5$136a@grimsel.zurich.ibm.com> <328109CD.6685@concentric.net> organization: Object Mentor Inc. newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.smalltalk,comp.ai Date: 1996-11-12T00:00:00+00:00 List-Id: In article <328109CD.6685@concentric.net>, Alan Lovejoy wrote: > The architecture and design of a program is a function of what **objects** it contains and > how they interact. I disagree. The architecture of a program is a function of the way it manages to decouple the source code while allowing the interactions to remain unaffected. This is true irrespective of language. It is as true in Smalltalk as it is in Java or C++. Whenever one neglects to manage the static relationships between source code units, one winds up in trouble. > 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: This is truer for Smalltalk than it is for Java or C++. But it isn't really even true in Smalltalk. Consider, that the way your two systems are affected by a change in specifications is very different. In the flattened model, the classes can, and must, be changed independently. But in the hierarchical model a change in the middle of a hierarchy affects all those classes that depend upon it. Thus, the design of the heirarchy must take into consideration the most likely changes that will occur; and should strive to minimize the effort involved in making those changes. -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan