Xref: utzoo comp.lang.c++:6578 comp.object:984 Path: utzoo!attcan!uunet!lll-winken!elroy.jpl.nasa.gov!ames!amdahl!pacbell!hoptoad!hsfmsh!dumbcat!marc From: marc@dumbcat.UUCP (Marco S Hyman) Newsgroups: comp.lang.c++,comp.object Subject: Re: Code Reuse (was Re: Inheritance vs. Composition) Summary: Reuse comes with familiarity Message-ID: <138@dumbcat.UUCP> Date: 21 Feb 90 06:22:37 GMT References: <10465@alice.UUCP> <136@dumbcat.UUCP> Followup-To: comp.object Organization: MH Software, Hayward, Ca. Lines: 55 In article cimshop!davidm@uunet.UU.NET (David S. Masterson) commented on something I said regarding design models You start out trying to follow the right principles but end up satisfying the customer. That is, when the ultimate goal is to ``finish the damn thing and make it work'' you tend to do ``what seems right programmatically.'' with a (version) of the Bill Wulf quote ``More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity'' cimshop!davidm@uunet.UU.NET (David S. Masterson) continued with My message meant to suggest that this seems to be programmers' attitudes to developing an "object-oriented" system, not that programmers were being forced into this mode by (forgive me) "real-world" constraints. The attitude that Marco expresses is a valid one for the programmer on the line, but, when talking about models for inheritance and composition, its too early. While I enjoyed the Bill Wulf quote I don't see how it is applicable to my comments unless ``efficiency'' is the efficiency of getting a product/project done and out the door. Also, it's never to early to think about the ``real-world.'' It is my contention that a design is not finished until the product ships -- if then. Requirements, design and implementation are recursive tasks. All two often a customer will come up with a new, last minute requirement that necessitates a change to the design. When this occurs the design model used is ``how can I make this change with minimum impact on schedule and budget.'' The last concern is ``does this change fit the inheritance model or the composition model.'' Extensible designs are less likely to break under the weight of last minute requirements changes. OO concepts, especially much aligned inheritance, tend to make designs extensible (with practice). Successful designs will tend to be re-used. In an OO environment design re-use leads to code re-use. (Ain't encapsulation, classes, and abstract data types grand.) This all takes time, though. Look at a programmer playing with Smalltalk for the first time. The ones I've seen (including myself) started looking at ``code'' using the browser and then then tried to write some ``code'' of their own. The idea of growing an application by making incremental changes to the existing classes doesn't come until the the programmer becomes familiar with the existing classes. In the case of languages like C++ code re-use wont come until the the second or third project the programmer is on. It will take that many tries just to come up with code worth re-using. I'm off my soap-box. -- // marc {ames,pyramid,sun}!pacbell!dumbcat!marc