Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!uwm.edu!mrsvr.UUCP!pet3.uucp!hallett
From: hallett@pet3.uucp (Jeff Hallett x5163	)
Newsgroups: comp.object
Subject: Re: Subclassing vs. subtyping
Message-ID: <1181@mrsvr.UUCP>
Date: 10 Oct 89 19:52:36 GMT
References: <33009@cornell.UUCP>
Sender: news@mrsvr.UUCP
Reply-To: hallett@gemed.ge.com (Jeffrey A. Hallett (414) 548-5163)
Distribution: comp
Organization: GE Medical Systems, Milwaukee,  WI
Lines: 76

In article <33009@cornell.UUCP> wilk@cs.cornell.edu (Michael Wilk) writes:
>The meaning of a subclass is more subtle.  In Smalltalk and CLOS
>(and probably others) a subclass represents a set of objects that
>are extensions of objects in the original class: they have the
>same instance variables and methods, and additional instance
>variables and methods can be added.

Basically, subclasses perform two logical functions:

  1.  The allow for specification of task
  2.  They provide semantic differentiation

Either may (or may not)  require more instance  variables.  Either may
(or may not) require more messages.  

It is possible to have an abstract class.   Such  a class has instance
variables and  defines active messages,  but has no methods and cannot
generate objects.  Its sole  purpose   is to serve    as a  point   of
specification or differentiation in the inheritance tree and act  as a
starting point for the classes that will actually do the work.

>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?


This is true,  but consider  that  a  square is  a  rectangle  with an
additional constraint upon it.  It has every property that a rectangle
has but has  an EXTRA one  - it is  a semantic  specification.  If you
send area! to   a square or  a  rectangle,  you expect  the  area - it
doesn't matter what it is. When you create a square, you also create a
rectangle - it just happens that  this rectangle has all  of its sides
equal.  Note also that a rectangle can be scaled, so scale!  should be
a message to rectangle as well as square.   If  I ask a square for its
height, I expect to get its height, just like any other rectangle.


Subclasses  are   an intuitive device that allow   you  to  modify the
behavior of  the original class  to create  a  more specific  form  or
function.  My  general guideline  for creating  subclasses  is  really
wrapped up in a few questions:

1.  Do  I need something  that  is similar, has  the same data, but is
just a little different?  Y == subclass.

2.  If I write a method and I have to ask the question, "Am I a..." or
"Do I have the property of...", I write a subclass (usually).

3.  Do I have a logical counterpart in  the real world  whose behavior
is  convenient to  model that lives  in an ISA  relationship with some
other class?  Y == subclass.  


--
	     Jeffrey A. Hallett, PET Software Engineering
      GE Medical Systems, W641, PO Box 414, Milwaukee, WI  53201
	    (414) 548-5163 : EMAIL -  hallett@gemed.ge.com
     "Your logic was impeccable Captain. We are in grave danger."