Alex is a Software Engineer working on Android development tools, especially Android Studio, at Google. His interests include Java, API design, OOP, IDEs and testing. Alex spends some of his spare time working on Open Source, blogging, writing technical articles, and speaking at international conferences. The opinions expressed here represent his own and not those of his employer. Alex is a DZone MVB and is not an employee of DZone and has posted 49 posts at DZone. You can read more from them at their website. View Full User Profile

An (Overlooked?) Use Case for the Strategy Pattern Part 2: It’s Not About Template Method

02.24.2010
| 3701 views |
  • submit to reddit

As I explained in my previous post, I think there is a use case for the strategy pattern that, in my opinion, we often overlook:

This is what I’ve seen: class A has method x. Just after method x is done doing its thing and before it exits, it calls a (sometimes empty) protected method y meant to be overridden to handle some result or side effect of x (is there a name for this anti-pattern?)

This is the example I used to illustrate this particular case:

/**
* Understands a <code>{@link SecurityManager}</code> that does not allow an application
* under test to terminate the current JVM. Adapted from Abbot's own
* {@code SecurityManager}.
*/
public class NoExitSecurityManager extends SecurityManager {
@Override public final void checkExit(int status) {
if (!exitInvoked()) return;
handleExitRequest(status);
throw new ExitException(concat(
"Application tried to terminate current JVM with status ", status));
}

/**
* Implement this method to do any context-specific cleanup. This hook is provided since
* it may not always be possible to catch the <code>{@link ExitException}</code>
* explicitly (like when it's caught by someone else, or thrown from the event dispatch
* thread).
* @param status the status the exit status.
*/
protected void handleExitRequest(int status) {}
}

 

and the issues with this approach:

Misunderstanding?

Some of the comments, both from this blog and Javalobby’s post, related this anti-pattern with the template method pattern. I respectfully disagree.

Although they may seem similar, the template method pattern and the anti-pattern I described are not the same. Let’s start with the definition of the template method pattern:

Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

The key differentiator is the Single Responsibility Principle. The template method pattern has one job: implement an algorithm. It defers some steps to subclasses, but those steps are part of the class’ main job. On the other hand, the anti-pattern I described provide a method that works as a “hook” that subclasses may want to use for handling some side effect or a result of an operation. The functionality of this “hook” may not be related at all to the original responsibility of the class, ending up with a class that is doing too much.

Of course, the template method pattern can be abused as well: deep hierarchy trees can make code difficult (or impossible) to understand, and the notion of a “single responsibility” can be subjective. What it seems to me like a single responsibility may be seen as multiple responsibilities by others. IMHO, the best ways to prevent these issues are education, lots of practice and having someone else look at our code.

Feedback is always welcome!

From http://alexruiz.developerblogs.com

Published at DZone with permission of Alex Ruiz, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: