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: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 11cae8,b87849933931bc93 X-Google-Attributes: gid11cae8,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public From: ell@access2.digex.net (Ell) Subject: Re: What is wrong with OO ? Date: 1996/12/05 Message-ID: <585h4i$ero@news3.digex.net>#1/1 X-Deja-AN: 202439233 organization: The Universe followup-to: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.lnag.java,comp.object,comp.software-eng newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.lnag.java,comp.object,comp.software-eng Date: 1996-12-05T00:00:00+00:00 List-Id: Tom Bushell (tbushell@fox.nstn.ns.ca) wrote: : rmartin@oma.com (Robert C. Martin) wrote: : > : >harry@matilda.alt.net.au (Harry Protoolis) wrote: : >> : >> The traditional techniques all suffered from a number of significant : >> flaws. Perhaps the most damaging one was what I (rather unkindly) think : >> of as 'The glorification of idiots' phenomenon. What I mean by this is : >> that projects were typically infested by a group of people who never : >> wrote any software, but spent most of the budget drawing diagrams that : >> the implementors never used. : >Much to my dismay, there are some OO methods that are promoting : >the same scheme. The "analyst" draw nice pretty little diagrams, and : >even run them through simulators to "prove" that they work. These : >diagrams are then run through a program that generates code. Programmers : >who maintain that code generator have to make sure that the "right" code : >is generated. They have to make the program work. : It is my growing opinion that this is a fundamental problem with all : "formal" design methods, not just OO design. The effort involved in : doing the design is as great or greater than doing the construction : (coding). Even if "doing" good OO analysis (drawing "nice pretty little diagram" and *much* more) cost more time and dollars than OO coding, it pays off because doing good OO analysis is generally decisive to the most rapid and Use Case effective development of the project. : I'm starting to believe that design and code don't make sense as : separate entities - the design should _become_ the code - the design : documents for an implemented system are used as the foundation of the : code, and then regenerated from the code. And if you think about it, the only real way for what you call "design" to "become" the code is if a perspective larger than being mainly focused on physical coding *leads* physical coding. : Major benefits would be : that design work would not be discarded because it was too difficult : to bring it up to date with reality. Therefore, the design should : never get out of synch. This is precisely the approach of Booch/Coad/Jacobson/Rumbaugh from what I know about their methods. Physical design and coding is based on/rooted in analysis concepts. Physical design and coding are simply additive to the analysis models. Elliott