Template method pattern

Question

Can anyone let me know some example situations where Template Method - pattern should be used?

Give me some real-world use from your own experience.

(I have so far found it useful only for mapping data in the DA layer. Sorry!!!)

Answer 1

A Template method pattern provides a skeleton for performing any sort of algorithm or an operation, and it allows the sub-classes to re-define part of the logic.

Pros: Natural fit for building frameworks, so that parent framework classes can make callbacks into methods implemented in child.

Examples:

• java.util.AbstractList
• Servlet's doGet and doPost methods
• MDB's onMessage method
• Struts Action class
• Spring's data access classes

Cons: Restricts you to a single inheritance in Java.

Answer 2

I have used the template method for Business Logic where a number of components shared the same process but the implementation was slightly different.

Answer 3

An application of the Template Method pattern has two main characteristics:

1. There is a base class (in Java, one only with protected constructors and optionally declared as abstract) which will be subclassed in client code.
2. There are two groups of methods defined in the base class: a) one or more template methods (typically only one) and one or more primitive operation methods (typically more than one). Each template method represents a high level operation, implemented in the base class itself in terms of the primitive operations, which are meant to be implemented/overriden in each specific subclass. Normally, the template method is public and non-overridable (final, in Java); its API documentation must specify precisely which primitive operation methods it calls, and when (that is, it must describe the "algorithm"). A primitive operation method, which represents a step in the algorithm, should be non-public but overridable (protected, in Java), and can be of two types: a) an abstract method which must be implemented in the subclass; b) a method with a default/empty implementation which may be overriden in the subclass.

One good example in the Java 6 SDK is the execute() method of the javax.swing.SwingWorker class (it is a public final void method). In this case, the primitive operation methods are doInBackground(), process(List), and done(). The first one is abstract and therefore requires an implementation in the subclass; it's called by the template method in a background thread. The other two have empty implementations and can optionally be overriden in the subclass; they are called during and at the end of processing, respectively, in the EDT (the Swing Event Dispatch Thread), to allow updates to the UI.

In my own experience, I have sometimes used this pattern. One such case was a Java base class implementing the java.util.Iterator interface, where next() was the template method and there was only one primitive operation method responsible for instantiating a specific domain entity class (this was meant to be used when iterating over a list of persistent domain entity objects, using JDBC). A better example in that same application was a base class where the template method implemented a multi-step algorithm intended to populate a "business entity maintenance screen" (using Swing) from a given list of persistent entities; primitive operations methods were called to 1) clear the current screen state, and 2) add an entity in a table view inside the screen; optionally, other primitive operations were called from the template method if the screen was editable.

In the end, I must say that although this certainly is a useful design pattern, not so often a situation comes up where it really is applicable. Simply having a base class with methods that get overriden in a subclass (a much more common situation, in my experience) is not enough, by itself, to qualify as an application of the pattern.