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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,c52c30d32b866eae X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public From: donh@syd.csa.com.au (Don Harrison) Subject: Re: Real OO Date: 1996/03/15 Message-ID: #1/1 X-Deja-AN: 142916538 sender: news@assip.csasyd.oz references: <4i455s$ijq@watnews1.watson.ibm.com> organization: CSC Australia reply-to: donh@syd.csa.com.au newsgroups: comp.lang.ada,comp.lang.eiffel,comp.object Date: 1996-03-15T00:00:00+00:00 List-Id: Norman H. Cohen) writes: :In article , donh@syd.csa.com.au (Don Harrison) writes: : :|> Notice what is happening here. Now that Person_Type is distinct, it now becomes :|> more reusable than it was when it was co-encapsulated. By generalising, you have :|> have increased reusability. If you take the process a step further and separate :|> Pairing_Type into a distinct abstraction (because it relates to other domains than :|> family trees), you increase reusability further. If you keep on going, you end up :|> with a pure OO model of the problem domain in which reusability has been maximised. :|> Although the software still does the same job, it is much more reusable with this :|> structure. : :I wish I could remember the author of this quote: "Every problem is a :special case of some more general problem, and we usually discover this :fact much too soon for our own good." : :One may write many different applications all of which have a class named :Person, but these classes may have little or nothing in common. Even if :they all share a Name attribute, it may be more sensible to define a new :class from scratch each time than to burden each application with a :Person class general enough to be shared by all of them. Reusability :pays off for large chunks of software, but the payoff does not scale down :to microscopic fragments. Not so sure about that. A good example is that of the basic types of INTEGER and REAL. In Eiffel, these are explicitly defined as classes offering operations such as '+', '-', '*', '/' (they actually inherit these from other classes) which may be inherited by subtypes such as VELOCITY, DISTANCE etc. which might apply range and other constraints. Clearly, the heavy reuse of these 'micro' classes carries the benefit of their definition at the micro level through to all higher levels. Although such basic types are not explicitly defined as classes in Ada, they are effectively classes because their features are 'inherited' through subtyping and derivation. You wouldn't want to define '+' for every arithmetic abstraction. Maybe, the potential for reuse should be the determining factor. Perhaps, if it is plain that a component of an abstraction will never be needed in it's own right (how can you know), then it may be acceptable not to separate it. However, the potential for sloppy design is obvious - developers would tend to take the expedient path of rarely or never anticipating long term reuse. :I am fully sympathetic with trying to anticipate other uses for the :software components we are building, and trying to make them general :enough to be reused, but generality usually comes at the expense of :efficiency and simplicity, so it can be carried too far. Sometimes there :is a specific problem, such as the recording of a family tree, to be :solved, and the most economical choice is just to go ahead and solve the :problem at hand rather than a broader class of problems that may never :arise. Certainly, in the short term. :True, ignoring reuse can lead to wasteful duplication of effort and more :diffcult and expensive maintenance, but blindly repeating the mantra of :reusability can lead to absurd choices. I firmly believe (but have no concrete evidence to back it up) that development of software characterised by a consistent focus on reuse (by inheritance or composition), will save time within the life of a project and deliver a better quality product. Regretably, many managers fail to recognise this fact and focus too much on short term expediency to the detriment of their staff and clients. :-- :Norman H. Cohen ncohen@watson.ibm.com Don.