java - 这个 Java Strategy 模式是否有多余的 Context 类？

Question

以下代码示例是策略模式的实现 copied from Wikipedia .我的完整问题如下...

Wiki 的 main 方法:

//StrategyExample test application

class StrategyExample {

    public static void main(String[] args) {

        Context context;

        // Three contexts following different strategies
        context = new Context(new ConcreteStrategyAdd());
        int resultA = context.executeStrategy(3,4);

        context = new Context(new ConcreteStrategySubtract());
        int resultB = context.executeStrategy(3,4);

        context = new Context(new ConcreteStrategyMultiply());
        int resultC = context.executeStrategy(3,4);

    }

}

图案片:

// The classes that implement a concrete strategy should implement this

// The context class uses this to call the concrete strategy
interface Strategy {

    int execute(int a, int b);

}

// Implements the algorithm using the strategy interface
class ConcreteStrategyAdd implements Strategy {

    public int execute(int a, int b) {
        System.out.println("Called ConcreteStrategyA's execute()");
        return a + b;  // Do an addition with a and b
    }

}

class ConcreteStrategySubtract implements Strategy {

    public int execute(int a, int b) {
        System.out.println("Called ConcreteStrategyB's execute()");
        return a - b;  // Do a subtraction with a and b
    }

}

class ConcreteStrategyMultiply implements Strategy {

    public int execute(int a, int b) {
        System.out.println("Called ConcreteStrategyC's execute()");
        return a  * b;   // Do a multiplication with a and b
    }

}

// Configured with a ConcreteStrategy object and maintains a reference to a Strategy object
class Context {

    private Strategy strategy;

    // Constructor
    public Context(Strategy strategy) {
        this.strategy = strategy;
    }

    public int executeStrategy(int a, int b) {
        return strategy.execute(a, b);
    }

}

具体考虑上面的例子，Context类是不是多余的？

例如，我可以通过使用除 Context 之外的现有类和接口(interface)来提出以下备用 main 实现，它的工作方式完全相同。它仍然是松耦合的。

(( 编辑: 在这个简单的场景中，当我省略 Context 类时，我以后会不会犯错误？ ))

public static void main(String[] args) {

    IStrategy strategy;

    // Three strategies
    strategy = new ConcreteStrategyAdd();
    int resultA = strategy.executeStrategy(3,4);

    strategy = new ConcreteStrategySubtract();
    int resultB = strategy.executeStrategy(3,4);

    strategy = new ConcreteStrategyMultiply();
    int resultC = strategy.executeStrategy(3,4);

}

---

总结更新

以点的形式列出通过回答和评论发现的内容:

• 上下文允许组合策略的使用方式发生变化(例如调用时间)。在调用给定策略之前和之后，不同的上下文可能会执行不同的内部工作。
• 上下文是一个高级“黑匣子”。上下文逻辑可以改变，复合策略也可以改变(或使用不同的策略)而不会破坏客户端，因为客户端只了解如何调用上下文。
• 尽管我通过省略上下文创建了维基百科示例代码的替代实现，并且尽管它的工作方式与原始代码相同，但整个情况都得到了简化(在这两种情况下)，我的更改实际上意味着:1. 它是不再是策略模式，2. 我想念这里提到的策略模式精神的好处。
• 我的替代实现使用了像 Context 一样的 main 方法，所以如果有效地模拟它，我还不如保留 Context。通过创建不纯的 Strategy 模式，造成了困惑。我不需要重新发明轮子或尝试变得更聪明(在这种情况下)。

如果有任何其他要点有用或需要更正，请发表评论，我会相应地修改列表。

Answer 1

顾名思义，Context 封装了执行策略的点。否则，您只有一个裸体 Strategy，调用类现在承担了额外的责任:知道何时调用 Strategy 本身。您的示例可能有点太简单了，在这种特殊情况下，我会说 Context 并没有让您了解太多。

可能更好地说明 Context 有用性的示例如下所示:

public class LoadingDock {   // Context.
  private LoadStrategy ls;   // Strategy.

  public void setLoadStrategy(LoadStrategy ls) { ... }

  // Clients of LoadingDock use this method to do the relevant work, rather
  // than taking the responsibility of invoking the Strategy themselves.
  public void shipItems(List<ShippingItem> l) {
    // verify each item is properly packaged     \
    // ...                                        |  This code is complex and shouldn't be
    // verify all addresses are correct           |  subsumed into consumers of LoadingDock.
    // ...                                        |  Using a Context here is a win because
    // load containers onto available vehicle     |  now clients don't need to know how a
    Vehicle v = VehiclePool.fetch();        //    |  LoadingDock works or when to use a
    ls.load(v, l);                          //   /   LoadStrategy.
  }
}

注意 Strategy 永远不会直接从外部客户端调用。只有 shipItems 使用该策略，它遵循的步骤的详细信息是一个黑框。这允许 Context 在不影响客户端的情况下调整其使用策略的方式。例如，这些步骤可以完全重新排序或调整(或完全删除)以满足性能目标或其他目标——但对于客户端而言，shipItems() 的外部接口(interface)看起来完全一样。

另外请注意，我们的示例 Context，即 LoadingDock，可以根据其内部状态随时更改其 LoadStrategy。例如，如果 jetty 太满，它可能会切换到更积极的调度机制，使 crate 更快地离开 jetty 并装上卡车，这样做会牺牲一些效率(也许卡车的装货效率不如他们本来可以)。