Re: Real OO

[donh@syd.csa.com.au (Don Harrison)]

Norman H. Cohen) writes:

: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.

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.