Design – Why do we need a context class in strategy pattern

designdesign-patternsobject-oriented-designstrategy

For the strategy pattern, why do we need a context class to call the appropriate algorithm? Why can't we just do Strategy s = new OperationAdd()? This way, we still use polymorphism.

Best Answer

In some languages, notably C# and Java, you can strategize, not the sorting algorithm, but the way the objects being sorted are compared for ordering purposes.

For example, in C#, you could say something like

var sort = new MergeSort(new ImaginaryNumberComparator());

and the MergeSort will treat the objects being sorted like imaginary numbers for ordering purposes.

Changing the sorting algorithm, however, requires knowledge of the entire collection, not just two of its members.

Related Solutions

Java – Modified Strategy Design Pattern

You need to clarify your strategy.

It all depends on how you use your algorithms. For your client class to use different strategy implementations interchangeably, they all need to have a common abstraction. If they don't follow the same interface, maybe what you need are different abstractions.

I've used configurable strategies before, where you parameterize the concrete classes on construction:

interface Strategy {
  int calculate();
}

class ConcreteStrategyThatNeedsAParameter implements Strategy {
  private final int param;
  public ConcreteStrategyThatNeedsAParameter(int param) {
    this.param = param;
  }
  public int calculate() { 
    // uses param...
  }
}

Now, someone still needs to create an instance of this class and pass it to your client. But your client still only needs to know about the Strategy interface.

It also works if your strategy method takes parameters, but then your client knows about those parameters and passes them to all implementations it works with.

Implementing Strategy Pattern Without Significant Branching

Of course not. Even if you use an IoC container, you will have to have conditions somewhere, deciding which concrete implementation to inject. This is the nature of the Strategy pattern.

I don't really see why people think this is a problem. There are statements in some books, like Fowler's Refactoring, that if you see a switch/case or a chain of if/elses in the middle of other code, you should consider that a smell and look to move it to its own method. If the code within each case is more than a line, maybe two, then you should consider making that method a Factory Method, returning Strategies.

Some people have taken this to mean that a switch/case is bad. This is not the case. But it should reside on its own, if possible.

Best Answer

Related Solutions

Java – Modified Strategy Design Pattern

Implementing Strategy Pattern Without Significant Branching

Related Topic