1

The Strategy Design pattern, from the book Design patterns written by the Gang of Four, has the following statement in the Consequences section:

Strategies eliminate conditional statements. The Strategy pattern offers an alternative to conditional statements for selecting desired behavior. When different behaviors are lumped into one class, it's hard to avoid using conditional statements to select the right behavior. Encapsulating the behavior in separate Strategy classes eliminates these conditional statements.

This statement is not as black and white as it seems. The Context class is indeed relieved from the burden of conditional statements. However, in case there is a single client, that injects different Strategies in the Context, then there must be a conditional statement in the client to make the decision. This means the conditional statement is not eliminated, but moved!

However, I can come up with a scenario where this Consequence might be true. In case there are multiple clients that all need the Context with a different Strategy. Then the conditional statement is eliminated from the code base, because each client creates its respective Strategy & Context combination. Is this what is meant by 'Strategies eliminate conditional statements' in the Consequence section of the Strategy design pattern or am I missing something?

Niek Beijloos
  • 39
  • 7

1 Answers1

1

You are more or less correct. The pattern is not claiming to eliminate all conditional statements from every class. The book touches on this issue a little bit in Consequences #5:

Clients must be aware of different Strategies. The pattern has a potential drawback in that a client must understand how Strategies differ before it can select the appropriate one. Clients might be exposed to implementation issues. Therefore you should use the Strategy pattern only when the variation in behavior is relevant to clients.

So there is potential tradeoff in terms of where the complexity lives. However, promoting each Strategy to an object offers additional selection mechanisms beyond the branching logic the pattern "eliminates". For example, Strategy objects could be stored in a HashMap and selected by key value (without branching).

Also consider the same approach, whereby branching logic is divided into Strategies, might be applied on the client side as well, to refactor a single client class into many. Essentially, you can take the Strategy approach as far as you want to go with it. Dividing every logical path through the code into its own set of classes may not be practical; but the Strategy pattern at least shows us a way in which it may be possible.

jaco0646
  • 15,303
  • 7
  • 59
  • 83
  • Thanks for the clarification, zooming in on the example you provided, it means we can also use a HashMap in the Context and replace Strategy objects with function pointers or lambdas. Each time a new Strategy is added, we extend the HashMap. The Strategy logic remains in the context class, but has no impact on the (generic) Context logic directly, only on the HashMap itself. In this way we accomplish the same goals as we would with the Strategy pattern. The difference: the logic resides in the Context, making the algorithmic logic (Strategies) harder to test and Context less readable? – Niek Beijloos Feb 05 '23 at 15:17
  • The tradeoff I see with respect to the example I provide and you provide are: **HashMap in Context with Strategies as function pointers/Lambda's** means the Context becomes more complicated and individual Strategies become harder to test, but the Strategy logic is is 'situated' in one place, namely: the Context (=understandability). **HashMap in Client with Strategy objects** means the client becomes harder to test and the Strategy logic is more scattered (for each one a different class), but the Strategies are easier to test in isolation. How do you see it? Do you have more arguments? – Niek Beijloos Feb 05 '23 at 15:45
  • You're 100% on the right track. The Strategy Pattern is an object-oriented workaround for languages that lack first-class functions. With basically all modern languages now supporting closures or lambdas, the goal of this Pattern can be achieved through alternative syntax. – jaco0646 Feb 05 '23 at 18:53
  • 1
    thanks for helping, you clarified it for me! – Niek Beijloos Feb 06 '23 at 07:44