以下代码示例是从维基百科复制的策略模式的实现。我的完整问题紧随其后...

维基的方法：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 之外的现有类和接口来提出以下替代实现，并且它的工作方式完全相同。它仍然是松散耦合的。main

(( 编辑：在这个简单的场景中，当我省略上下文类时，我将来会犯错误吗？ ))

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。通过创建不纯的策略模式，造成了混乱。我不需要重新发明轮子或试图变得更聪明（在这种情况下）。

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