Design Patterns

Strategy design pattern comprehensive guide with head first design patterns examples

Please check each branches for stepwise implementation of the code

1. step 1 - branch step1
2. step 2 - branch step2
3. step 3 - branch step3
4. step 4 - branch step4

Design Pattern 1 - Strategy Pattern

The Strategy Pattern defines a family of algorithms, encapsulate each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

Duck problem

This is the same scenario used in the "Head First Design Patterns" book.
Please refer the SimDuck app section for details description of the scenario.

Problem Propagation

Step 1

Current Design

• Super Class
  • Duck
• Sub Classes
  • MallardDuck
  • RedHeadDuck
  • RubberDuck

Current Pond

• Mallard Duck
• RedHead Duck
• Rubber Duck

Duck class



MallardDuck class



RedHeadDuck class



RubberDuck class



App class



Step 1 Output



As you can see it is not ideal fro rubber duck to fly. When adding the flying behavior to the ducks supper class the programmer failed to identify that it is was not appropriate for some duck subclasses. *A localized update to the code caused a non-local side effect (flying rubber ducks)

Solution fro Step 1

Override the fly() method in the RubberDuck class to do nothing

Step 2

Current Design

• Similar to the previous design

Current Pond

• Mallard Duck
• RedHead Duck
• Rubber Duck

RubberDuck class



Step 2 Output



What happens when a wooden decoy duck added to the programme?.

Solution for Step 2

Override the fly(), swim(), quack(), method in the DecoyDuck class to do nothing. But what happens when new types of duck (like rubber duck, decoy duck) adds to the system quit frequently. Then we'd have an overwhelming task in our hands to override every method fro each new class. So the Inheritance (concept of OOP) is not really the way to go. We now need a cleaner way to have only some(but not all) of the duck types fly or quack.

A better solution here would be to use interfaces.

Step 3

Current Design

• Super Class
  • Duck
• Sub Classes
  • MallardDuck
  • RedHeadDuck
  • RubberDuck
  • DecoyDuck
• Interfaces
  • Flyable
  • Quackable

Current Pond

• Mallard Duck
• RedHead Duck
• Rubber Duck
• Decoy Duck

Duck class



MallardDuck class



RedHeadDuck class



RubberDuck class



DecoyDuck class



Flyable interface



Quackable interface



App class



Step 3 Output



An additional add method is used here because if the encapsulation. Now what let's say we need to make a little change in flying behavior. We have to go through all the flying duck subclass. This completely destroys the code reusing concept (Lot of duplication).

Solution for Step 3

Design Principle 1

Identify the aspects of your application that vary and separate them from what stays the same.

Take what varies and "encapsulate" it so it won't affect the rest of the code. later you can alter or extend the parts that vary without affecting those that don't.

According to the 1st design principle we can identify the parts that vary like this

Encapsulate what varies

Design Principle 2

program to an interface, not an implementation.

from now on duck behaviors will live in a separate class, which implements a particular behavior interface. Now duck class won't need to know any implementation details of it's own behaviors.

This time, Duck class is not the one who will implement these interfaces/behaviors

Note: When we say program to an interface, it's actually program to a supertype. (abstract class or interface). The point is to find polymorphism by programing to a super type, so that actual runtime object isn't lock into the code. In simple word to dynamically decide the behavior at runtime.

Step 4

Current Design

• Super Class
  • Duck
• Sub Classes
  • MallardDuck
  • RedHeadDuck
  • RubberDuck
  • DecoyDuck
• Interfaces
  • FlyBehavior
  • QuackBehavior
• Behavior Classes
  • FlyBehavior
    • FlyWithWings
    • FlyNoWay
  • QuackBehavior
    • Quack
    • Squeak
    • MuteQuack

Current Pond

• Mallard Duck
• RedHead Duck
• Rubber Duck
• Decoy Duck

Project Structure

Duck class



Note: Here we are using Composition instead of inheritance.

Design Principle 3

Favor composition over inheritance

This allows lot more flexibility to the code.

• It allows to encapsulate the behaviors as a family of algorithms
  into their own set of class
• Also allows to change the behavior at runtime

MallardDuck class



RedHeadDuck class



RubberDuck class



DecoyDuck class



FlyBehavior interface



FlyWithWings class



FlyNoWay class



QuackBehavior interface



Quack class



Squeak class



MuteQuack class



App class



Step 3 Output



These things points to a Design pattern "Strategy Pattern".

Design Pattern 1 - Strategy Pattern

The Strategy Pattern defines a family of algorithms, encapsulate each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.