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?
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.