While looking into the code of our project I stumbled upon a part that I haven’t investigated before. The part is implemented with the strategy pattern, or so I was told because In fact the strategy pattern isn’t fully implemented. So I got curious about this pattern and found this nice definition by The gang of four :
Define a family of algorithms, encapsulate each one, and make them interchangeable. [The] Strategy [pattern] lets the algorithm vary independently from clients that use it.
In fact the strategy pattern can be used to avoid the use of big switch statements or if – elseif statements. What we do is, we create an interface and use this in our context class. This allows us to decouple the implementation and the usage for each other. The next step would be to create implementations of our strategies and and in order to use them we use a setter in the context class. Since explaining patterns is rather difficult without a UML scheme here it is :
Sorry for the poor drawing but I had to make this in Visio which really sucks. As for the actual implementation I will show you a few code fragments to actually demonstrate the usage in Java.
We’ll start with the Context class. We should define a private member which is an implementation of the ICalcul interface.
public class ContextClass {
private ICalcul calcul = null;
private double result = 0.0;
.....
public void setCalcul(ICalcul calc) {
this.calcul = calc;
}
public ICalCul getCalcul() {
return this.calcul;
}
public void calculate() {
this.result = this.calcul.calculate();
}
....
}
As you can see in the above code fragment we use the interface in the ContextClass this allows us to decouple the actual implementation of the calculation from the ContextClass. This is very useful since now we can create any sort of calculation we want and decide at run-time which kind of calculation we want to use. All we need to do now is create an implementation of our calculation.
public class CalculA implements ICalcul {
public double calculate() {
return = 1.0/3.0;
}
public void save() {
// do something here
}
}
There is our heavy calculation :) Now we can set the calculation we want in our application by doing the following
public class Calculator {
.....
public static void main(String[] args) {
....
ContextClass cc = new ContextClass();
ICalcul calc = new CalCulA();
cc.setCalcul(calc);
cc.calculate();
....
}
}
If you want more information on this pattern I suggest you take a look on wikipedia or simply search for it with google.
3 Comments so far
Leave a comment
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <pre> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Excellent post — you do a great job of explaining it.
I do have one comment/question though. You say that using the strategy pattern eliminates the need for bulky switch/if-else-if blocks. Doesn’t it just clean them up (or move them elsewhere if you go with a factory pattern)? I mean, if you’re working with multiple strategies, you still need some way to determine which strategy to use, correct? (I’ve programmed for quite a while, but my academic training was minimal; I only heard about the GOF book in January and haven’t spent the time to delve into Design Patterns very deeply).
Again, excellent post.
Comment by mcory1 May 11, 2007 @ 15:15Your right, in fact it shifts the boiler plate code outside of your ContextClass ( the class using the strategy pattern ) by doing so, you can make your actual implementation interchangeable. But to make it interchangeable, you will ofcourse at some point have to decide wich implementation you will use, the nice thing about this pattern is that adding a new implementation becomes easy.
Comment by Tilleuil Doménique May 11, 2007 @ 16:16Isn’t this basically a factory pattern?
Comment by bob April 30, 2009 @ 19:19