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: 11cae8,b87849933931bc93 X-Google-Attributes: gid11cae8,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public From: ell@access5.digex.net (Ell) Subject: Re: What is wrong with OO ? Date: 1996/12/06 Message-ID: <587veh$ng8@news3.digex.net>#1/1 X-Deja-AN: 202604480 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-06T00:00:00+00:00 List-Id: Tom Bushell (tbushell@fox.nstn.ns.ca) wrote: : : Robert C. Martin wrote: : : >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. So then we had the elevation of self-centered hackers, eh? Not that all such plans were good, but the coders should be following some architectural plan 95% of the time. : >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. Are you saying that iterative and incremenatl diagrams are always wrong or that the code generator has problems? Or both? : 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). Contrast this with doing the blueprints for a bridge - the : design effort is orders of magnitude cheaper than the construction. This to me only shows that building software and building bridges are 2 different kinds of building activity. It does not impugn the efficacy of determining sw project analysis and formulating a project architecture. : (Or so I believe - a civil engineer might correct me on this). Also, : the OO design models I've studied don't seem to be very good maps of : actual real world systems - there seems to be a big gap between high : level architecture and running code. I believe there should be a : fairly smooth continuim from high level to low level of detail. This is precisely what the 3 amigos and other OO gurus advocate in their works. : 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. 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 a similar idea to reverse engineering, : but not identical. Ditto my last remark. Cheers, Elliott