views:

180

answers:

5

Is it better to put a default implementation of a method in a superclass, and override it when subclasses want to deviate from this, or should you just leave the superclass method abstract, and have the normal implementation repeated across many subclasses?

For example, a project I am involved in has a class that is used to specify the conditions in which it should halt. The abstract class is as follows:

public abstract class HaltingCondition{
    public abstract boolean isFinished(State s);
}

A trivial implementation might be:

public class AlwaysHaltingCondition extends HaltingCondition{
    public boolean isFinished(State s){
        return true;
    }
}

The reason we do this with objects is that we can then arbitrarily compose these objects together. For instance:

public class ConjunctionHaltingCondition extends HaltingCondition{
    private Set<HaltingCondition> conditions;

    public void isFinished(State s){
        boolean finished = true;
        Iterator<HaltingCondition> it = conditions.iterator();
        while(it.hasNext()){
            finished = finished && it.next().isFinished(s);
        }
        return finished;
    }
}

However, we have some halting conditions that need to be notified that events have occurred. For instance:

public class HaltAfterAnyEventHaltingCondition extends HaltingCondition{
    private boolean eventHasOccurred = false;

    public void eventHasOccurred(Event e){
        eventHasOccurred = true;
    }

    public boolean isFinished(State s){
        return eventHasOccurred;
    }
}

How should we best represent eventHasOccurred(Event e) in the abstract superclass? Most subclasses can have a no-op implementation of this method (e.g. AlwaysHaltingCondition), while some require a significant implementation to operate correctly (e.g. HaltAfterAnyEventHaltingCondition) and others do not need to do anything with the message, but must pass it on to their subordinates so that they will operate correctly (e.g. ConjunctionHaltingCondition).

We could have a default implementation, which would reduce code duplication, but would cause some subclasses to compile yet not operate correctly if it wasn't overridden, or we could have the method declared as abstract, which would require the author of every subclass to think about the implementation they were providing, although nine times out of ten it would be a no-op implementation. What are the other pros and cons of these strategies? Is one much better than the other?

+4  A: 

One option is to have another abstract subclass, to use as the superclass for all implementations which do want to use the default implementation.

Personally I usually leave non-final methods abstract in an abstract class (or just use interfaces instead) but it definitely depends on the situation. If you have an interface with many methods, and you want to be able to just opt in to some of them, for example, then an abstract class which implements the interface in a no-op way for every method is fine.

You need to evaluate each case on its merits, basically.

Jon Skeet
A: 
Woot4Moo
I am not familiar with an "Interface" (not to be confused with an "interface" which I am familiar with). Can u provide a link?
emory
Please do expand. The only Java interfaces I know of cannot provide any implementations.
Scott
I don't see an `Interface` class anywhere in the API.
Michael Angstadt
@mangst Interface is a java keyword to denote a certain object wherein no method implementations may be provided.
Woot4Moo
Re: expansion. I take it you mean polymorphism i.e. the ability of an object to be treated as if it is a member of another class - typically a superclass. I don't see how this solves the problem of where to put the implementation. Arguably, it's the source of it.
Scott
Scott: I don't mean it to be polymorphism, at least in the purest sense of the term interface. In my example I could see how it is perceived to be polymorphism. In the sense of where to put the implementation isn't really a problem per se as each object should have specialized functionality as needed, however if it is possible to allow an object to represent an interface than obviously that is where the implementation should go.
Woot4Moo
+1  A: 

It sounds like you are concerned about setting that boolean variable when the event happens. If the user overrides eventHasOccurred(), then the boolean variable will not be set and isFinished() will not return the correct value. To do this, you can have one abstract method which the user overrides to handle the event and another method which calls the abstract method and sets the boolean value (see the code sample below).

Also, instead of putting the eventHasOccurred() method in the HaltingCondition class, you can just have the classes that need to handle events extend a class which defines this method (like the class below). Any class that does not need to handle events can just extend HaltingCondition:

public abstract class EventHaltingCondition extends HaltingCondition{
  private boolean eventHasOccurred = false;

  //child class implements this
  //notice how it has protected access to ensure that the public eventHasOccurred() method is called
  protected abstract void handleEvent(Event e);

  //program calls this when the event happens
  public final void eventHasOccurred(Event e){
    eventHasOccurred = true; //boolean is set so that isFinished() returns the proper value
    handleEvent(e); //child class' custom code is executed
  }

  @Override
  public boolean isFinished(){
    return eventHasOcccurred;
  }
}

EDIT (see comments):

final EventHaltingCondition condition = new EventHaltingCondition(){
  @Override
  protected void handleEvent(Event e){
    //...
  }
};
JButton button = new JButton("click me");
button.addActionListener(new ActionListener(){
  public void actionPerformed(ActionEvent actionEvent){
    //runs when the button is clicked

    Event event = //...
    condition.eventHasOccurred(event);
  }
});
Michael Angstadt
That's a nice solution, but not to the problem I have. I'm not worried about access to a particular field - it's ensuring that an event is handled. That might be by setting a flag, or it might be doing something else - starting a timer, for instance. In short, it's entirely implementation-specific.
Scott
What kind of events are we talking about? For example, if the event were a button press, then you would simply call `eventHasOccured()` in the button's `ActionListener` (see edited answer for code example).
Michael Angstadt
The events are fairly arbitrary. An example might be when the program starts processing or a particular stage of processing is reached. They're unlikely to be UI actions. I like the idea of attaching it as an observer before stuffing it down the chain, although it wouldn't be able to survive serialisation.
Scott
I guess I don't really understand your problem. My understanding is that you could simply call eventHasOccurred() whenever the event has happened. For example, in the event of the program starting some processing task like you suggested, you would call this method right before the processing takes place. To make a class serializable, you just have to have it implement the `java.io.Serializable` interface.
Michael Angstadt
+1  A: 

If you are going to put any implementation in the abstract base class, it should be the code for the sub-classes that use the no-op implementation, since this is an implementation that makes sense for the base class as well. If there were no sensible implementation for the base class (e.g., if there was no sensible no-op for the method you're discussing here), then I'd suggest leaving it abstract.

With respect to duplicated code, if there are "families" of classes that all use the same implementation of the method and you don't want to duplicate the code across all classes in the family, you might simply use helper classes per family that supply these implementations. In your example, a helper for classes that pass down the events, a helper for classes accept and record the event, etc.

Steve
+1  A: 

I encountered a similar scenario when I created the basic outline (class hierarchy) of an application I was developing together with others at work. My choice for placing a method abstract (and consequently to force its implementation) was for communication purposes.

Basically the other team mates had somehow to explicitly implement the method and therefore first of all notice its presence and second agree on what they return there, even if it is just the default implementation.

Default implementations in base classes often get overlooked.

Juri
That's a good point.
Michael Angstadt