Design Pattern in simplicity: Strategy Pattern

Kenneth Cheung
< />
Published in
4 min readMar 1, 2018
Photo by JESHOOTS.COM on Unsplash

About this series…

Learning GoF Design Pattern has been being my goal since I became a developer. For me, having a decent understanding of design pattern is one of fundamentals for being a good developer. Although Javascript is not a pure object oriented programming language and some of the popular front end frameworks like React, Redux, they work more like functional programming. I think it is still so valuable to learn. Understand how smart people solve software development problems helps us to deal with software design problems with more inspiration, write better code and prevent reinvent the wheel.

There are a lot of resources to learning GoF Design Pattern, but not so many of those are specifically for web developer and some of those with many complicated UML diagrams or hard termanology. Sometimes it is difficult to be begin with for a web developer without related background. If you want to learn patterns with more details, I think this site is a good one.

So, in this series, I will try to make everything simple by:

  1. Using plain language to interpret my understanding of the pattern
  2. Extracting the high level concept of the pattern
  3. Using simple examples to implement the pattern in javascript.

I hope this series helps web developer who want to learn design pattern have better understanding for these patterns.

I will start with the pattern which I personally think is more general and I might skip some of the patterns seem too hard to me at the moment to implement simple examples or patterns seem not relevant to web development.

In the end of the series. I will make a conclusion about my point of view for how design pattern can make us become a better web developer.

Strategy Pattern

If you don’t have time, the one sentence version for this article is:

Program to an interface, not implementation.

The definition in the wikipedia is

In computer programming, the strategy pattern (also known as the policy pattern) is a behavioral software design pattern that enables selecting an algorithm at runtime.

Example

John has to go to work, how he goes to work is decided by currentWeather and currentTime. Fow now, his only way is walking.

var john = new People();
john.walk();

Weeks passed…

John has enough money to buy a bike, he has another choice now.

Let’s re-code it!

var john = new People();
if (currentWeather === 'sunny' && currentTime > 9) {
john.bike();
} else {
john.walk();
}

In this example, method walk() and bike() are the algorithm details for the task “go to work”. The code is not ideal. When we change the algorithm details we also need to change the code of client side. What if John buys a car in the future, or John go to work by walking when it is raining. The code in the client side will soon become smelly.

One remedy is abstracting the walk() and bike() method one level higher goToWork()

var john = new People();
john.goToWork(currentWeather, currentTime);

The actual implementation for goToWork()in OOP is a little bit beyond the coverage of this series. If you are interested in it, take a look at this.

For simplicity, you can imagine goToWork() works like this:

class People {
// ...properties in the Class
goToWork(currentWeather, currentTime) {
let strategy = null;
if (currentWeather === 'sunny' && currentTime > 9) {
strategy = this._walk.bind(this);
} else {
strategy = this._bike.bind(this);
}
strategy();
}
}

In this case, no matter how John goes to work, it doesn’t affect client side’s code. The client side and the algorithm all rely on the consensus function name(interface) goToWork(). Just be careful to name the function too general like move().

A classic real world example is input validation. Instead of writing a bunch of functions likeisNumber() , isEmpty() , isValidLength() etc. for client. We can just provide a validate() function, let it deal with the validating details.

Conclusion

Strategy pattern is one of the most widely used pattern, because it can be implemented in many places. It decrease the coupling level by abstract the algorithm details. I hope this article helps. If anything in this article or my understanding is incorrect, please let me know, thanks!

References

--

--