I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Design Patterns Uncovered: The Strategy Pattern

  • submit to reddit

Having focussed on the two factory patterns over the last week, today we'll take a look at the Strategy Pattern, a useful pattern in changing algorithm implementations at runtime, without causing tight coupling.

Strategy in the Real World 

To explain the strategy in the real world, let's take the example of a software developer. If language isn't an issue I might ask a developer to write a piece of code for me to create a user interface. One developer's chosen language is Java, so he'll develop the UI with Swing. Meanwhile, the other developer decides to use C#. I don't mind, I've left the details of how to write the UI to the developers, and both have applied their own strategy. At any stage, the developer chould change their strategy, choosing to use a different language if they feel it's necessary. It's all about dynamically changing behaviours.

Design Patterns Refcard
For a great overview of the most popular design patterns, DZone's Design Patterns Refcard is the best place to start. 

The Strategy Pattern

The Strategy pattern is known as a behavioural pattern - it's used to manage algorithms, relationships and responsibilities between objects. The definition of Strategy provided in the original Gang of Four book on Design Patterns states: 

Defines a set of encapsulated algorithms that can be swapped to carry out a specific behaviour

Now, let's take a look at the diagram definition of the Strategy pattern.

In the above diagram Context is composed of a Strategy. The context could be anything that would require changing behaviours - a class that provides sorting functionality perhaps. The Strategy is simply implemented as an interface, so that we can swap ConcreteStrategys in and out without effecting our Context. 

Let's take a look at how some client might put the Strategy pattern into action: 



Use of the Context from the client may vary - your client could tell the Context which strategy it would like to use, or the Context could decide on behalf of the client.  In my opinion, it's better to leave this decision to the Context, as it removes the type switch statements that we saw in our Factory patterns. 

Where Would I Use This Pattern?

The Strategy pattern is to be used where you want to choose the algorithm to use at runtime. A good use of the Strategy pattern would be saving files in different formats, running various sorting algorithms, or file compression.

The Strategy pattern provides a way to define a family of algorithms, encapsulate each one as an object, and make them interchangeable.  

So How Does It Work In Java?

Let's use the example of a file compression tool - where we create either zip or rar files. First we'll need a strategy: 

//Strategy Interface
public interface CompressionStrategy
public void compressFiles(ArrayList<File> files);

And we'll need to provide our two implementations, one for zip and one for rar

public class ZipCompressionStrategy implements CompressionStrategy

public void compressFiles(ArrayList<File> files)
//using ZIP approach

public class RarCompressionStrategy implements CompressionStrategy

public void compressFiles(ArrayList<File> files)
//using RAR approach


Our context will provide a way for the client to compress the files. Let's say that there is a preferences setting in our application that sets which compression algorithm to use. We can change our strategy using the setCompressionStrategy method in the Context.

public class CompressionContext
private CompressionStrategy strategy;

//this can be set at runtime by the application preferences
public void setCompressionStrategy(CompressionStrategy strategy)
this.strategy = strategy;

//use the strategy
public void createArchive(ArrayList<File> files)



It's obvious that all the client has to do now is pass through the files to the CompressionContext

public class Client

public static void main(String[] args)
CompressionContext ctx = new CompressionContext();
//we could assume context is already set by preferences
ctx.setCompressionStrategy(new ZipCompressionStrategy());
//get a list of files



Other Articles in This Series
The Observer Pattern
The Adapter Pattern
The Facade Pattern
The Factory Method Pattern
The Abstract Factory Pattern
The Singleton Pattern
The Strategy Pattern
The Visitor Pattern

Next Up

We've got through 7 of the 23 GoF patterns, so there's still a bit to go in this series. Next we'll be looking at the Visitor pattern, followed the the Proxy pattern. 



jawed ahmed replied on Tue, 2010/03/02 - 1:06am

good work!!!

Jakob Magiera replied on Tue, 2010/03/02 - 5:50am

I never understood what is unique about this pattern. How is it different from any interface with runtime-configured implementation?

Aamir Iqbal replied on Tue, 2010/03/02 - 8:20am

Dear James,

                i appreciate your effort. Your post is very helpful. specially when you use code (java)  with so simplicit, it really helps me out.

       Good work. Keep on Posting such kinds of Articles.




James Sugrue replied on Wed, 2010/03/03 - 3:01am in response to: Jakob Magiera

The thing with a lot of patterns is that they're not new approaches to problems, but rather proven solutions to particular scenarios. So, like Observer, Strategy is one of those patterns that you may have been using all along.

The big advantage with a pattern, is that you can say "I'll use Strategy" to explain your design, rather than explaining the whole approach. It's a nice shorthand for designers and developers. 

So to answer your question, there's nothing particularly unique about it, but that doesn't stop it from becoming a pattern. 

Srinath Soma replied on Wed, 2010/03/03 - 8:20am

Thank you James.It's very useful.Really Short but effective. Keep posting such useful articles and practical examples.

John Turner replied on Wed, 2010/03/31 - 8:40am

The one thing that jumps out from your example is the use of the setCompressionStrategy which will allow the strategy of the CompressionContext to vary at runtime.  When this is not desired the alternative is to set the strategy through the constructor.


Oliver Weiler replied on Fri, 2010/04/23 - 2:36am

The Comparator interface is propably the most well-known example of the Strategy Pattern found in the Java API.

Djordje Popovic replied on Sun, 2013/08/25 - 5:33pm in response to: John Turner

@John Turner
Hi John,
I think you are right.  
The example uses the black UML diamond for composition but latter in the code the example just uses aggregation. I also think the best way would be to use the constructor for the Context class.

Also one thing I noticed that in the example, but I would not adventure myself to say is a mistake, is that the client directly creates an object of one of those strategies.
My opinion is that the client shouldn't need to do that, instead the context should be aware of all the possible strategies.
Have a look at this little modifications I did on the Context and Client classes:

public class CompressionContext {     
private Map possibleStrategies = new HashMap();       
public void setCompressionStrategy(CompressionStrategy strategy)         {            
possibleStrategies.put("zip",new ZipCompressionStrategy());         possibleStrategies.put("rar",new RarCompressionStrategy());         }

public void createArchive(ArrayList files,String archiveType)        {            possibleStrategies.get(archiveType).compressFiles(files); public class Client { public static void main(String[] args) { CompressionContext ctx = new CompressionContext(); ctx.createArchive("zip");    } }  

Sorry about the bad formatting of the code above

Troy Young replied on Mon, 2014/09/01 - 8:47pm

Good article, but I think this pattern can be used after the factory pattern. 

Mark Anthony Ortiz replied on Mon, 2014/09/15 - 3:40am in response to: Jakob Magiera

because interface void code reuse. hard to maintain. though you can write an abstract class to let sub classes (context) implement the same method still, lead you to duplicate code which is hard to maintain. what if the context will now provide converter. where you need to convert a file to another type. ? thats why we need an interface with implementation of a specific algorithm.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.