Implementing Strategy pattern on TypeScript
Design patterns are ways of standardizing resources implementations into our applications. The greatest motivation to use patterns is, by far, the increase in legibility, efficiency and help on future code maintenance.
There are a lot of design patterns out there. But, from this huge list, we have Strategy, which is maybe the simplest of them. It appears, mostly, when we need to vary some part of our algorithm to process different client requests, but at the same moment, we want to reach a common final objective, but with some advantages during implementation, as we are going to see later on.
Analyzing a situation
Meet Josh. Josh is a little bit, uh, let’s say, chubby. His doctor recommended him to start working out during the week, at least doing what he likes the most. Josh enjoys doing three things when it comes to sports: go running, play soccer and going to the gym. His wife, Jessica, is working by the time he leaves to go work out, so he downloaded a TypeScript program to help him let his wife knows what he has chosen to do. Here is the program source:
After running the program, Jessica received the response that Josh decided to play soccer with his friends. Josh, though, knows design patterns, and realized this was not the smartest way of implementing this program.
Is using IFs a bad idea?
Conditional structures are one of the basis of programming languages. The structure IF/ELSE IF/ELSE is present in, pretty much, every programming language. However, just because they are there, it doesn’t mean they are the only choice for you. Imagine Josh discovered a new favorite sport. Adding them to the program would make code harder to read, hence harder to maintain, but also things could get even weirder: Josh could accidentally add side effects to his program.
Hence, we have Strategy pattern. It allows us to encapsulate each one of Josh’s favorite sports in a different class. Nonetheless, we need to guarantee that each sport will tell the user which option Josh took. How can we do that? Using Interfaces.
Let us begin by declaring an interface FavoriteWorkout. Every class that implements it must contain the method begin(), responsible of showing the notification to Jessica. Then we have:
Now, we need to refactor our sports. The idea here is that each FavoriteWorkout is encapsulated in its own class, which implements the interface we’ve just created, and the notifications on the console are being made by the function begin(), that makes part of the contract signed buy our class when it implements our interface. By doing this refactoring we end up with:
We are now half way through. All we need to do now is refactoring our class Person using polymorphism, making her receive an instance of FavoriteWorkout instead of an ENUM option. By doing that, we can call the method begin() of this instance inside our workout() method. After refactoring, we may have something like this:
If we run the program now, we are going to arrive at the same result:
What is the benefit of doing all this?
Suppose now Josh decided to play volleyball besides the other sports that he already practice. Instead of getting worried on modifying many IFs through his code, he only needs to add a new Class to the program:
And, when his wife runs up the code:
As we can see, Strategy pattern is a quick and easy way of dealing with many types of a same category, for example. Here, we are just using a few methods and types. Imagine now the same situation in a much larger and dynamic application, with many users, with different properties, permissions levels and quickly you will realize how using Strategy will save you time.
See you later.
✉️ Subscribe to CodeBurst’s once-weekly Email Blast, 🐦 Follow CodeBurst on Twitter, view 🗺️ The 2018 Web Developer Roadmap, and 🕸️ Learn Full Stack Web Development.
