Call Super

Call Super is a minor smell (or anti-pattern if you like) that crops up from time to time in OO frameworks. Its symptoms are pretty easy to spot. You are inheriting from a super-class in order to plug into some framework. The documentation says something like “to do your own thing, just subclass the process method. However it's important to remember to start your method with a call to the super-class”. An example might be something like this.

public class EventHandler ...
  public void handle (BankingEvent e) {
    housekeeping(e);
  }
public class TransferEventHandler extends EventHandler...
  public void handle(BankingEvent e) {
    super.handle(e);
    initiateTransfer(e);
  }
    

Whenever you have to remember to do something every time, that's a sign of a bad API. Instead the API should remember the housekeeping call for you. The usual way to do this is to make the handle method a Template Method, like this.

public class EventHandler ...
  public void handle (BankingEvent e) {
    housekeeping(e);
    doHandle(e);
  }
  protected void doHandle(BankingEvent e) {
  }
public class TransferEventHandler extends EventHandler ...
  protected void doHandle(BankingEvent e) {
    initiateTransfer(e);
  }
    

Here the super-class defines the public method and provides a separate method (often referred to as a hook method) for the subclass to override. The subclass writer now doesn't have to worry his ugly head about calls to super. Furthermore the super-class writer is free to add calls after the subclass method if she wishes.

There are a couple of ways to define the hook method. In this case I've shown an empty implementation. This is useful if many subclasses don't need to provide their own additional behavior. If many subclasses have to do the same thing, you can consider a default implementation, which can also be a template method itself to allow for variation within the common scheme. If every subclass should provide unique behavior, then you can make the hook method abstract in the super-class.

One of the problems with this is that there's usually no way to indicate that a certain method is a hook method, i.e. that it's the one that the framework writer expects to be overridden. You do see conventions (the handle/doHandle is one common one), but mostly you have to explain how it works. One of the best ways to explain it is with an example. When I'm looking at one of these cases I usually find the best thing to do is look at an existing subclass and see what it does.

In this case there's single, and relatively obvious hook method. Often, however, there are many methods, all of which could be hooks, depending on how much control the subclass wants to take. A quick glance at the abstract base class for my HTML layout class shows half a dozen methods that could be overridden. Some subclasses want to do something simple, and override small hooks; others need to do more fancy things and override larger scoped methods.

In some languages you can Seal the handle method to prevent the subclass from overriding it. Since I have an EnablingAttitude, I'm usually reluctant to do this - especially if the inheritance is effectively a published interface. The argument in favor of sealing is that it means that subclasses can't break your super-class. I don't think of overriding the wrong thing as 'breaking the super-class'. The subclass and super-class have to collaborate closely, after all inheritance is a very intimate relationship. Either the whole thing works or it doesn't. Sealing can be a good way to indicate to someone that they are overriding the wrong thing, and as such I'd be inclined to use it for a non-published interface (i.e. the subclasses are part of the same code base). My problem with sealing is that a subclass may want to override the handle call to do something particularly fancy. I can't predict the subclass's needs, so I'd rather say “go ahead, but on your own head be it”, rather than “no”. If it's all one code base then we can always take the seal off if we need to.

public abstract class TestCase
  public void runBare() throws Throwable {
    setUp();
    try {
      runTest();
    }
    finally {
      tearDown();
    }
  }
  protected void setUp() throws Exception {
  }
  protected void tearDown() throws Exception {
  }

public class AlphaTestCase extends TestCase
   protected void setUp() throws Exception {
     alphaProjectSetup();
   }

public class AlphaTestCase  extends TestCase...
  final protected void setUp() throws Exception {
    alphaProjectSetup();
    doSetUp();
  }    
  protected void doSetUp() throws Exception {        
  }

public class AlphaTestCase extends TestCase...
  public void runBare() throws Throwable {
    alphaProjectSetup();
    setUp();
    try {
      runTest();
    }
    finally {
      tearDown();
    }
  }
  protected void setUp() throws Exception {
  }