Should You Ever Override Concrete Methods?

A lot of people have pointed out gotchas when overriding concrete classes in Java. For example, properly overriding methods like clone() and equals() can be tricky. (Joshua Bloch's books Effective Java Programming Language Guide and Java Puzzlers: Traps, Pitfalls, and Corner Cases explain the issues better than I can.) In fact, some people recommend that you declare all concrete classes final for this reason.

The same general issue is true for methods. Consider the so-called Call Super anti-pattern. Although I'm thinking of Java at the moment, I don't see any reason why these arguments wouldn't apply in most languages.

Suppose I implement the following base class:

  public class Worker {
    public void start() {
      setup();
    }
    public void finish() {
      teardown();
    }

	private void setup() {...}
	private void teardown() {...}
  }

Now suppose I require anyone who overrides the class and calls start() or finish() to call the super method, e.g.,

  public class SpecialWorker extends Worker {
    public void start() {
	  super();
	  // do something special
	}
	public void finish() {
	  // do something extra special
	  super();
	}
  }

This is considered an anti-pattern because there is no way to force implementers of derived classes to "follow the rules". It is far more reliable to use the Template Method pattern:

  public abstract class Worker {
    public void start() {
      setup();
	  doStart();
    }
    public void finish() {
	  doFinish();
      teardown();
    }

	protected void doStart();
	protected void doFinish();

	private void setup() {...}
	private void teardown() {...}
  }

  ...

  public class SpecialWorker extends Worker {
    protected void doStart() {
	  // do something different
	}
	protected void doFinish() {
	  // do something innovative
	}
  }

This is better because it ensures the correct behavior; setup() and teardown() will always be called and subclasses only have to worry about their unique additions. The only downside is that subclasses must implement all the protected methods, not just override the public methods they might really be interested in changing. I see this as very much analogous to the arguments Michael Feathers blogged about recently on Designing Away Preconditions; using the Template Method makes it harder for users to do the wrong thing.

Sure, there are real-world contingencies when you have to do this:

• You have to subclass an existing class that uses "call super" and you can't refactor the parent class.
• Similarly, you might need to completely change the behavior of a parent class' method. (Make sure you know what you are doing. Will this change violate the contract of the parent-class method? I.e., is the Liskov Substitution Principle violated by your subclass?)

So, given these arguments, I can't think of any examples when it would be a good design to subclass concrete methods. This design constraint seems to be a more useful restriction than making concrete classes final. Am I wrong?

---

!commentForm