provided by: 
Originally published at Internet.com Design patterns are powerful tools. Powerful tools always present the potential for misuse. If we're not careful, we could chop off a leg or glue our code together into a stick mess. Template Method is a design pattern that presents one solution for eliminating common duplication between two or more related classes. It is one of the twenty-three patterns demonstrated in the book Design Patterns (1995, by Gamma, et. al.).
You're best off treating Template Method as a refactoring goal. In this article, you'll step through an example that shows how to manipulate code to meet that goal. Instead of talking about what Template Method even is, we'll just refactor and talk about the results when we're done.
For this example, we're building a rule-based workflow system for managing scanned forms. The first rule we tackle requires that the state supplied on a form match the state passed in as an argument. The class CheckStateRule implements the Rule interface:
import java.util.*; public interface Rule { boolean eval(Case c, List val, boolean returnTrue); } The workflow system executes rules. Executing a rule can move forms through the workflow.
The CheckStateRule code is fairly straightforward. The rule engine passes a Case object, a list of arguments, and a negation flag to the eval method. The Case indirectly contains form data. The switchReturnValues method, a slightly confusing bit, flips the result of the rule if someone has configured it in the workflow system to be negated.
import java.util.*; /** * * Check if the state the case is located in is equal to argument passed in. */ public class CheckStateRule implements Rule { private static final String EXCEPT = "Exception: "; String errStr; boolean hasMissingData; public boolean eval(Case c, List val, boolean returnTrue) { boolean returnVal = false; String argVal = null; try { if (val == null || val.size() != 1) { errStr = "Can't convert value list to a state"; hasMissingData = true; return false; } else { argVal = (String)val.get(0); } // get the location object off the form and get the state the // case resides in Location loc = (Location)c.getFormComposite("location"); if (loc == null) { errStr = "Cannot determine the state this case is located in."; hasMissingData = true; return false; } String st = loc.getAttribute("state"); String state = (st == null ? null : st.toUpperCase()); if (state == null) { errStr = "Cannot determine the state this case is located in."; hasMissingData = true; return false; } else if (state.equals(argVal)) { returnVal = true; } // return value List
As soon as we get CheckStateRule working, we begin work on a second rule, CheckDependentsRule. The job of this second rule is to ensure that each dependent specified on the form has both a first and last name.
import java.util.*; /** * * Ensure all dependent detail is supplied */ public class CheckDependentsRule implements Rule { private static final String EXCEPT = "Exception: "; private String errorMessage; private boolean missingData = false; public boolean eval(Case c, List val, boolean returnTrue) { boolean returnVal = false; try { // get the location object off the form and get the state the // case resides in Subscriber sub = (Subscriber)c.getFormComposite("subscriber"); if (sub == null) { errorMessage = "Unable to obtain subscriber info."; missingData = true; return false; } returnVal = true; for (int i = 1; i <= Subscriber.DEPENDENT_ROWS; i++) { if (!hasCompleteDependentName(sub, i)) { returnVal = false; break; } } boolean returnVal1 = returnVal; if (!returnTrue) returnVal1 = !returnVal1; String retErrStr = null; if (returnVal1 == false) { if (returnTrue) retErrStr = "Dependent info incomplete"; else retErrStr = "All dependent info provided"; } List
The two rules, CheckDependentsRule and CheckStateRule, appear to have some similarities. Chunks of the eval method are the same, and a few supporting methods appear to be the same. We want to eliminate the redundancies between these two classes, which should reduce our risk and future maintenance costs.
Should we use delegation or inheritance? Normally I prefer to start by considering delegation, as it doesn't introduce as-strong dependencies. Delegation is ideal when we need to re-use common constructs and logic. But in this case, our two classes are behaviorally related. Both share the same goals and behaviors. We'll create a common class, BaseRule, and slowly pull common functionality up into it.
As the first step, we simply create an empty superclass and have both Rule classes extend it. We then, naturally, run our tests. public class BaseRule { } public class CheckStateRule extends BaseRule implements Rule { ... public class CheckDependentsRule extends BaseRule implements Rule { ...
If we look at CheckDependentsRule, the last chunk of code in the try block appears to replicate the functionality in CheckStateRule's switchReturnValues method.
boolean returnVal1 = returnVal; if (!returnTrue) returnVal1 = !returnVal1; String retErrStr = null; if (returnVal1 == false) { if (returnTrue) retErrStr = "Dependent info incomplete"; else retErrStr = "All dependent info provided"; } List
At this point we can visually inspect the two switchReturnValues methods and see if they indeed contain the same logic. Since we have good unit tests, we can spend only a little bit of time on this comparision, enough to get a good warm fuzzy. The real answer comes by trying to eliminate the redundancy: We pull one of them up to the BaseRule superclass (run tests), and eliminate the other (run tests again). All remains green.
import java.util.*; public class BaseRule { protected List
Getting rid of duplication often involves making things look the same. In both rule classes, we have a hasMissingData> flag. We also have a String field that appears to hold an error message, but its name is different. We rename the field in CheckStateRule from errStr to errorMessage (and run tests). We also make both fields private in CheckStateRule, since they are both private in CheckDependentsRule. We run our tests. We do the same thing with the hasMissingData/missingData fields.
Once we complete the preparatory work of making things look the same, we pull up both the fields and their accessor (getter) methods to BaseRule. We make the fields protected instead of private. This is perhaps a questionable design decision, but we can look to correct it once the rest of our current refactoring is complete. We verify that our tests still pass.
One more simple refactoring: both classes define an EXCEPT constant. We pull this definition to the superclass and eliminate from both subclasses.
Now the fun work begins. The eval method is still a bit long. But if we look at the structure of the eval method within the CheckStateRule, we note that it has the following policy: * extract arg values * extract form data * execute rule * prepare return values, negating if necessary * handle any trapped exception from the above three steps as a rule failure
CheckDependentsRule has pretty much the same structure, except that it doesn't extract any argument values. Starting with CheckStateRule, we break up the function into method calls that correspond to this policy.
import java.util.*; /** * * Check if the state the case is located in is equal to argument passed in. */ public class CheckStateRule extends BaseRule implements Rule { private String argVal; private String formState; public boolean eval(Case c, List val, boolean returnTrue) { try { return evalWithThrow(c, val, returnTrue); } catch (Exception e) { errorMessage = BaseRule.EXCEPT + e.getMessage(); hasMissingData = true; return false; } } private boolean evalWithThrow(Case c, List val, boolean returnTrue) { if (!extractArgs(val)) return false; if (!extractFormData(c)) return false; boolean returnVal = executeRule(c); return prepareReturnValues(returnTrue, returnVal); } private boolean extractFormData(Case c) { // get the location object off the form and get the state the // case resides in Location loc = (Location)c.getFormComposite("location"); if (loc == null) { errorMessage = "Cannot determine the state this case is located in."; hasMissingData = true; return false; } String st = loc.getAttribute("state"); formState = (st == null ? null : st.toUpperCase()); if (formState == null) { errorMessage = "Cannot determine the state this case is located in."; hasMissingData = true; return false; } return true; } private boolean prepareReturnValues(boolean returnTrue, boolean returnVal) { List
The methods eval and evalWithThrow provide the definitions of policy. Of course we make these changes incrementally. We also make typical simple mistakes along the way. Running the tests continuously keeps these mistakes from getting buried and becoming a big nuisance.
We can now pull up the eval and evalWithThrow policy methods to BaseRule. That creates complie errors. In order to get BaseRule compiling, we create stubs for things that are specific to CheckStateRule (for example, extractFormData). We change the stubs to protected in both BaseRule and CheckStateRule. Tests still run.
public boolean eval(Case c, List val, boolean returnTrue) { try { return evalWithThrow(c, val, returnTrue); } catch (Exception e) { errorMessage = BaseRule.EXCEPT + e.getMessage(); hasMissingData = true; return false; } } private boolean evalWithThrow(Case c, List val, boolean returnTrue) { if (!extractArgs(val)) return false; if (!extractFormData(c)) return false; boolean returnVal = executeRule(c); return prepareReturnValues(returnTrue, returnVal); } protected boolean prepareReturnValues(boolean returnTrue, boolean returnVal) { return false; } protected boolean executeRule(Case c) { return false; } protected boolean extractFormData(Case c) { return false; } protected boolean extractArgs(List val) { return false; }
In the next step, we convert the stub methods into abstract methods (which makes BaseRule abstract). Each such change causes compile errors in CheckDependentsRule. Rather than declare all methods abstract simultaneously, which would generate more than a few minutes work before we could see a green bar, we do them one at a time.
Finally, when done, we take a bold step and delete the eval method in CheckDependentsRule. Our resulting code:
import java.util.*; /** * * Ensure all dependent detail is supplied */ public class CheckDependentsRule extends BaseRule implements Rule { private Subscriber sub; @Override protected boolean prepareReturnValues(boolean returnTrue, boolean returnVal) { List
The final version of BaseRule:
import java.util.*; abstract public class BaseRule { protected String errorMessage; protected boolean hasMissingData = false; static final String EXCEPT = "Exception: "; protected List
Author: Jeff Langr
Read article at Internet.com site