How to replace (and not just move) Conditional logic with strategy?

Question

In Refactoring for templates, the author replaces conditional logic with the fact that the client uses the Loan factory methods, where everyone uses the appropriate Strategy for the given arguments. However, I feel like it passed the conditional logic code to the client, which should choose based on the arguments that the Loan factory method calls. Is this not a displacement, but a replacement?

DP book clogs the same illusion:

For example, without strategies, the code for breaking text into lines may look like

void Composition::Repair () { switch (_breakingStrategy) { case SimpleStrategy: ComposeWithSimpleCompositor(); break; case TeXStrategy: ComposeWithTeXCompositor(); break; // ... } // merge results with existing composition, if necessary } 

The strategy template removes this case argument by delegating the task of creating rows for the Strategy object:

 void Composition::Repair () { _compositor->Compose(); // merge results with existing composition, if necessary } 

Yes, but how to choose from the Strategy class to create an instance of the composer? Conditional logic? I see that if the context had charisma, then the conditional logic would be even further, since each subclass could create an appropriate strategy, but this also applies to Composition :: repair (), where each subclass will directly call ComposeWithSimpleCompositor from ComposeWithTeXCompositor.

Answer 1

Yes - choosing a design template sometimes moves logic rather than replacing it.

I really do not understand your objection. Some logic of the solution is already in the client, and the strategy consolidates the solution.

In your code example

 void Composition::Repair () { switch (_breakingStrategy) { case SimpleStrategy: ComposeWithSimpleCompositor(); break; case TeXStrategy: ComposeWithTeXCompositor(); break; // ... } // merge results with existing composition, if necessary } 

the _breakingStrategy field should be provided somewhere, presumably, by client code that determines which layout method to use and pass the result of this decision as the value of _breakingStrategy .

The only thing that the Strategy applies is that this solution provides a subclass of the Strategy instead of the "type code", as it is now, of consolidating the solution.

The decision, of course, must be made somewhere. If you think that the Composition::Repair method is suitable for it, you, of course, may not use the strategy template at all.

If you want to use the Strategy, but do not want the logic in the client (no more than it is), the Factory method containing a similar switch could provide it.

Answer 2

conditional logic is pushed further to the client. This may be desirable, since it is likely that a choice has already been made in this direction (yes, through conditional logic). Thus, conditional logic is taken into account. The conditions by which a choice is made can take many forms, including text.