Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.object Subject: Re: Code Reuse (was Re: Inheritance vs. Composition) Message-ID: Date: 22 Feb 90 19:18:10 GMT References: <10465@alice.UUCP> <136@dumbcat.UUCP> <138@dumbcat.UUCP> Sender: davidm@cimshop.UUCP Followup-To: comp.object Organization: Consilium Inc., Mountain View, California. Lines: 66 In-reply-to: marc@dumbcat.UUCP's message of 21 Feb 90 06:22:37 GMT In article <138@dumbcat.UUCP> marc@dumbcat.UUCP (Marco S Hyman) writes: [...comments on my comments about his comments...] [.... ??? ^^^^ is that recursive ^^^^ :^) ....] 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. Exactly. 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.'' I agree. This is where the "programmer on the line" makes his money. That is, he has to understand and balance the constraints of time and money with what he might feel is the more "theoretical" right thing to do. The question/point I'm driving toward is not what that "programmer on the line" must theoretically sacrifice in order to "get the job done", but more of what the model is that he would start with in his evaluation of the project (namely, the OO model). My contention is that the design model that you are expressing above is not an Object-Oriented model, but more of a "produce by whatever means" 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.) The questions here are: 1. What was the object-oriented model you began with in your design and why? 2. What did practice teach you was wrong with that model? 3. What is the definition of "re-use"? This all takes time, though. True, as it is true with any other modelling system. However, an understandable and complete model helps to cut down this time. The producer of a product is far too worried about "getting it done" to be worried about using a design model that doesn't answer all his questions about the project. From what I've seen (and, admittedly, I'm no expert), the OO model for problem solving seems somewhat haphazard in its application because of incompleteness in people's "working" definition of what it is. This can be disconcerting to the "programmer on the line" who has to apply OO to his product because its the new industry buzzword (which seems to be a big reason for its use) and not because understands why it should be used. I'm off my soap-box. Me too, but soap-boxes are such fun objects to play with... 8^) -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"