Strategy Design Pattern

1.  Classification
2.  Intent
3.  Motivation
4.  Structure
6.  Examples
5.  Consequences
6.  Sample Code
6.  References
CLASSIFICATION  top
Strategy is a behavioural pattern.
Behavioural patterns help you define the communication between objects in your system as well as the flow of control in a complex program.
 

INTENT  top
Define a family of algorithms, encapsulate each one, and make them interchangeable.
Strategy lets the algorithms vary independently from clients that use it.  [1] 
 

MOTIVATION  top
Strategy offers a better way of managing code with a lot of conditional logic.

Suppose there are many algorithms for doing something within your code.
Drawing a border example: One example would be depending on what you needed drawing a border within your code.

You could write the code for drawing a border depending on maybe a parameter you check within your procedure. Depending on that parameter, you have a switch statement for deciding which algorithm to choose to draw that border. 

// A hypothetical JComponent.paintBorder method

protected void paintBorder(Graphics g) {
   switch(getBorderType()) {
      case LINE_BORDER:   paintLineBorder(g);
                          break;

      case ETCHED_BORDER: paintEtchedBorder(g);
                          break;

      case TITLED_BORDER: paintTitledBorder(g);
                          break;
      ...
   }
}
In the above example [2] , hard-wiring all such algorithms into the classes that require them isn't desirable because:
  • code is more complex with logic to determine which algorithm to choose
  • different algorithms will be appropriate at different times
  • difficult to add new algorithms (or new types of borders to draw)
    because code would need to be modified in multiple spots
Strategy offers a better way of managing your code than to rely on a parameter and a switch statement. With Strategy, you would define classes that encapsulate different algorithms.
 

STRUCTURE  top
.____________________. (strategy)	._________________________.
|      Context       |<>--------------->|       Strategy          |
|____________________|		 	|_________________________|
| 	 	     |		 	| AlgorithmInterface()    |
| ContextInterface() |		 	|_________________________|
|                    |				     |
|____________________|				     |
			   			     |
			   			     |
			    			     |
			   ._________________________^_________________________.
			   |			     |			       |
			   |			     |			       |
		.__________|___________.  .__________|___________.  .__________|___________.
		| ConcreteStrategyA    |  | ConcreteStrategyB    |  | ConcreteStrategyC    |
		|______________________|  |______________________|  |______________________|
		| AlgorithmInterface() |  | AlgorithmInterface() |  | AlgorithmInterface() |  
		|______________________|  |______________________|  |______________________|
 

EXAMPLES  top
An example is the Java AWT Layouts.
The AWT Component instances act as strategy contexts allowing you to set the desired strategy implementation via the setLayout method. Classes BorderLayout, FlowLayout, CardLayout, etc., are concrete strategy implementations. Each of them encapsulates their own algorithm of laying out the components on AWT containers.
 

CONSEQUENCES  top
  • Families of related algorithms. Inheritance can be used to factor out common functionality.
  • An alternative to subclassing the Context.
  • Strategies eliminate conditional statements, particularly switch cases. Code containing many conditional statements often indicates the need to apply the Strategy pattern.
  • Allow choice of implementation.


  • Clients must be aware of different strategies.
  • Communication overhead between Strategy and Context may be high.
  • Increased number of objects.
 

SAMPLE CODE  top
Here are two test Java code examples (using the awt) that simply draw six buttons in a window.

The first example uses the Strategy Design Pattern to apply different formatting to the button layout.
The second example uses a switch statement to draw the buttons with different formatting and layout without Strategy.
 

REFERENCES  top
1.  GOF
     Design Patterns: Elements of Reusable Object-Oriented Software. Reading Mass., Addison Wesley.
     Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1995).
2.   Strategy for success
3.   Programming Patterns Overview