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: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 11cae8,b87849933931bc93 X-Google-Attributes: gid11cae8,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: tbushell@fox.nstn.ns.ca (Tom Bushell) Subject: Re: What is wrong with OO ? Date: 1996/12/06 Message-ID: <32a734ab.9786381@news.nstn.ca>#1/1 X-Deja-AN: 202629513 references: <585h4i$ero@news3.digex.net> organization: Telekinetics 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: On 5 Dec 1996 03:56:02 GMT, ell@access2.digex.net (Ell) wrote: >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 agree that formal high level design _should_ pay off, but there is ample anecdotal (as provided by other contributers to this thread) that it doesn't always. Some might argue that this is because the design process wasn't "good", but I wonder if this is just a symptom of a deeper problem with formal design as it is currently practiced. We seem to be modelling the civil engineers - draw the blueprints, then build the bridge, and correct the blueprints "as built". But software is bits, not atoms, and there may be better approaches. >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. Agreed. I picture the design activity as creating some form of outlines and diagrams, which would be successively refined down to the level of running code. But you could "back up" (zoom out?) to the higher levels of abstraction at any point in the development (or maintenance) process. >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. I speak only from knowledge gleaned from magazine articles, but my understanding is that the tools are lacking to provide the outline style views I'm looking for, with the possible exception of Together/C++. IMO, most of these well known methods focus on the wrong things. There seems to be far too much emphasis on inheritance relationships, which is not extremely useful in my experience. I'd be much more interested in tools that allowed me to work with dataflow and side effects on persistant data - at various levels of abstraction. -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ----------------------------------------------------------