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: 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: 103376,7f8fc37d854731d6 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,7f8fc37d854731d6 X-Google-Attributes: gid114809,public From: Alan Lovejoy Subject: Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Date: 1996/11/12 Message-ID: <32891BA4.4AA5@concentric.net>#1/1 X-Deja-AN: 196097219 references: <32813322.41C6@kyebek3.kjist.ac.kr> <55pqr5$136a@grimsel.zurich.ibm.com> <328109CD.6685@concentric.net> 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-12T00:00:00+00:00 List-Id: Robert C. Martin wrote: > > 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++. I have to admit that I don't really understand what you mean. Perhaps you could clarify? > > 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. The design/architecture of the **source code** of a program (what you called the "static model" in another post, assuming I understood you) is different than the desgign/architecture of the program as it exists at execution time (what you called the "dynamic model"). As I have used the term "design" in earlier posts, it refers to what you have called the "dynamic model" (assuming I have correctly understood you). My thesis is not that the "static model" is unimportant, but rather that one needs to know what dynamic model one wants to achieve before one can optimally derive a static model. The dynamic model is the heart of the design, because it is where the real work gets done, and because the purpose of the static model is the specification of the dynamic model. You can't implement a good static model that specifies a dynamic model without having a good idea of what dynamic model you intend to specify! That being said, I completely agree that a "flat" class library with no inheritance is not a good idea. I mentioned it solely to highlight the difference between the static and dyanmic models. Finally, this thread started with the claim that there wasn't enough focus on class inheritance in the static model in typical design methodologies. I and some others objected to this, because in our experience typical methodologies don't have sufficient support for handling the dynamic model, and overemphasize static modelling issues such as class inheritance. In view of the OO languages such as Self that don't even have classes, one has to question how central class inheritance (as opposed to type inheritance) really is to even static modelling (not that getting inheritance right is easy, or that getting it wrong is inconsequential). The earlier posts should be interpreted in that context. Bottom line: "Design" involves much more than class hierarchies. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|