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: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,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: 11cae8,b87849933931bc93 X-Google-Attributes: gid11cae8,public From: tbushell@fox.nstn.ns.ca (Tom Bushell) Subject: Re: What is wrong with OO ? Date: 1996/12/12 Message-ID: <32aefdb0.406273038@news.nstn.ca>#1/1 X-Deja-AN: 203752534 references: <32A4659D.347A@shef.ac.uk> <32a5ceba.81462731@news.nstn.ca> <32A885CF.5530@csn.net> <32a98036.46416970@news.nstn.ca> <58lbbo$8kl@news.xmission.com> 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-12T00:00:00+00:00 List-Id: On 11 Dec 1996 03:55:36 GMT, tknarr@xmission.com ( Todd Knarr ) wrote: >I think the problem with formal design goes right to your point #1, >since in most other enginerring disciplines there *isn't* the strong >dichotomy between design and implementation. Guess I wasn't clear about what I meant by "dichotomy". I was referring to the fact that in current practice, the design and the implementation are almost always distinct artifacts. The "design" is a text, drawings, equations, or whatever. The "implementation" is runnable code. Designs are models - static, abstract, incomplete - not usable except as a precursor to implementation. Implementations are dynamic, tangible, detailed - usable in the real world. If you accept this description, then there *is* a dichotomy in most other enginering disciplines as well - the design for a car is the blueprints, mockup, etc. The implementation is the drivable car. This dichotomy may make sense for other engineering disciplines, who must convert the design (which is information, or "bits", to use Negroponte's term) into "atoms". But for software, it's all bits, from design to implementtion! I'm merely speculating that the dichotomy may only exist in software because the disciplines we're thinking about emulating do it that way. Perhaps this is a fundamental mistake, and we need to think of design as an outline, or a scaffold, or a foundation, or whatever other good analogies we can come up with, as opposed to a "model". Perhaps then we will not face so much difficulty and resistance to formal design, because it will become obvious that this is a worthwhile activity. >All too often, though, the "systems analysts" hand me a design document >which I'm supposed to implement which is exactly the programming >equivalent of that 1000-foot single-span stone bridge. This is a very valid point, but in my mind a different issue (although related). In other parts of this thread, we've been talking about the "gap" between design and code - the sense that there's a big leap of abstraction between current design models and implementable systems. I'm not really happy with the way I've explained this, and not even sure I believe my own explanations, but will let it stand until something better occurs to me. -Tom (practicing semantics without a thesaurus _or_ a license) ---------------------------------------------------------- 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 ----------------------------------------------------------