Does the Strategy Pattern violate the Single Responsibility Principle?

Question

If the Single Responsibility Principle states that every object must have a single reason to change and a single strategy class implemented with the Strategy pattern (by definition) has multiple methods that can change for any number of reasons, does that mean that it's impossible to implement the Strategy pattern without violating the SRP?

Answer 1

How so? Strategy pattern if I recollect is basically a way to decouple the logic/algorithm being used. So Client has m_IAlgorithm. IAlgorithm should have a small set of methods if not one.

So the only reason that a AlgoImplementation class can change is

• if there is a change in the algorithm it implements. (change in its responsibility/behavior)
• or if IAlgoritm changes.. which would be rare unless you made a mistake in defining the interface. (Its a change in its own public interface - so don't think its a violation of SRP.)

Answer 2

I actually see the opposite. The strategy pattern lets you decouple two things, the (potential) algorithms used to get some job done and the decision making logic about these algorithms.

I'm not sure if you rather have a class which does both conditional logic on which algorithm to use and also encloses those algorithms. Also, I'm not saying you've implied that but you didn't gave an example where Strategy would break SRP and what's, in your opinion, a better design.

Answer 3

The context which I am most familiar with the single responsibility principle is in overall system design, and can compliment the strategy pattern with regard to the grouping of components within the system.

Use the strategy pattern to define a set of algorithms that a client uses interchangeably, then the single responsibility principle can be used to decide where to group the client and algorithms the client uses within the system. You don't want to have to disturb the code for algorithm A if your work is solely in algorithm B and vice versa. For compiled languages this can have a significant impact in the complexity of the re-factor, version and deploy cycle. Why version and re-compile the client and algorithms A, C, and D when the only changes needed where to algorithm B.

With this understanding of the single responsibility principle I don't see where having a class that implements the strategy pattern violates SRP. The purpose of the client class is to implement the strategy pattern, that is the clients responsibility. The purpose of the algorithms are to implement the logic that they are responsible for, and the single responsibility principle says don't group them all together within the system since they will be changing for different reasons. That's my $0.02.

Answer 4

Good Point :) I guess it's more a single responsibility guideline, which makes sense for many cases, but for some also not, like the strategy pattern..