如何用策略替换（而不仅仅是移动）条件逻辑？

In 作者通过让客户端使用贷款工厂方法来替换条件逻辑，其中每个方法针对给定参数使用适当的策略。但是，我觉得它已将条件逻辑代码传递给客户端，客户端必须根据参数选择要调用哪个 Loan 工厂方法。这不是移动而不是替换吗？

DP 的书也强调了同样的错觉：

例如，如果没有策略，将文本分成行的代码可能如下所示

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

Strategy 模式通过将换行任务委托给 Strategy 对象来消除这种 case 语句：

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

是的，但是如何选择哪个策略类来实例化合成器呢？条件逻辑？ 我发现如果上下文有层次结构，那么条件逻辑会更远，因为每个子类都可以实例化适当的策略，但这也适用于 Composition::repair() ，其中每个子类将直接调用 ComposeWithSimpleCompositor的 ComposeWithTeXCompositor。

是的——设计模式的选择有时会改变逻辑而不是取代它。

不过我不太明白你的反对意见。一些决策逻辑已经在客户端中，策略巩固了决策。

在您的代码示例中

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

the _breakingStrategy字段必须在某个地方提供，大概是由客户端代码确定要使用哪种组合方法并将该决定的结果作为值传递_breakingStrategy.

应用策略的唯一作用是让该决策提供一个策略子类，而不是像现在这样的“类型代码”，从而巩固该决策。

当然，这个决定必须在某个地方做出。如果您感觉Composition::Repair方法是它的正确位置，您当然可以完全不使用策略模式。

如果您想使用策略，但不想在客户端中使用逻辑（比现有逻辑更多），则包含类似开关的工厂方法可以提供它。