Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.object
Subject: Re: programming design methodologies fo
Message-ID: <135300011@p.cs.uiuc.edu>
Date: 17 Oct 89 12:17:00 GMT
References: <910@gorath.cs.utexas.edu>
Lines: 60
Nf-ID: #R:gorath.cs.utexas.edu:910:p.cs.uiuc.edu:135300011:000:3339
Nf-From: p.cs.uiuc.edu!johnson    Oct 17 07:17:00 1989


From jnino@cs.utexas.edu 

>My impression by reading the literature, is that there is no programming
>methodology that has been recognized to be successful, and furthermore
>that there is still need to develop a design methodology adequate for
>OOP applications.

This is an incorrect impression.  People have been building large
object-oriented systems successfully.  This indicates that they must
have some sort of methodology, since large systems cannot be built
successfully without one.  The problem is to determine their methodology.
You can't always find out the methodology that people use by asking them,
they might not understand your question.  Moreover, I think that the
people asking the question might not always understand it, either!

What is a methodology?  A programming methodology is a way of programming.
Smalltalk programmers have a fairly consistent way of building systems,
so there exists a Smalltalk programming methodology.  It is centered around
a number of key ideas.  One is the importance of iteration and revision.
Smalltalk programmers sit down to the keyboard very early in the life
of a project, and some people mistake this for "programming without
thinking".  This is easy to do, because if you ask the programmer whether
he/she is programming, the answer will probably be "yes".  After all,
classes are being created, methods are being written, and often code is
being executed.  However, if you ask the programmer whether the code for
the final product is being written, the answer will be quite different.
The programmer is really doing design, trying to discover the correct
set of classes and how functionality should be distributed among them.
The programmer expects to completely redo the design several times, until
it is right.

Another key idea is the importance of reuse.  It isn't enough for a class
to work, it should be reusable.  There are many particular techniques
for making a design more reusable, but the key point is that revision
and reworking are always necessary.  Each class should be as independent
of other classes as possible, and this is hard to do.

Another key idea is that a computer system should be a simulation
of the design.  The programmer should think of objects as components
of an active system.  This provides a concreteness that makes object-oriented
systems easier to think about.  Note that a computer system is not
necessarily simulating anything out in the real world, so it fine for
objects to correspond to newly invented ideas.

OOP consists of making classes and adding methods to them.  OO design
also consists of making classes and adding methods to them.  Thus, it
is easy to confuse the two.  The difference is in the level of detail
of the methods (the bodies of methods are often ignored during design)
and in the completeness of the class hierarchy, since designers aften
just write a few typical subclasses and assume that the rest will be
similar.

It is true that OOD is quite a bit different from traditional design.
It is also true that it is not written down much.  The people who know
it do it instead of writing about it.  However, since people are successfully
designing object-oriented systems, there must be some "method to their
madness".  The problem is in learning it.

Ralph Johnson -- University of Illinois at Urbana-Champaign