March 2, 2021
Hot Topics:

Working with Design Patterns: Strategy

  • By Jeff Langr
  • Send Email »
  • More Articles »

Some developers hold design patterns up as a lofty standard, an ideal. I've even seen some developers worship patterns so much that they were lax to use them on anything but a high-visibility implementation. On the contrary, many design patterns should really be used fairly frequently, almost to the point where you just think of them as standard programming constructs. Don't put patterns on a pedestal.

In other words, you shouldn't wait for the perfect example. You also shouldn't fear design patterns. Although the original Design Patterns book is daunting, most of the patterns it contains are simple to understand and apply. Many design patterns are so simple that you might find yourself using them every few minutes. Certainly, the iterator pattern falls into this category, but so do patterns such as template method and strategy.

The strategy pattern, according to Design Patterns, says to "define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it [Gamma]." Doesn't sound too tough!

The first thing to remember with patterns is that you must have a need. The first time I code a solution, or part of a solution, I look to keep the implementation as simple as possible. Usually, that means I'm not even thinking about patterns. As I add new code to the current, existing solution, I look for ways to eliminate redundancies, to simplify complex code areas, or to just make the code easier to test. As I look to make these corrections, I'll often recognize that the best approaches to doing so are recognized design patterns. From there, I'll use my knowledge of the pattern to help guide me toward an end goal.

For an example that demonstrates derivation of the strategy pattern, I'll build a portion of an SQL generator. The basic idea is that, given metadata about relational tables and columns, the generator returns an appropriate SQL string. In the spirit of keeping things as simple as they need to be, I'll concentrate on just the piece that generates the values clause for a date column that needs to be inserted.

The application that uses the SQL generator needs to support MySQL, according to my customer. As part of the SQL generator, I need to be able to produce an insert value for MySQL. MySQL expects dates to be formatted in year-month-day order, with each of month and day being two digits.


Here's a test I wrote that specifies the basic functionality needed to support MySQL:

import static org.junit.Assert.*;
import java.util.*;
import org.junit.*;

public class DateColumnTest {
   private static final String NAME = "name";
   private DateColumn column;

   public void initialize() {
      column = new DateColumn(NAME);

   public void create() {
      assertEquals(NAME, column.getName());

   public void insert() {
            Calendar.JULY, 15)));

The code in DateColumnTest uses a simple Date utility method. Here's its code:

import java.util.*;

public class DateUtil {
   private static final Calendar calendar = Calendar.getInstance();

   public static Date createDate(int year, int month,
      int dayOfMonth) {
      calendar.set(year, month, dayOfMonth);
      return calendar.getTime();

The implementation for the MySQL solution is, as you might expect, very simple:

import java.util.*;

public class DateColumn {
   private String name;

   public DateColumn(String name) {
      this.name = name;

   public String insertString(Date date) {
      return String.format("'%1$tY-%1$tm-%1$td'", date);

   public String getName() {
      return name;

I get the MySQL-specific code in place and shipped as part of a complete iteration's work.

In the subsequent iteration, the customer indicates that the application now needs to support Oracle. Unfortunately, the two different database systems each require dates to be formatted differently. So much for compatibility! I've actually had to do something similar in the distant past on a "real" project, which had to be deployed into two separate environments.

Page 1 of 3

This article was originally published on June 13, 2007

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date