Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[David N. Smith <dnsmith@watson.ibm.com>]

In article <3283BB94.2D82@concentric.net> Alan Lovejoy,
alovejoy@concentric.net writes:
>To me, the "design" of a program is a language-independent abstraction.  Implementation
>inheritance is a coding issue.  It's about how to express the program in a programming
>notation with the least amount of code duplication and/or the least amount of 
>code changes when requirements change.


I try to stay out of 'design' discussions for a variety of reasons,
partly because they often have little to do with Design, and partly
because the design-it-and-throw-over-the-wall school of thought seems to
have the same kinds of problems in computing as it has in other fields.
Yet, here is Alan saying these things and somehow I can't resist
commenting. :-)

Many other fields have found that integrating design, engineering, and
manufacturing (into an iterative process) leads to better products,
cheaper products, and products that are easier to maintain. One doesn't
end up with air-conditioners or exhaust manifolds on top of spark plugs,
making a simple job into a half-day or more of work. 

For that matter, Alexander's patterns involve all parts of the job, from
materials all the way to living in the building. A building is not just
designed then dumped on some construction worker to figure out how to
make fit on a lot and which materials to use.

Computer languages differ greatly in how they express algorithms. One
thinks differently in APL than in FORTRAN or Scheme, or in Smalltalk
compared to C. C++ programmers seem to think quite differently than
Smalltalk programmers, having lots of ideas like friend functions, type
hierarchies, templates, and lots more stuff that I find incomprehensibly
unnecessary and totally void of need or interest.  My own biases aside,
the point is simple: Programmers think differently in different
languages. Even Java and C++, two peas in similar pods, foster different
thinking patterns.

I'm not interested in starting a language war. I'm a widely known
Smalltalk bigot (or at least widely know as a Smalltalk bigot :-) and
probably warped beyond any chance of a cure. But when I hear my friend
Alan make such inflammatory statements, My fingers start to itch.

I do not think one can separate design from 'mere' coding, no matter how
grungy one thinks coding to be, nor how lofty one's ideas of Design. One
designs a fiberglass body (and much of the rest of the car) very
differently than a steel body. One designs a stone house in a totally
different way than a frame house. One should design a Smalltalk program
in a different way than a C++ program since there are fundamental
differences in how the languages work and how people think in them when
using them well.

The design of a program should be an integral part of the design of the
implementation of a program which should be an integral part of the
coding of a program. This does not mean there is so separation between
the parts. Car companies still have designers, design engineers,
manufacturing engineers, and assemblers. These people with different
points of view need to work together as partners, with the designer
cognizant of enough of the details of the target language not to get in
too much trouble, and the ultimate programmer cognizant of enough of the
high-level design to understand where it all is going.

Failing to consider the language at design time can leave issues open
that need to be closed. If the designer has learned 'object design' but
has never programmed an object, a condition I fear happens all to often,
is the design suitable for implementation and maintenance in any language?

Please note that I am not saying that it is impossible to implement
designs thrown over the wall from a designer who doesn't consider
language. I am suggesting that such designs can lead to very poor
programs. Since programs are the ultimate product of the whole process,
and it is the program that will be used, lived with, maintained, or
thrown away, it is the program that matters, not the original design. To
the extent that a programmer had to perform heroics to fit a design to a
language, the design has failed and the resulting product is the poorer
for it.

Dave

_____________________________________________
David N. Smith
IBM T J Watson Research Center, Hawthorne, NY
Mailto: dnsmith@watson.ibm.com
Home Page: http://www.dnsmith.com/
_____________________________________________
Any opinions or recommendations are those 
of the author and not of his employer.