Does Strategy pattern involve modifying every subclass?

Question

Consider a super class Animal, inherited by multiple subclasses(Dog / Bird). On their instantiation, objects have their local state & behavior:

---

wiki says:

The strategy pattern

• defines a family of algorithms,
• encapsulates each algorithm, and
• makes the algorithms interchangeable within that family.

---

If a requirement demands to add a new behavior(fly()) in super class Animal, then use Strategy pattern, to create new family of algorithm(CantFly/ ItFly) and encapsulate these algorithms in setFlyingAbility()/tryToFly(), to attain minimal code changes in existing class hierarchy, with below changes:

where ItFyls and CantFly are family of algorithms for new behavior(fly) that are used by subclasses(Dog / Bird) interchangeably, with below code changes

---

Association of type Composition, at crux, is helping to add new behavior in super class by minimizing code changes in super/sub class relationship, shown below,

class Animal{
    ....
    Flys flyingType;
    ....
    public String tryToFly(){
       return flyingType.fly();
    }
    public void setFlyingAbility(Flys newFlyType){
      flyingType = newFlyType;
    }
}

---

Question:

To add a new behavior(fly()) in super class(Animal), Does Strategy pattern involves modifying every subclass(Dog/Bird) constructor? Can modification of subclass get avoided?

Answer 1

Your implementation of the Strategy Pattern is fine, but I do not think your example is a good illustration of the problem Strategy Pattern is solving.

Consider sorting. Given an array of comparable items, we choose among many different sorting algorithms (or, "strategies"). One common use case of the strategy pattern is used to run the algorithms in parallel, for example, until the first one terminates. Databases have a similar approach to finding the most efficient method of performing a query, during the optimization phase.

Your OO analogy with Dog/Bird inheriting from Animal doesn't quite fit this, in my view, because the fly() strategy that you choose depends on whether the input is a dog or a bird.

A better fit for your situation is the idea of a virtual function. In such a case, the base class Animal declares the function signature, and defers the implementation to inheriting classes.

Answer 2

The "strategy pattern" is a red herring here!

There is an existing class hierarchy (of animals), and one tries to make the code more SOLID (in this case specifically SRP and OCP conform). Then the refactoring causes the necessity to touch every constructor in the hierarchy - but that is quite normal when making a non-solid class hierarchy more SOLID, and it has absolutely nothing to do the specific approach here is "Strategy". The real reason is, refactoring a more complex codebase involves more effort than refactoring a simpler one - that is IMHO not very surprising!

The "Strategy" pattern requires always one or more places in the program where the specific strategy subclass has to be picked, or changed (maybe it changes at runtime, maybe not). This is part of the business logic, and the "correct" place is case-dependent. When it is introduced into a simple context (like a test class without a class hierarchy), there are typically less things to be changed than when it gets introduced into a more complex context like a class hierarchy. However, the reason for this is the complexity of the context, not the pattern.

In this specific example, it makes sense to make the decision about the strategy in the constructor of the different animals - the association Dog - CantFly, Bird - ItFlys must be somewhere, and since the correct strategy can be picked by the kind of animal, by general knowledge, and it won't change during the lifetime of each object, the constructor is not the worst place to implement it.

So yes, making this code more SOLID involves changing the constructors at the time you introduce the pattern into the code, no less, no more (in real code, you will probably have to refactor more things in the Animal class hierarchy for introducing the pattern). Note the point such refactorings is not to avoid changes to the code before it got introduced, but after.