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

[Alan Lovejoy <alovejoy@concentric.net>]

Nick Thurn wrote:
> 
> alovejoy@concentric.net wrote 06.11.96:
> >
> > Class inheritance is an abstraction mechanism for code sharing.
> > It has
> > nothing much to do with architecture or design of a program.
> >
> This is a dangerous notion! IMHO those who subscribe to this notion
> should work for "the opposition". :)

But my statement is merely an obvious and intended consequence of information
hiding and object encapsulation.  An object is a "black box."  You're not 
supposed to know or care what the internal mechanisms are that give it its
externally visible properties and behavior--and that includes what class
it may be an instance of, or what behavior it inherits instead of implementing 
locally.

> So what pray tell *is* to do with architecture and design?

Architecture is a question of the division of responsibility among the
objects and subsystems within a system.  It is about the roles that objects
play, the relationships among and interactions between objects, and of how 
objects collaborate to carry out their responsibilities.  Design is the
process of converting a set of requirements into a specification of the
types of objects than can exist and how objects of the specified types
will operate as a system to satisfy the requirements.

> 
> > 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.
> >
> This is wrong.
> 
> It is not "simple" unless the translated program doesn't use polymorphis.
> Where it was used explodes to a mess of conditionals and special cases.
> 
> Polymorphism moves complexity from class clients to the runtime.
> Your "proof" is bogus. An equivalent program cannot be mechanically
> produced by simply copying method implementations as *much* new code is
> required to deal with the dispatch of those methods.
> 
> Think of a program with two sets of interacting objects. The OO version
> has two hierarchys each with a base abstraction that fully describes
> the behaviour of derived objects. The program must deal with two things
> only.
> 
> Remove the polymorphism and what happens? The program must now deal
> with N things everywhere. The complexity increases exponentially with
> the number of new objects and all parts of the program are touched by
> any additional types.

You don't understand.  You are thinking in terms of some statically-typed
language that uses classes as type contraints (such as C++).

In a dynamically-typed language such as Smalltalk, it is syntactically legal 
to send any message to any object.  If the object does not understand the message, 
an error will be reported at run time.

In a statically-typed language that uses interfaces instead of classes as
type constraints (such as can be done in Java), one just needs to define
a hierarchy of interfaces, and then declare each class to be an implementor
of the appropriate interface.  Doing this gets you an otherwise equivalent
program without using any class inheritance at all, and without having
to use any additional switch or if statements.

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