[comp.lang.smalltalk] When to make a parent class

uucigj@swbatl.UUCP (3531) (08/31/89)

Please excuse:

1 - the cross posting, the comp.object is not out yet.
2 - me if this was asked before, I just came up against it.

What I have is the following:

I am making a new class and have defined most of the important methods.
Now I look at the classes that are already established and look for some
common functionality.  I find a class (foo) that has almost every thing
that my new class needs except there are several methods that I definitely
do not need in my new class.  

And now my questions: 
	I understand that there is no right answer to this but I would like to
get a general feeling as to what to do with the methods that do not fit my
new class. Do I 1) make my class a sub class and stub out the methods that
don't fit, 2) go above foo and put a new class between foo and its parent
and leave out the methods that I don't need for my class and then sub class
off of this new class, or 3) do something else ?

	Something that I think affects this, is the number of methods that don't
fit.  If you were to do 1 before 2 what is the point that makes you go to
2?

Since this probably has been talked about before (and maybe even flamed),
please e-mail responses.


      Gregg Jensen
   ---------------------------------------------------------------------- 
    These opinions are my own and do not necessarily reflect my companies.
      Southwestern Bell Telephone
      Send E-MAIL to the following address...
               ...!uunet!swbatl!uucigj
   ---------------------------------------------------------------------- 

sakkinen@tukki.jyu.fi (Markku Sakkinen) (09/01/89)

In article <760@swbatl.UUCP> uucigj@swbatl.UUCP (3531) writes:
- ...
-I am making a new class and have defined most of the important methods.
-Now I look at the classes that are already established and look for some
-common functionality.  I find a class (foo) that has almost every thing
-that my new class needs except there are several methods that I definitely
-do not need in my new class.  
-
-And now my questions: 
-	I understand that there is no right answer to this but I would like to
-get a general feeling as to what to do with the methods that do not fit my
-new class. Do I 1) make my class a sub class and stub out the methods that
-don't fit, 2) go above foo and put a new class between foo and its parent
-and leave out the methods that I don't need for my class and then sub class
-off of this new class, or 3) do something else ?
-
-	Something that I think affects this, is the number of methods that don't
-fit.  If you were to do 1 before 2 what is the point that makes you go to
-2?
-
-Since this probably has been talked about before (and maybe even flamed),
-please e-mail responses.

I think this problem has not been overworked here (at least recently),
so it's perfectly worth discussing in the newsgroup.

Solution 2 is recommendable on conceptual grounds: you will then keep
your class hierarchy more close to a true generalisation ("is-a") hierarchy.
However, it may require more work.

I suppose that by 'stub out' in alternative 1 you mean writing dummy
"methods" (in Smalltalk jargon, "member functions" in C++ jargon)
that do nothing or perhaps write an error message at run time if invoked.
Well, C++ and most other current OOP languages offer no way to just
cancel a superclass function in a subclass, but in C++ there is an
alternative that is still much better than "stubbing out":
you can make public (or protected) functions inherited from the
superclass, private in the subclass. Then only other member
and friend functions can call those functions -
and this is checked at compile time!
"Stubbing out" isn't even possible in C++ if the superclass function
has not been declared virtual.

This problem has some connexion with my two most recent postings in this
newsgroup, which recommend not to declare such functions as members
of a class that can be completely impletely upon other public functions
(and public data members) of that class. However, even if this
recommendation had been followed in defining class "foo", you might
want to exclude some "primitive" function of "foo" in your new class,
so the problem remains.

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland

johnson@p.cs.uiuc.edu (09/03/89)

E-mail is definitely NOT appropriate for this topic, which is of
general interest.

>I am making a new class and have defined most of the important methods.
> ...  I find a class (foo) that has almost every thing
>that my new class needs except there are several methods that I definitely
>do not need in my new class.  

>Do I 1) make my class a sub class and stub out the methods that
>don't fit, 2) go above foo and put a new class between foo and its parent
>and leave out the methods that I don't need for my class and then sub class
>off of this new class, or 3) do something else ?

It depends on what you are trying to do.  If you are rapid-prototyping
then you make it be a subclass and ignore the extra methods.  If you are
trying to make an elegant design then you build a new abstract superclass
of the two classes.  This is the standard way of finding abstract classes.

If you just keep subclassing and never reorganize your hierarchy then
you will end up with a very ugly set of classes.  You have to clean things
up periodically to keep your design elegant.

Ralph Johnson

goss@ese.essex.ac.uk (Gossain Sanjiv) (09/03/89)

Article 419 in comp.lang.smalltalk:
From: johnson@p.cs.uiuc.edu
Subject: Re: When to make a parent class
Message-ID: <80500072@p.cs.uiuc.edu>
Date: 2 Sep 89 23:03:27 GMT
References: <760@swbatl.UUCP>
Lines: 24

In a recent article, <80500072@p.cs.uiuc.edu> Ralph Johnson says..

>> I am making a new class and have defined most of the important methods.
>> ...  I find a class (foo) that has almost every thing
>> that my new class needs except there are several methods that I definitely
>> do not need in my new class.  

>> Do I 1) make my class a sub class and stub out the methods that
>> don't fit, 2) go above foo and put a new class between foo and its parent
>> and leave out the methods that I don't need for my class and then sub class
>> off of this new class, or 3) do something else ?

> It depends on what you are trying to do.  If you are rapid-prototyping
> then you make it be a subclass and ignore the extra methods.  If you are
> trying to make an elegant design then you build a new abstract superclass
> of the two classes.  This is the standard way of finding abstract classes.

Dr. Johnson is perfectly correct in what he says here. The process of 
finding abstract classes is not an easy one, but allows one to structure
a class hierarchy in an elegant and, sometimes more importantly,
comprehensible manner.

> If you just keep subclassing and never reorganize your hierarchy then
> you will end up with a very ugly set of classes.  You have to clean things
> up periodically to keep your design elegant.

I think that people who use OO languages, should be aware of the
 need to restructure and "clean up" the hierarchy as more classes are
integrated into it. There is nothing wrong in having to redesign existing
classes in the light of additions to the hierarchy.

Sanjiv Gossain