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,ec3c42bc0b48f2c9 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,ec3c42bc0b48f2c9 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,ec3c42bc0b48f2c9 X-Google-Attributes: gid1108a1,public From: donh@syd.csa.com.au (Don Harrison) Subject: Re: Real OO Date: 1996/03/15 Message-ID: #1/1 X-Deja-AN: 142916548 sender: news@assip.csasyd.oz references: 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: Jon S Anthony writes: :In article <4i455s$ijq@watnews1.watson.ibm.com> ncohen@watson.ibm.com (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. :> ... :> 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. : :The importance of this observation really cannot be overemphasized. :It is well known, researched and discussed in the reuse literature. Can you suggest some specific papers/articles which convey this position? :Trying to build the one "jumbo general purpose" abstraction for a :particular concept is doomed quite simply because no such thing :exists. About the most you can do is define suites of related :abstractions exhibiting various aspects of commonality and variability :that "you" are interested in with respect to the various related :domains. It is also worth stating that this is _not_ a bad thing. It :may not be a "good" thing either (depending on your temperment). If :you make lots of observations and build various models of the process :and resulting abstraction definitions this fact starts to become :_very_ clear. The fact that the real world is a complex place with many interactions gives credence to this argument. As you suggest, it is only feasible to model the subsets of it we are interested in. I'm unconvinced, however, that a pure OO model is inappropriate for this task. What do pure OO developers have to say about this? - Eiffelers, Smalltalkers? :/Jon :-- :Jon Anthony :Organon Motives, Inc. :1 Williston Road, Suite 4 :Belmont, MA 02178 : :617.484.3383 :jsa@organon.com Don.