Protected "stub" methods used only for overriding purposes considered good practice or not?

Question

Sometimes when I extend one of my own classes, I want to (for the purpose of the subclass) "inject" one or two lines of code in the middle a method in the super class.

In these cases I sometimes add a call to an empty protected method for the subclass to override.

public void superClassMethod() {

    // some fairly long snippet of code

    doSubclassSpecificStuff();

    // some other fairly long snippet of code

}

// dummy method used for overriding purposes only!
protected void doSubclassSpecificStuff() {
}

When doing this several times in the same class I must say it looks quit awkward / ugly so my questions:

1. Is this way of "opening up" for subclasses to "inject" code in the middle of methods considered good practice or not?
2. Is the pattern (anti-pattern?) called something?
3. Has it been used in any well known API / library? (Note that I'm talking about non-abstract classes.)
4. Are there any better alternatives?

---

The only alternative I can come up with is to use something like the command pattern and have a setMiddleOfMethodHandler(SomeRunnableHandler), and call handler.doSubclassSpecificStuff() instead of the dummy-method. It has a few drawbacks as I see it though, such as for instance not being able to touch protected data.

Answer 1

You've just discovered the Template method design pattern. Note though that normally the methods that comprise the individual steps are abstract (rather than empty and protected) so that subclasses must override them.

Answer 2

There is the Template method pattern. The idea there is that much of the work is common, except for a few bits, which are handled by a subclass implemented method.

Answer 3

Yes, this is a legitimate way to do things; I've used it myself.

The only problem I can see is not the specific technique, but the fact that you are using subclasses of concrete (read: non-abstract) classes at all. Subclassing concrete classes has many subtle problems, so I would recommend to avoid it altogether. See e.g. http://en.wikipedia.org/wiki/Liskov_substitution_principle for an explanation of what you must do to properly subclass a class, and the problems involved. Also, in "Effective Java" Block recommends using composition (Item 16).

Another approach (that avoids subclassing) would be to use Dependency Injection. Your method would accept a parameter of a type that implements the interface ISpecificStuff, which specifies a method doSubclassSpecificStuff():

public void superClassMethod(ISpecificStuff specificStuff) {
  ....
  specificStuff.doSubclassSpecificStuff();
  ....
}

That way, any caller can decide what the method should do. This avoids the need for subclassing. Of course, you could inject via a constructor, if you need it in more than one method.