Re: Inheritance Problem in Dynamic/Typeless Language

On Mon, 28 Oct 2002, William Djaja Tjokroaminata wrote:

bill-

> Well, it may occur in C++ programs, but it is not the intention.  Suppose
>
>     derived a;
>     parent  b;
>     parent  c;
>     ....
>     a = b + c;
>
> Assuming that this code compiles and executes, here we are guaranteed that
> the class of a is "derived" (i.e., a will respond to methods that
> are defined for class derived).  There may be some semantic/logic error
> depending on the overloadings of the '+' and '=' operators, but that is a
> separate issue.

i would say it occurs all the time in c++ programs, it's as easy as :

derived *a;
parent  *b;
parent  *c;

further_derived *z;

.....

a = b + c;

all we are guarenteed of, is that 'a' will point to an a, or some subclass of
a, like further_derived, - this knowledge is not available (by inquiry) to use
at compile time, nor at runtime.  i think this a more accurate example since
the pointer is really the only type to use if one wants to consider all of
c++'s object oriented (mis) features...

furthermore ( opinions were solicited earlier right? ;-) ) i would say this type of
coding is not 'good' object oriented coding since, in order to create operator
'+' for the parent class, knowledge of it's descendants was required.  we have
alot of code like this in our shop and it's ____terrible____ to work with.
consider that the header files for the parent class must include the header
file for the derived class, which must include the header file for the parent
class, which must include the header file for the derived class, which must
incl.... (recurse here untill you get sick of it)

it's header file __madness__.  only the preprocessor saves the day.

you even have to maniplulate the build order since there are circular object
dependancies - ouch.


if this doesn't make sense to anyone - try writing this yourself

  class parent;
  class child;

  child parent::operator + (parent anOther);

when splitting the files out into *.h, *.cc files


on a more general note, though many will object, i think subclassing itself
often (always?) violates encapsulation and so it not good object oriented
coding... wait a minute isn't inheritence supposed to be a 'feature' of object
oriented coding?  i guess the point is that sub-classing _usually_ means that
a subclass has intimate knowledge of the guts of it's parent(s) and that can
lead to trouble (as per the examples in this thread).  i have found that,
except in rare cases when coded by very clever programmers, subclassing almost
always introduces subtle bugs, or at least inconsistencies.  this does't mean
it useless - it's just about 47 time more difficult than simply

class Foo < AnOtherClass
....
....

my rule is this :

use Has-A before Is-A whenever possible, when using Is-A -- think long and
hard about it!!


-ara

-- 

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328
 | Email: [e-mail]
 | Phone:  [phone]
 | Fax:    [phone]
 ====================================