The Strategy Pattern

Sometimes, we find ourselves adding child classes to our original classes, just to add new behaviours to our objects. Some other times, we just simply detect a class full of if, else, swicth… These are symtoms with two possible diagnostics: we are not acomplishing the Dependency Inversion Principle or the Single Responsability Principle. If you are a big fan of the SOLID principles you can stop reading this post right now, but if you have just finished the college or you have been working in a donuts factory during the last ten years, you are a great candidate to learn the Strategy Pattern.

Let’s say we are in a developing team of a first action shooter game and the “men upstairs” put us in charge of the big fish: the weapons. At this time, the game designers don’t know how many weapons will we have to create to the final game and, besides, they have plans to develop a expansion pack with more weapons in a close future. This is not our first time, so we are going to design our classes to avoid refactorization, because we will need to create different weapons with different actions like shoot, stab, explode, scarf…

The first thing we do is define the actions that our weapons will be able to do or, at least, the ones which we initially think. In this pattern, the different behaviours that our class can have are called Strategies and they define using interfaces. We don’t know exactly which weapons we will have to create, so we are going to start just with two basic strategies: Fire and Stab:

We know a lot of action games, so we know well that not every weapon fires the same way and some of them, even have more than one type of firing, so we will need another level, which define exactly each  Disparar strategy. This level is called Concrete Strategy and, in our example, we are going to define two of them: Shot and Burst. We also add the concrete strategy HeartStab,  to our Stab strategy:

Our idea is taking shame. We have already implemented the different behaviours (strategies) of our weapons. The next step is to create Weapon class, which will use our strategies. The good thing about this pattern is, every strategy is only in charge of its own algorithm and tottally independent from the main class, which is called Context:

Just in time, when we have just finished our classes, we receive a call from the men upstairs, informing us that they have made a decision about the weapons which will be: a gun, a chaingun, a knife and a ninja star. Well, we had not thought about the ninja star, but we don’t panic, because we know we have built a class model easily extenible. We simply create a new Throw strategy, we define a concrete strategy ThrowOne and we add this behaviour to our context:

We are ready to create our weapons. The Strategy Pattern allows us to do that in execution time, so if we assign to our character a Weapon object as a property, we can equip whatever weapon  we want when the game is running. We could even combine strategies to create a more effective weapon, even this could not like to the men upstairs.

So far this brief explanation about the Strategy Pattern. You can go further this topic in this two blogs (in spanish) that served me as inspiration: y danielggarcia. Thanks to both of them and to you to have read this post. You have the complete code in my Github.

Leave a Reply

Your email address will not be published. Required fields are marked *