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.6 required=5.0 tests=BAYES_40,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: 103376,7f8fc37d854731d6 X-Google-Attributes: gid103376,public X-Google-Thread: 10461e,7f8fc37d854731d6 X-Google-Attributes: gid10461e,public X-Google-Thread: 1108a1,7f8fc37d854731d6 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,7f8fc37d854731d6 X-Google-Attributes: gid114809,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: 196044276 references: <32813322.41C6@kyebek3.kjist.ac.kr> <55pqr5$136a@grimsel.zurich.ibm.com> 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 , Jan Steinman wrote: > In article <55pqr5$136a@grimsel.zurich.ibm.com>, Paul_Gover@uk.ibm.com wrote: > > > In <32813322.41C6@kyebek3.kjist.ac.kr>, Dong Oh Kim > writes: > > > ... > > >Let me have your opinions about followings: > > > > > > 1. Is everything OK with existing oo development methods? > > > If not, what are needed? and what stage should be enforced in the > > > future,i.e,analysis or design,etc...? > > > ... > > > > OK, here's my 2 cents: most OO development methods concentrate too much > > on objects and too little on classes... > > Gee, in my 8 month experience with one well-known methodology, I felt just > the opposite! It was impossible to model instance-specific behavior > without pretending it was a class. Of course, we might just have been > using it wrong... Objects execute inside computers. They take up memory space and CPU cycles. Classes are source code. They specify the objects and create a structure from which the objects are created. Any method that concentrates on one more than the other is doing a disservice to its inventors and its users. Rather we must focus on both. We generally use dynamic models (i.e object diagrams, interaction diagrams, etc) to specify objects and the way that they interact. We use static models (i.e. class diagrams, package diagrams, etc) to specify classes and the static relationships between them. There is a mapping between the two kinds of models that must be maintained. Every relationship on a dynamic model; that is, ever pathway accross which a message is sent; must be supported by a static relationship in a static model. For example, if object A sends a message to object B, then there must be a class relationship somewhere that supports that. For example, the relationships might be an "aggregation" relationship between the class of A and the class of B. Or it might be an 'association' between one of the base classes of A and one of the base classes of B, etc. Static models, when developed in the absense of dynamic models, cannot be proven correct. They often have missing relationships and unnecesary relationship because the suite of relationships was untested by dymnamics. On the other hand when dynamic models are developed in the absense of static models, the structure of the software is seldom as flexible and maintainable as needed. Opportunities for reuse and robustness are lost. The code becomes interdependent and slowly rots. -- 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