Introduction

The strategy pattern is the single most important design pattern for developers to learn. And the best part? It’s also one of the most simple.

As the name implies this pattern is used for responding with various strategies to some input. The strategies are abstracted either using functions or various classes/interfaces and the desired strategy is passed into your program to be executed during runtime.

This follows the Open/Closed design principle- you don’t need to modify code in the execution context (where your strategy gets called) to modify the behavior of your strategies. The logic comprising your strategies exists elsewhere.

Consider The Following Problem

You are developing a checkout system for an online store and you need to be able to apply different sales taxes based on which state somebody is ordering from.

If you’re unfamiliar with the strategy pattern you may be tempted to do the following:

This naive solution forces your execution context (the POST endpoint) to know the logic for each state’s sales tax calculation. Why is this a problem? Because when it comes to software design abstraction is king. The more you can write code that you never have to touch again the better. By including the logic for the various strategies / states in the execution context you open up the possibility that you have to modify stuff in the execution context later.

Abstracting your functionality into small, cohesive units will help keep your projects clean and the resulting encapsulation means modifications are finely-scoped. In other words, you only need to modify code in the strategy logic, not in the execution context.

And as I mention in the article I wrote demanding that you write more functions as a beginner, abstracting creates more testable, more readable, and overall more pleasant code to work with.

The Strategy Pattern

To implement the strategy pattern all we need to do is create various “strategies” (in this case- functions) that hold the necessary logic for getting various state sales taxes.

And with that, we are well on our way to using the strategy pattern. Let’s go ahead and throw it into our POST endpoint:

Voilà. We’ve implemented the strategy pattern!

“I.. I can go home now, right?” Wrong.

There is a serious design problem with this implementation, let’s talk about it.

What Tutorials Don’t Mention

As your company begins accepting customers from a few more states this implementation will hold up. But.. What happens when you support twenty states? Thirty?

Supporting even as little as seven states leaves you with a bloated function. You would be a mad man to go on this way.

A Better Way

The strategy pattern is good. But the strategy pattern tucked inside a nice little lookup table that grabs the strategy you want by passing in a key (the customer’s state) is even better.

We’ve replaced the if statements with a basic lookup table (a topic I will be writing about more in depth soon). This particular abstraction is using a JavaScript object (essentially, a hash table) to make looking up our desired sales tax function very easy. Pass in the state and get back the function you need.

That’s good. That’s really good.

Conclusion

No matter how many functions we have, or what their functionality looks like, when we use the strategy pattern we don’t have to touch the logic inside our POST endpoint. The POST endpoint doesn’t need to know anything about how we get the sales tax.

And using the lookup table the POST endpoint doesn’t even need to know which function we are passing into it. Better yet, if we need to get the sales tax in various other places in our application, we now have a straight forward way to do so using the function lookup table. And testing these functions? Super easy.

The strategy pattern is easy to implement and even easier to make pretty.

Now you can go home.