title: Does this Java Strategy pattern have a redundant Context class?
body: <p>The following code sample is an implementation of the Strategy pattern <a href="http://en.wikipedia.org/wiki/Strategy_pattern#Java" rel="noreferrer">copied from Wikipedia</a>. My full question follows it...</p>
  
  <p>The Wiki's <code>main</code> method:</p>
  
  <pre><code>//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);
  
      }
  
  }
  </code></pre>
  
  <p>The pattern pieces:</p>
  
  <pre><code>// 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);
      }
  
  }
  </code></pre>
  
  <p><strong>Considering specifically the above example, is the <code>Context</code> class redundant?</strong> </p>
  
  <p>For example, I can come up with the following alternate <code>main</code> implementation by using the existing classes and interface except Context and it will work exactly the same. It is still loosely coupled.</p>
  
  <p>(( <strong>Edit:</strong> In this simple scenario, when I leave out the Context class, <strong>will I be making a future mistake?</strong> ))</p>
  
  <pre><code>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);
  
  }
  </code></pre>
  
  <hr>
  
  <h1>Summary Update</h1>
  
  <p>Listing in point form what was discovered through answers and comments:</p>
  
  <ul>
  <li>The Context allows for variation in how the composited Strategy is used (e.g. timing of it's call). Different Contexts might do different internal work before and after calling the given Strategy.</li>
  <li>The context is a high level "black box". The Context logic can change, also the composited Strategy can change (or a different one used) without breaking the client because the client understands only how to call the context. </li>
  <li>Even though I created an alternate implementation of the Wikipedia sample code by leaving out the Context, and although it worked the same as the original, the entire situation was simplified (in both cases) and my changes actually meant: 1. it's not a Strategy pattern anymore, 2. I miss the benefits of the spirit of the Strategy pattern that are mentioned here.</li>
  <li>My alternate implementation used the main method like a Context, so I might as well keep the Context if effectively simulating it. By creating an impure Strategy pattern, confusion was created. I didn't need to reinvent the wheel or try to be smarter (in this case). </li>
  </ul>
  
  <p>If any other points would be useful or if this needs correction leave a comment and I'll modify the list accordingly.</p>