Re: Designing Classes, needing stubs

[glen e. p. ropella]

Try putting this in your abstract class

- handleProblem 
{
  [self subclassResponsibility: @selector(handleProblem)];
    return self;
}


At 03:38 PM 5/17/99 -0500, you wrote:
>
>I came across an issue yesterday and I suppose people who design OO
>software must face it all the time, but for a moment I was surprised and
>made a note to ask about it.   What do you do when a superclass has a
>method that includes calls to other methods that are implemented in the
>subclasses?  I found myself creating hollow (call it a stub?) methods in
>the superclass to stop the compiler from complaining.
>
>Let me explain.
>
>There is a class A.  Instances of A are never created, rather there are
>subclasses B and C.  B and C have specialized implementations of a
>method, say we call it handleProblem.    All of the other things that B
>and C do are inherited from A.  A does not have a handleProblem method.
>
>In the class A, there is a "step" method that outlines a number of
>things to do, and one of them is [self handleProblem].   This step
>method is called from ModelSwarm in the usual way, it tells each agent
>to do a series of actions.  The "step" method is defined in the
>superclass A, and there is no need to specialize it in B and C.
>However, when I try to compile, I get the understandable compiler
>warning that class A does not respond to handleProblem.   However, since
>I never create any objects of class A, only the subclasses B and C, the
>warning is not important.
>
>To make it go away, the only thing I could think of was to put a stub in
>A for the -handleProblem method, and then have the specialized actions
>in B and C override.  Good, bad, or indifferent?
>
>--
>Paul E. Johnson                       email: address@hidden
>Dept. of Political Science            http://lark.cc.ukans.edu/~pauljohn
>University of Kansas                  Office: (785) 864-9086
>Lawrence, Kansas 66045                FAX: (785) 864-5700
>
>
>
>
>                  ==================================
>   Swarm-Support is for discussion of the technical details of the day
>   to day usage of Swarm.  For list administration needs (esp.
>   [un]subscribing), please send a message to <address@hidden>
>   with "help" in the body of the message.
>


--
glen e. p. ropella                =><=          Hail Eris!
Home: http://www.trail.com/~gepr/home.html  (505) 424-0448
Work: http://www.swarm.com                  (505) 995-0818  

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.