SUMMARY: Good Object-Oriented Design

SUMMARY: Good Object-Oriented Design

[sdd.hp.com!wupost!m.cs.uiuc.edu!johnson]

This is in response to the list of replies that Ravi Kalakota
posted to his original message about OO design and maintenance.

Robert Martin's (Uncle Bob's) response was outstanding.  His response
should be standard reading by all software engineers.  Note that
he was talking about DESIGN, not just OO design.  Further, most of
what he said holds true even if you are talking about the design of
bridges or light-bulbs.  Good design is difficult and takes many 
iterations to get right. It is essential to reuse as many ideas from
other people as you can, as long as they work, of course.  The book
"To Engineer is Human" makes this point well.

The advantage that civil engineers and mechanical engineers have
over software engineers is that they build the same things that
other people have been building for years, so they can learn from
their experience in school.  Buildings are much more like each
other than programs are like each other, and we haven't had many
years of experience, so software engineers suffer from a huge
disadvantage compared with other kinds of engineers.

That said, I am not convinced that OOD is any more difficult than
traditional structured design.  Many people think it is is, because
they have spent six months trying to learn OOD and still feel
uncomfortable.  They forget that it took a decade to learn their
original set of design skills and seem to think that they can replace 
them with a new set in a couple of months.  We seem to idealize
our early years.  OOD is different from traditional structured
design, but it is not harder.

>I have been pondering
>over reuse and OO for some time now, and have realized all the features
>of good OO design are almost same as those discussed by Tracz and 
>Biggerstaff, 4-5 years back. The good design must separate the
>context from the content and the concept[Tracz] in a reusable 
>environment and this applies equally well to OO. This raises another
>issue, is OO and Reuse one and the same concept, but packaged differently,
>ie. reuse is the base concept and OO is the vehicle to deliver us from
>evil (structured programming??).

The reason that people are interested in things OO is that they are
hoping it will help them achieve reuse.  Contrary to what Les Degroff
said, OOD does help make software more reusable.  Contrary to what Hugh
LaMaster said, OO is much more than just data abstraction and 
encapsulation, though that is a very important part of OO technology.
The heart of OOD is polymorphism and developing standard interfaces
that you can use to mix and match components.  It is possible to 
implement an OO design in a non-OO language, which is what Les
Degroff might mean, but it is easier when you are using an OO language.

So, you can build a non-reusable OO system, but since the reason you
are going with OO is to build a reusable system, you will probably
consider that a failure.  Thus, OOD implicitely includes design for
reuse because management only chooses OOD when they want reuse, not
because there is a technical reason why OO subsumes reuse.

I missed the comment by Bob Hathaway that chisnall@cosc.canterbury.ac.nz
was responding to.  Composition is *extremely* important in reusable OO
programming, but it is composition of objects, not so much composition
of functions.  It looks like Bob was saying that composition of
functions happens less than composition of objects.  Whether this is
true depends partly on your definition.  If every function that calls
another function is considered a composition of functions then this
is not true, but it certainly is true that the OO designer thinks
primarily in terms of composition of objects, not functions.

Franz Weber had a very nice response about why software evolves.  I'd
like to emphasize his point that new insights are found when you try
to implement software.  In particular, this is common when trying to
make software more reusable.  Trying to reuse software points out the
ways in which it is not reusable, and so points out changes that need
to be made in the design.

He said:
>Generalization is costly. So a question of the design
>process is, what is the optimal effort for generalization.

Documentation is costly.  Making a good user interface is costly.
Making systems efficient is costly.  I suppose you could say the same 
things about any aspect of a system; don't bother to document a part
of the system unless you expect to need the documentation, don't bother 
making the user interface easy to use if only a couple of gurus will 
ever use it, don't bother making software fast if it rarely runs.  In 
the same way, don't bother making software reusable if you aren't going
to reuse it.  I suppose it is all reasonable.

I'd like to argue with one thing that Bob Martin said:

>A good design is also something that no two engineers will agree upon,
>unless they worked together to create it.  (and then only their
>own part will really be good).  

This is amusing, but isn't true.  I've seen several designs by other
people that were obviously strokes of genius, obviously the perfect
design for the job.  In fact, a good design will appeal to a wide
community of people who share similar esthetics of design.  I think
that Bob knows this, because later he talked about the importance of
concensus on the design team.  In fact, I'd say that if you get several
engineers together and they DON'T agree on a design, then the design is
clearly not mature.

Ralph Johnson -- University of Illinois at Urbana-Champaign