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

[Alan Lovejoy <alovejoy@concentric.net>]

Paul_Gover@uk.ibm.com wrote:
> 
> In <328109CD.6685@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> writes:
> > ...
> >The architecture and design of a program is a function of what **objects** it contains and
> >how they interact.  What classes these objects may or may not be instances of is a separate
> >issue--a fact which becomes obvious in a Self program, for example.  What matters is the
> >**interface** supported by each object, and the **role** each object plays in the program.
> >Note that two objects may support the same interface, but be instances of different
> >classes and/or play different roles.
> >
> >Class inheritance is an abstraction mechanism for code sharing.  It has nothing much to do
> >with architecture or design of a program.  Proof: any program using class inheritance can
> >easily be converted into a completely equivalent program where all the leaf classes are root
> >classes: one simply duplicates all the inherited methods in each leaf class.
> > ...
> 
> Alan, If you restrict your statements above to "architecture" or "analysis" I'd be in
> complete agreement.  However, I disagree when it comes to design; this might be a
> difference in our view of where to separate design from coding.  My view is that design
> includes implementation detail such as inheritance.  I most certainly consider that
> "OO development methods" should address it.

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.  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 think from your statement about converting to equivalent programs indicates you
> consider implementation to be outside the scope of the design (since you describe two
> different implementations for the same design); in that case, do you think that
> questions of inheritance and so forth are not part of the development method?

I think implementation inheritance is overemphasized.  Many seem to think that the
class hierarchy **is** the design!  As I noted in another post: the same class hiearchy
may permit the specification of many different programs, each with a different 
architecture and design.

> I think this is dangerous; in your example, the coverted program has large amounts of
> duplicated code, so making changes is harder because the programmer has to find all
> occurrences of the duplicated code, and we have lost one of the benefits of OO.

Hey, I'm not saying that inheritance is not a good thing!  Far from it!  Yes, the "converted
program" has those problems, but I wasn't recommending that programs be coded that way, but
rather pointing out that they could be.  I was hoping that contemplation of that fact 
would illuminate the difference between design, class hiararchies and implementation
inheritance.

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?

However, implementation inheritance should be treated as a refinement of the design, not
as the body and soul of it.

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