Xref: utzoo comp.lang.c++:4533 comp.lang.smalltalk:1325 comp.lang.eiffel:385
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!mcsun!sunic!tut!tukki!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: When to make a parent class
Keywords: class levels, parent class
Message-ID: <1257@tukki.jyu.fi>
Date: 1 Sep 89 07:32:24 GMT
References: <760@swbatl.UUCP>
Reply-To: markku@jytko.jyu.fi (Markku Sakkinen)
          SAKKINEN@FINJYU.bitnet (alternative)
Organization: University of Jyvaskyla, Finland
Lines: 57

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