是否可以在没有明显分支的情况下实施策略模式？

策略模式很好地避免了if ... else庞大的构造，并使添加或替换功能更加容易。但是，我认为这仍然存在一个缺陷。似乎在每个实现中仍然需要一个分支构造。它可能是工厂或数据文件。以订购系统为例。

厂：

// All of these classes implement OrderStrategy
switch (orderType) {
case NEW_ORDER: return new NewOrder();
case CANCELLATION: return new Cancellation();
case RETURN: return new Return();
}

此后的代码无需担心，现在只有一个地方可以添加新的订单类型，但是此部分代码仍不可扩展。将其拉出到数据文件中有助于提高可读性（我知道这值得商bat）：

<strategies>
   <order type="NEW_ORDER">com.company.NewOrder</order>
   <order type="CANCELLATION">com.company.Cancellation</order>
   <order type="RETURN">com.company.Return</order>
</strategies>

但这仍然增加了样板代码来处理数据文件-授予的，更容易进行单元测试和相对稳定的代码，但是仍然增加了复杂性。

而且，这种结构不能很好地进行集成测试。现在每个单独的策略可能更容易测试，但是您添加的每个新策略都增加了测试的复杂性。它比没有使用模式时要少，但是它仍然存在。

有没有办法实现减轻这种复杂性的战略模式？还是这只是简单而已，而尝试更进一步只会增加另一层抽象，却几乎没有好处？

当然不是。即使您使用IoC容器，也必须在某处具有条件，从而确定要注入的具体实现。这就是策略模式的本质。

我真的不明白为什么人们会认为这是一个问题。在一些书中有一些声明，例如Fowler的Refactoring，如果您在其他代码中间看到一个开关/盒或if / els链，则应该考虑一种气味并将其移至自己的方法。如果每种情况下的代码多于一行，也许是两行，那么您应该考虑将该方法设置为Factory方法，并返回Strategies。

有人认为这表示开关/外壳不好。不是这种情况。但是，如果可能的话，它应该独立存在。

是否可以在没有明显分支的情况下实施策略模式？

是的，使用每个策略实现在其注册的哈希图/字典。工厂方法将变成类似

Class strategyType = allStrategies[orderType];
return runtime.create(strategyType);

每个策略实现都必须使用其orderType和一些有关如何创建类的信息来注册工厂。

factory.register(NEW_ORDER, NewOrder.class);

如果您的语言支持，则可以使用静态构造函数进行注册。

register方法只不过向哈希映射添加了一个新值：

void register(OrderType orderType, Class class)
{
   allStrategies[orderType] = class;
}

[2012年5月4日更新]
此解决方案比我大多数时候都希望使用的原始“交换机解决方案”复杂得多。

但是，在策略经常变化的环境中（即，价格计算取决于客户，时间等），将此哈希图解决方案与IoC容器结合使用可能是一个很好的解决方案。

“策略”是关于必须在替代算法之间至少选择一次，而不是更少。在程序的某个地方，必须要做出决定-可能是用户还是您的程序。如果使用IoC，反射，数据文件评估程序或开关/案例构造来实现，则不会改变这种情况。

在指定可能的行为时使用策略模式，在启动时指定处理程序时最好使用策略模式。通过介体，您的标准IoC容器，您描述的某些Factory来指定要使用的策略实例，或者仅通过基于上下文使用正确的实例即可（通常，该策略是广泛使用的一部分）包含它的类）。

对于这种行为，需要根据数据调用不同的方法，那么我建议使用手头语言提供的多态结构。不是策略模式。

在与我工作的其他开发人员交谈时，我发现了另一个有趣的解决方案-特定于Java，但是我确信该想法可以在其他语言中使用。使用类引用构造枚举（或映射，不要紧），并使用反射实例化。

enum FactoryType {
   Type1(Type1.class),
   Type2(Type2.class);

   private Class<? extends Type> clazz;

   private FactoryType(Class<? extends Type> clazz) {
      this.clazz = clazz;
   }

   public Class<? extends Type> getTypeClass() {
      return clazz;
   }
}

这大大减少了工厂代码：

public Type create(FactoryType type) throws Exception {
   return type.getTypeClass().newInstance();
}

（请忽略不良的错误处理-示例代码：）

它不是最灵活的，因为仍然需要构建...但是它将代码更改减少到一行。我喜欢将数据与工厂代码分开。您甚至可以通过使用抽象类/接口提供通用方法，或创建编译时注释以强制特定的构造函数签名，来进行诸如设置参数之类的操作。

通过使每个类定义其自己的订单类型，可以提高可扩展性。然后您的工厂选择一个匹配的对象。

例如：

public interface IOrderStrategy
{
    OrderType OrderType { get; }
}

public class NewOrder : IOrderStrategy
{
    public OrderType OrderType { get; } = OrderType.NewOrder;
}

public class OrderFactory
{
    private IEnumerable<IOrderStrategy> _strategies;

    public OrderFactory(IEnumerable<IOrderStrategy> strategies) // Injected by IoC container
    {
        _strategies = strategies;
    }

    public IOrderStrategy Create(OrderType orderType)
    {
        IOrderStrategy strategy = _strategies.FirstOrDefault(s => s.OrderType == orderType);

        if (strategy == null)
            throw new ArgumentException("Invalid order type.", nameof(orderType));

        return strategy;
    }
}

我认为应该限制多少个分支。

例如，如果我的switch语句中包含八个以上的案例，那么我将重新评估代码并寻找可以重构的内容。我经常发现某些案例可以分组到单独的工厂中。我在这里的假设是，有一家工厂可以制定战略。

无论哪种方式，您都无法避免这种情况，因此必须在某个地方检查正在使用的对象的状态或类型。然后，您将为此制定策略。好旧的关注点分离。