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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public From: pcg@aber.ac.uk (Piercarlo Grandi) Subject: Re: What is wrong with OO ? Date: 1996/12/05 Message-ID: X-Deja-AN: 202577730 sender: pcg@osfb.aber.ac.uk references: <32A4659D.347A@shef.ac.uk> <32a5ceba.81462731@news.nstn.ca> organization: Prifysgol Cymru, Aberystwyth newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1996-12-05T00:00:00+00:00 List-Id: >>> "tbushell" == Tom Bushell writes: tbushell> On Wed, 04 Dec 1996 08:45:22 -0600, rmartin@oma.com (Robert tbushell> C. Martin) wrote> >> harry@matilda.alt.net.au (Harry Protoolis) wrote: harry> The traditional techniques all suffered from a number of harry> significant flaws. Perhaps the most damaging one was what I harry> (rather unkindly) think of as 'The glorification of idiots' harry> phenomenon. What I mean by this is that projects were typically harry> infested by a group of people who never wrote any software, but harry> spent most of the budget drawing diagrams that the implementors harry> never used. But such people are not at all idiots: they are usually the cleverest people on the project, from many points of view, especially self-interest. :-) rmartin> Much to my dismay, there are some OO methods that are promoting rmartin> the same scheme. The "analyst" draw nice pretty little rmartin> diagrams, and even run them through simulators to "prove" that rmartin> they work. These diagrams are then run through a program that rmartin> generates code. Programmers who maintain that code generator rmartin> have to make sure that the "right" code is generated. They rmartin> have to make the program work. Both of these observations seem to me rather realistic, from direct and indirect observation of actual projects. tbushell> It is my growing opinion that this is a fundamental problem tbushell> with all "formal" design methods, not just OO design. This is in part what has made formal methods (as in correctness proofs/verification) rather less popular than perhaps they should be: the ``formal'' bit is as large as, and usually as unreliable as, the ``informal'' bit of a project (getting a specification or a proof right is often about as hard, and sometimes harder, as getting the program itself right) tbushell> The effort involved in doing the design is as great or greater tbushell> than doing the construction (coding). That's quite well often the case -- now, if the design was _useful_, then that would not be a problem. Unfortunately analisyses or designs are often rather dramatically decoupled from each other and implementation, for both technical and sociological (for example inane adherence to the waterfall model) reasons, and so that effort is usually largely wasted. *If* analisys and design efforts were conducted in resonance with each other and implementation, then spending more effort on those than coding would be all fine and actually rather useful, for formulating solutions in more abstract terms usually makes them easier to maintain and modify. tbushell> Contrast this with doing the blueprints for a bridge - the tbushell> design effort is orders of magnitude cheaper than the tbushell> construction. (Or so I believe - a civil engineer might tbushell> correct me on this). It is usually _cheaper_, but on the other hand it might take _longer_. Developing and then ``debugging'' a bridge design is a long and difficult process, that involves a large number of considerations in different fields, from economics to demographics to aestetics. tbushell> Also, the OO design models I've studied don't seem to be very tbushell> good maps of actual real world systems - there seems to be a tbushell> big gap between high level architecture and running code. I tbushell> believe there should be a fairly smooth continuim from high tbushell> level to low level of detail. Why? tbushell> I'm starting to believe that design and code don't make sense tbushell> as separate entities - the design should _become_ the code - tbushell> the design documents for an implemented system are used as the tbushell> foundation of the code, and then regenerated from the code. tbushell> Major benefits would be that design work would not be tbushell> discarded because it was too difficult to bring it up to date tbushell> with reality. Therefore, the design should never get out of tbushell> synch. This a similar idea to reverse engineering, but not tbushell> identical. This seems a bit fuzzy as a description, but reminds me of the ``corroboration'' approach from Dijkstra to program correctness: if one develops programs using methodical techniques _starting_ from their ``proof'', then the correctness of the program is highly corroborated by such a process. tbushell> If anyone has knows of tools that would facilitate this tbushell> approach, I'd certainly be interested. I've done some very tbushell> simple prototypes, and hope to work on the idea in future tbushell> (when I have more time - Hah!). But OO is in large part about this: the ``high level'' modules/classes/prototypes are supposed to capture the essence of the design. Pointing some sort of OO program browser to a program source and removing from the picture the lower levels of abstraction *ought* to reveal the design. This *ought* to be the case with structured programming methods in general, and with OO in particular it should be even more pleasant because of the disciplined modularization of the program it entails.