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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: dkenny@actrix.gen.nz (Des Kenny) Subject: Re: Real OO Date: 1996/03/16 Message-ID: X-Deja-AN: 143027802 x-nntp-posting-host: dkenny.actrix.gen.nz sender: news@actrix.gen.nz (System Administrator) references: <4hneps$1238@watnews1.watson.ibm.com> <4i455s$ijq@watnews1.watson.ibm.com> organization: Objective Methods Ltd newsgroups: comp.lang.ada,comp.lang.eiffel,comp.object Date: 1996-03-16T00:00:00+00:00 List-Id: In article <4i455s$ijq@watnews1.watson.ibm.com>, ncohen@watson.ibm.com wrote: > 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. > > 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. > > 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. > > -- > Norman H. Cohen ncohen@watson.ibm.com Large scale reuse benefits from both tools and organisational roles. Customer product development project team(s) are focused on product project milestones, product quality and cost; and the class library architecture team(s) who are focused on longer term benefits and large scale investment. These teams need to work together to achieve the short term objectives of producing a quality product on time and budget and the longer term objective of continuously improving the process of future product development. Developing any item for a variety of product uses is not an easy design task and that is why the class library architecture team have different skills and a longer term focus than the customer product team. These kinds of separations of roles are not unique to software production. In hardware manufacturing engineering there are fitters and turners that use lathes to make a wide range of customer products; then there are other mechanical engineers who design the lathes so that they may be used for product development. In the music area there are violin players that play an almost limitless range of music and then there are the people that design the violins so that the music can be played. Throughout history these types of roles have existed, there have always been tool users and tool makers. Class libraries that have a long life are best built by the tool makers who are generalists and customer products are best built by the tool users who are trying to satisfy a specific customer need. The boundary is not always sharp and it changes over time with experience. There will always be design iterations of the product development and the process used to make the product. Many of the most common constructs are already available in the Eiffel class libraries. These are tools that are readily available. If I am working on a customer product development I first look at the class libraries to see what tools are available for the task at hand. If I can find a suitable set of classes I will consider them first. It may be that they are not all suitable and some extensions and redefinitions are required; which is fine. The experience of this project is then fed back to the class library architects and they consider what , if anything, should be done to the library architecture for future projects. They are focused on the longer term investment and continuous improvement of the production process. So to my way of thinking the work for the classs Family_Tree is almost all done for me; because I have done my homework and studied the Eiffel class libraries carefully. I know, immediately, that the Collection cluster has a number of tree classes which are worth considering. So I can at once get a preliminary sketch of the design: Class Family_Tree[G] inherit Tree[T] ..... ..... end --Family_Tree And depending on the maturity of the class library and the skill of its designers I have a reasonable chance that 80% of my work is done already. Of course, 20%, or so, of the time I have to do more work because there are special circumstances that are not so easily taken care of by the past experience of the class architects. It's not perfect but its pretty good 80% of the time - and that's not a bad thing. It leaves you more time to focus on the harder/novel parts because the well defined parts are done already. This is also nothing new, most other professions : Mathematicians, Scientists, Engineers, Lawyers ... behave like this all the time. Maybe it is an accident of history related to the ease with which software developers can generate millions of lines of source code text at unprecedented speed that they have this illusion that they are always creating something new. They do not need to be economic in generating source text because they seem to have unlimited machine resources at their disposal. Compare this to any other profession in history , before text processors, they had to be economic and reuse what was already done by others because there was simply not enough time to recreate everthing from scratch all over again. So they developed classification systems for Periodic Tables of the elements, for Legal statutes, for Mathematical Algebras, for Physical laws, Engineering designs. No Mathemetician or Lawyer would dream of reinventing anything, unless they had not done their homework! It is just not economic,there isn't time to do it all over again every day! Maybe the text editor and the word processor are our undoing, because we can reinvent the basic structures of almost every application and computer science construct all over again every day! Software developers have just figured out a way to be uneconomic much faster than anyone else. Like in Alice in Wonderland they have found out how to make the world go as fast as they do so they can run faster to stay in the same place. Pretty clever eh! Maybe we need to go back to contemplation of the works of others, as people were compelled to do before text processors, and learn to write less source text not more. And it's good night from him! Cheers Des Kenny Objective Methods Ltd Email: dkenny@actrix.gen.nz