Re: Real OO

[dkenny@actrix.gen.nz (Des Kenny)]

In article <4i455s$ijq@watnews1.watson.ibm.com>, ncohen@watson.ibm.com wrote:

> In article <Do3F1K.4xG@assip.csasyd.oz>, 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