Design Patterns: Strategy Pattern
originally posted on my blog at henricodesjava.blog
Hello world! I’m currently reading Head First Design Patterns: A Brain-Friendly Guide. If it's your first time reading about design patterns in Object Oriented Programming (OOP), it's a great place to start!
I wouldn’t recommend it as a reference guide, though, because there are a ton of examples, illustrations, and informal descriptions. Here is the first pattern introduced in the book.
Strategy Pattern: defines a family of algorithms, encapsulates each one, and makes them interchangeable. The strategy lets the algorithm vary independently for clients that use it.
Sounds confusing, but it's actually pretty simple. The pattern is based on the following three principles:
- Identify the aspects of your application that vary and separate them from what stays the same.
- Program to an interface, not an implementation.
- Favor composition over inheritance.
Let me try to clear up what these principles mean. I’ll use an example that is different from the one included in the book.
Let's say we are starting a robot company, like Boston Dynamics. We want to build all types of robots. Check out the class below that will be used for all of our robot’s behaviors.
Here is where we apply our first principle. Our imaginary company needs to be be able to build robots that operate on land, air, or water. All of our robots also need to be able to give the greeting, “Hello world!”
The greeting is the behavior that stays the same. The other three behaviors are what will change from robot to robot. So we will separate the ‘walk,’ ‘swim,’ and ‘fly’ behavior from the ‘greeting’ behavior. Let's see how.
The second principle states that it is better to use interfaces rather than direct implementations. What we will do is create interfaces for each behavior group that has the possibility of changing. This way, there can exist many different implementations of each. See below.
When it comes time to create a specific implementation of a robot, we will extend the Robot class. This way, we have access to the ‘greeting’ behavior.
The greeting behavior can be coded in the Robot class since this will be the same for all robots we'll ever create. When it comes time to add a walk, swim, or fly behavior to our new robot, it will not inherit this behavior from the original Robot class — it will instead have an implementation of an interface assigned to it.
In other words, it will be composed during runtime. This successfully separates these changing and non-changing behaviors using interfaces. This way, we follow our third design principle. Take a look at the diagram below for an overhead view of it all, including three example robots: Dog, Shark, and Eagle.
That's it! That is the quick introduction to the Strategy Pattern. From above, you can see what a complete class diagram would look like when we implement the Strategy Pattern. Thanks for reading 👋🏽
This post is originally published by the author here. This version has been edited for clarity and may appear different from the original post
