I started to read Head First Design Patterns. I highly recommend this book to anyone who wants to explore design patterns in such an engaging way. I allocated 2 hours every week to deep dive into the contents. Every time I finish learning about one design pattern, I am going to write about what I understood about the pattern.
First of all, let's start with a very important question as this is my first post about this book. What is the design pattern? The author of the book defines it really well.
Design pattern is the best practice that professional OOP developers have found. design patterns are the solutions to many common problems that developers have encountered.
According to Tutorial Point, generally, the design patterns can be categorized into three types.
- Creational pattern
- Structural Pattern
- Behavior Pattern.
The design pattern that I am going to talk about today is a behavior pattern.
Before I talk more about that design pattern, let's first answer this question; what is a behavior pattern?
A behavior pattern is a design pattern that is mainly concerned with the interaction between objects.
Taken the definition of the design pattern and that of the behavior pattern together, you can probably guess that today's pattern is a design that somehow solves certain problems that happen when objects interact. So what is it?
Strategy Pattern (Policy Pattern)
Let's start with its definition.
Strategy pattern is the behavior design pattern that selects strategy at runtime.
Okay.. So it sounds like we need to understand what 'strategy' means here. I interpret strategy as behavior of an object or a program. Broadly speaking, this behavior is an algorithm, a set of instructions that your program follows. So basically, the Strategy pattern is a design pattern that allows your program to have different behavior at runtime.
Before we talk about how to implement the strategy pattern, let's discuss why even allowing your program to have different behavior at runtime is important.
When we say we allow our program to have different behavior at runtime, it means we allow our program to react to different inputs. Think about the below case:
Let's say you want to make a console application that prints out different results based on a user's input. When a user types 'I', a random int data is passed to my program and my program processes the data and shows the sum including the number. When the user inputs 'S', a random string is passed to my program and my program shows the whole strings which consist of random strings generated up to the point.
This is powerful if you think about how much flexibility your program has. With one program, you can meet so many different customers' demands. You can see the benefit of code reusability here as well.
Then how does strategy pattern allow my program to have this flexibility? The key in the Strategy pattern is encapsulating* the behavior that changes quite often. Basically, make the behavior that frequently changes as its own class. By doing so, we can (1) make our program to be flexible with changes in that behavior without modifying our program itself and therefore we can stick with the open/close principle*, (2) increase code reusability by allowing other programs to use the behavior class.
Now we covered the theoretical aspects of Strategy Pattern. It is always helpful to see an actual example to understand the concept better. We will deep dive into the implementation of the Strategy Pattern with an example from the book in the next post. It will be fun. I promise :)
*Encapsulation in OOP: Class should contain the data and methods that directly work on the data as a single unit.
*Open/Close Principle: class is open to extend and close to modification.
Top comments (0)