Intro

Design patterns are easy to understand. Just read the post below and hopefully, my explanation will make you appreciate the Strategy Design Pattern. My example is written in Java but design patterns can be applied to any other programming language.

Design patterns are architecture terms that describes how to implement the solution for a problem. Today, I will demostrate how a Strategy Design pattern can be implemented in Java. Read my post about my simplest explanation on what is a Strategy Design Pattern (TODO).

Overview

Categories of Design Patterns

  • Creational
  • Behavioral <– Strategy Design Pattern
  • Structural

Description

Strategy Design Pattern Рbehavioural type design pattern where you encapsulate an algorithm and be able to interchange (from a set of algorithm/code available) it at runtime.

Problem

Our example here is class¬†Animal. An Animal can be anything, Dog, Lion, Fish etc. So for simplicity, our Animal super class can have 2 actions which is eat and poop. What we want is to encapsulate the different codes that we have for “eat” and “poop”. For example, the different codes (or algorithms as they refer) for this actual example is that “eat” can be “eat meat” or “eat grass” (lion eats meat, cow eats grass). The code when “eating meat” is different from the code when “eating grass”. In real life situation, we can relate this to an Employee class where the computeCommission method can be different from each employee type.

[pastacode lang=”java” manual=”interface%20iEat%0A%7B%0A%09public%20void%20doEat()%3B%20%2F*interfaces%20only%20have%20method%20declarations*%2F%0A%7D%0A%0Ainterface%20iPoop%0A%7B%0A%09public%20void%20doPoop()%3B%0A%7D%0A%0Aclass%20cEatGrass%20implements%20iEat%0A%7B%0A%09public%20void%20doEat()%20%7B%0A%09%09System.out.println(%22eating%20grass%22)%3B%0A%09%7D%09%09%0A%7D%0A%0Aclass%20cEatMeat%20implements%20iEat%0A%7B%0A%09public%20void%20doEat()%20%7B%0A%09%09System.out.println(%22eating%20meat%22)%3B%0A%09%7D%09%09%0A%7D%0A%0Aclass%20cPoopGrass%20implements%20iPoop%0A%7B%0A%09public%20void%20doPoop()%20%7B%0A%09%09System.out.println(%22pooping%20grass%22)%3B%0A%09%7D%09%09%0A%7D%0A%0Aclass%20cPoopMeat%20implements%20iPoop%0A%7B%0A%09public%20void%20doPoop()%20%7B%0A%09%09System.out.println(%22pooping%20meat%22)%3B%0A%09%7D%09%0A%7D%0A%0Aclass%20Animal%0A%7B%0A%09private%20iEat%20eatAction%3B%0A%09private%20iPoop%20poopAction%20%3B%0A%09%0A%09public%20Animal(iEat%20eatParam%2C%20iPoop%20poopParam)%20%2F*constructor*%2F%0A%09%7B%0A%09%09eatAction%20%3D%20eatParam%3B%0A%09%09poopAction%20%3D%20poopParam%3B%0A%09%7D%0A%09%0A%09public%20void%20eat()%0A%09%7B%0A%09%09eatAction.doEat()%3B%20%2F*take%20note%20we%20execute%20the%20doEat%20of%20the%20param%20values%20from%20the%20constructor*%2F%0A%09%7D%0A%09%0A%09public%20void%20poop()%0A%09%7B%0A%09%09poopAction.doPoop()%3B%0A%09%7D%0A%7D%0A%0Apublic%20class%20StrategyDesignPattern%0A%7B%0A%09public%20static%20void%20main(String%20args%5B%5D)%0A%09%7B%0A%09%09Animal%20lion%20%3D%20new%20Animal(new%20cEatMeat()%2C%20new%20cPoopMeat())%3B%20%2F*the%20Strategy%20Design%20Pattern*%2F%0A%09%09Animal%20cow%20%3D%20new%20Animal(new%20cEatGrass()%2C%20new%20cPoopGrass())%3B%0A%09%09%0A%09%09System.out.println(%22Lion%20actions…%22)%3B%0A%09%09lion.eat()%3B%0A%09%09lion.poop()%3B%0A%09%09%0A%09%09System.out.println(%22Cow%20actions…%22)%3B%0A%09%09cow.eat()%3B%0A%09%09cow.poop()%3B%0A%09%09%0A%09%09%2F*now%2C%20just%20in%20case%20we%20have%20a%20new%20kind%20of%20animal%20that%20eats%20meat%20but%20poops%20grass*%2F%0A%09%09Animal%20lionAndCowHybrid%20%3D%20new%20Animal(new%20cEatMeat()%2C%20new%20cPoopGrass())%3B%0A%09%09System.out.println(%22LionAndCowHybrid%20actions…%22)%3B%09%09%0A%09%09lionAndCowHybrid.eat()%3B%0A%09%09lionAndCowHybrid.poop()%3B%0A%09%7D%0A%7D%0A%0A%0A” message=”” highlight=”” provider=”manual”/]

Conclusion

With the sample code above, we can appreciate the Strategy Design Pattern because it allows us to define different underlying actions (eatGrass, eatMeat, eatFruits, eatFish) by just writing additional classes. Each algorithm/code are all encapsulated (packed/bundled) and can be substituted easily to compose a new object.

Hope you enjoy reading. I am trying to simplify abstract concepts in software architecture by writing blogs like this. Thank you!