Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!newstop!sun!brahmand!grover
From: grover%brahmand@Sun.COM (Vinod Grover)
Newsgroups: comp.object
Subject: Re: Subclassing vs. subtyping
Message-ID: <126043@sun.Eng.Sun.COM>
Date: 9 Oct 89 17:11:52 GMT
References: <33009@cornell.UUCP>
Sender: news@sun.Eng.Sun.COM
Reply-To: grover@sun.UUCP (Vinod Grover)
Distribution: comp
Organization: Sun Microsystems, Mountain View
Lines: 121

In article <33009@cornell.UUCP> wilk@cs.cornell.edu (Michael Wilk) writes:
>This seems to me a programming construct that has no semantic
>correlation to anything outside of programming.  Let us consider
>an example below.  A rectangle is what you think it is; a
>venetian blind is a rectangular geometric figure with additional
>horizontal lines.
>
>     Class RECTANGLE
>          Instance variables HEIGHT, WIDTH
>          Methods HEIGHTEN, WIDEN, AREA
>
>     Class VENETIAN-BLIND
>          Inherit from RECTANGLE
>          Instance variables NUMBER-OF-SLATS
>               (with HEIGHT and WIDTH inherited)
>          Methods CHANGE-NUMBER-OF-SLATS
>               (with HEIGHTEN, WIDEN, and AREA inherited)
>
>In standard object-oriented languages, VENETIAN-BLIND is a
>subclass of RECTANGLE, so that all VENETIAN-BLINDS are
>RECTANGLES.  But ask any high school mathematics teacher if all
>such shapes are rectangles and you'll hear a clear "No."  

This is a classic fallacy.  You are modelling VENITIAN-BLIND as a kind of
RECTANGLE. This model would only provide you with answers that are
consistent with that view, no matter what the reality is, or what
high-school teachers think.

How is it different from the following example ? 

  type THOUGHT is record
      ...
  end record;

  function THINK(T : THOUGHT) return THOUGHT is
     ...
  begin 

     ...

  end;

Just because one uses suggestive names, does not mean that our model
reflects reality!

>                                                          In
>fact, it is quite the opposite:  VENETIAN-BLIND is the more
>general class, as we have a rectangle whenever NUMBER-OF-SLATS
>equals one!  The point to remember is that a rectangle consists
>of four sides *and nothing more*.
>
>One way to resolve this is to say that RECTANGLEs are not the
>quadrilaterals we normally think of, but include any extensions
>so long as its methods are supported in the subclasses.  Thus, we
>should replace the name RECTANGLE with something like
>RECTANGULAR-THING and have two subclasses: VENETIAN-BLIND and
>RECTANGLE (or perhaps STRICT-RECTANGLE) where the latter is
>indeed the simple geometric figure without extensions.
>
Another way to resolve this might be to not use inheritence 
and adopt the view that a VENITIAN-BLIND is an object consisting of a bunch
of rectangles satisfying a certain obvious constraint. 

>But there's nothing to insist that a programmer adopt this
>regimen; subclassing simply doesn't enforce it.  What is more,
>RECTANGULAR-THING cannot generate instances of every object in
>the set of objects it represents; it can generate a STRICT-
>RECTANGLE but not a VENETIAN-BLIND.  
This is the same as the concept of "mixins" in FLAVORS. That is classes that
are not to be used on their own but in combination with other classes. For
example a "window border" cannot be instantiated without combination with
window class. 

>                                     I believe C++ deals with
>this by calling RECTANGULAR-THING an "abstract" class and
>forbidding it from generating any instances at all.  This is an
>understandable but unsatisfactory solution.
I agree, but I believe that imposing strict object-orientation on everything
may yield unreal objects. One example I saw was in Air Traffic Control
System, where an object called  ETHER was introduced to detect collision of
Airplanes. All airplanes would send messages to the ETHER  to indicate their
current positions and other attributes. This implied ACTION-AT-A-DISTANCE. 
Now any physicist will tell you that this is all nonsense. Since the model
was not used to answer "wrong" questions it worked. 

>
>Let us now try to use subclassing to create a class that repre-
>sents a restricted form of an existing class.
>
>     Class RECTANGLE
>          Instance variables HEIGHT, WIDTH
>          Methods HEIGHTEN, WIDEN, AREA
>
>     Class SQUARE
>          Inherit from RECTANGLE ?
>          Instance variables SIDE-LENGTH
>          Methods SCALE, AREA
>
>What happened to inheritance?  It was useless!  Since SQUARE is
>more restricted than RECTANGLE we need *fewer* instance
>variables, not *more* as subclassing allows.  And the HEIGHTEN
>and WIDEN methods that applied to RECTANGLEs make sense only if
>we allow squares to be automatically transformed into rectangles. 
>It seems best to compose the class SQUARE without any references
>to the class RECTANGLE; thus, any relationship between squares
>and rectangles is only in the mind of the programmer.  Perhaps
>that is enough?
>
>My conclusion is that subclassing is a tool for code re-use and
>does not conform to our intuitive understanding of types as sets
>and subtypes as subsets, making it difficult to design classes at
>a conceptual level before actual programming.
>
I dont think so. I think that subclassing (aka inheritence) is useful in
many situaions for modelling real-world objects. Where it leads to
awkwardness one must either live with it or use other methods in
combination. 


Vinod Grover
grover@sun.com