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

[Alan Lovejoy <alovejoy@concentric.net>]

Bill Gooch wrote:
> 
> Alan Lovejoy wrote:
> >
> > I think you've hit the nail on the head.  I do distinguish between "design" and "coding".
> >
> > To me, the "design" of a program is a language-independent abstraction.  Implementation
> > inheritance is a coding issue....
> 
> I'd like to hear more about how you think design can be done
> independent of language, and what such a "design" would look
> like.  I can see that the most abstract levels of design can
> be language-independent, but refinement from this level is an
> essential aspect (IMO) of doing good design.  Such refinement
> necessarily goes down through layers including language, frame-
> work, database,... dependencies; in fact, it takes into account
> *all* requirements, including hardware constraints.
> 
> If you don't agree that all of this is important in producing
> good designs, then I have a question: what do you call a
> program specification, not involving code, which does take
> these issues into account?

Oh dear.  I think what we have here is merely :-) a terminology problem.

There is a difference between design methodology, the process of producing a design, 
and the result of that process.  Unfortunately, the term "design" (without modifiers)
can be applied to any or all of these things.

Please believe that I am well aware of the fact that one absolutely must take the 
idiosyncracies of the implementation technology (such as the programming language)
into account in desgining and coding a program. I'm sorry that so many people seem
to think I have suggested otherwise!

Any "program specification" that could be used to actually execute a program,
or generate an executable program, is by definition a program text, and the notation
in which it is written is in effect a programming language.

"Programming languages" such as C or Smalltalk are designed so that human beings
find it convenient to write program texts in them, and also so that computer programs
can translate such texts into equivalent programs that execute efficiently on typical 
hardware.

Design notations have a different purpose: to communicate what the design of the
program is to human readers--often ommitting details that should be specified
if the program actually needs to be executed by a computer.  However, those
details should be **optionally** specifiable, so that those cases in which
such details are important at the "design level" can be dealt with there.

My thesis is that a design **methodology** should be able to handle designing
a program regardless of language, although it will certainly need to take the
differences between langauges into account.  If I have to use a completely
different methodology for each part of the system that is implemented in a
different language, something is wrong.

Similarly, the design notation should be flexible enough to handle any and
all implementation languages.  One may use different capabilities of the
notation and/or and specify different designs due to the intended target
language.  But if the notation becomes completely worthless in the face of
an implementation language such as Self, perhaps there is something wrong with 
the notation (and/or its underlying object metamodel) at a fundamental level.

> I think it is impossible to progress very far from a domain
> model into design without considering target language, and
> the other things I've mentioned.  A very abstract design, not
> considering these issues, may be useful some of the time, but
> the design one actually implements *must* consider them.
> 
> > Many seem to think that the class hierarchy **is** the design! ...
> 
> Well, I do not.  But there are many levels of design, and
> it is important to ultimately be specific.

Agreed.  I am reacting to all the times I've seen people start their design process
by drawing class hierarchies.

> > The issues that a design methodology should address with respect to implementation inheritance
> > would be questions such as the following:
> >
> > * Just because two objects have the same behavior may or may not mean that they should
> > inherit the shared behavior.  The methodology should provide the guidance needed to
> > resolve this issue (is the fact that the behavior is the same simply accidental, or
> > does it depend upon some reliable invariant?  How likely is it that a changed requirement
> > will necessitate changing the behavior of one of the objects, but not the other?).
> >
> > * When should delegation be used instead of inheritance?
> >
> > * When should the Strategy pattern be used instead of inheritance?
> 
> I agree that IWBNI methods could help with these things.
> I don't know of any method that even comes close, however.
> This is why design remains largely a black art - not the
> best situation, but it's the way things are.  I'd really
> like to hear from anyone who can suggest how to address
> questions such as the ones Alan has raised here in a
> method(olog)ical or systematic fashion.

Yep.  The methodologists have some work to do.  I think patterns have started the right
things happening in this regard.

> > However, implementation inheritance should be treated as a refinement of the design, not
> > as the body and soul of it.
> 
> From the last, I gather that in some sense, we are in
> agreement.  But again, what do you call this refinement,
> if it isn't another (more specific, closer to code) layer
> of design?

Implementation?  But again, I think we are arguing terminology, not substance.

My practice has been to use the term "design" in way that is apparently more abstract
than those who have read and objected to my posts.  

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|