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: 10461e,7f8fc37d854731d6 X-Google-Attributes: gid10461e,public X-Google-Thread: 114809,7f8fc37d854731d6 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,7f8fc37d854731d6 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,7f8fc37d854731d6 X-Google-Attributes: gid103376,public From: rmartin@oma.com (Robert C. Martin) Subject: Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Date: 1996/11/20 Message-ID: #1/1 X-Deja-AN: 197600644 references: <32813322.41C6@kyebek3.kjist.ac.kr> <55pqr5$136a@grimsel.zurich.ibm.com> <328109CD.6685@concentric.net> <32891BA4.4AA5@concentric.net> organization: Object Mentor Inc. newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.smalltalk,comp.ai Date: 1996-11-20T00:00:00+00:00 List-Id: In article <32891BA4.4AA5@concentric.net>, Alan Lovejoy wrote: > 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? Sure. Imagine a program that trasmits files between computers using modems. That program could deal with lots of different kinds of modems in several different ways. It could use a switch statement every time it needed to interact with a modem, choosing the correct modem each time and executing the right code. Or it could create an abstract Modem class and then create derivative for each type of modem. In the first example, adding a new modem means ripping through all the code and finding every place where there is a switch statement and adding the new modem to it. In the second example, adding a new modem is a easy as writing a new derivative class of Modem. On the other hand, if we need to add a new function to all the modems, then in the first example, all we have to do is add a switch statement, but in the second example, we must modify the abstract modem class and all its derivatives. This is an architectural choice; and it is based upon which kind of change is more likely. If it is more likely that new functions will be added to existing modems, then the switch statement is probably the better choice. If it is more likely that new kinds of modems will be added, then the class structure is probably better. The point is that the interactions between the program and the modems remain identical regardless of which architecture you choose. The architecture is strategy for decoupling the source code so that changes are easily made. > 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! Damn straight! Static models are meaningless without dynamic models to justify them. By the same token, dynamic models are fantasies without static models to support them. Both are important. Neither can stand alone. One cannot create a static model without a decent dynamic model. But by the same token, one cannot create a realistic dynamic model without it being constrained by a good static model. -- 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