4

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?

Luc Touraille
  • 79,925
  • 15
  • 92
  • 137
plaureano
  • 3,139
  • 6
  • 30
  • 29
  • I don't quite get what you mean by "a single strategy class implemented with the Strategy pattern (by definition) has multiple methods that can change for any number of reasons". What's the definition you're thinking of? – Ionuț G. Stan Apr 28 '09 at 07:38
  • I'm thinking of the classical GOF definition of the strategy pattern, which is a single policy class with a set of logically related methods – plaureano Apr 29 '09 at 07:26

5 Answers5

3

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.)
Gishu
  • 134,492
  • 47
  • 225
  • 308
3

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.

Ionuț G. Stan
  • 176,118
  • 18
  • 189
  • 202
2

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.

snarkyname77
  • 1,154
  • 1
  • 10
  • 23
0

Depends on the point of view IMO. If you look at strategy (class for example) as a mixture of algorithms/logic which is decided on run-time and they are quite different from one another.... yeah kinda violates the single responsibility pattern... but if you think about this strategy class it's a decoupling entity which encapsulates the whole decision making and making it a single-job class - to decide which algorithm/logic is goint to be used and does nothing more, nothing less

pofqggg
  • 141
  • 2
  • 11
0

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..

Nils
  • 13,319
  • 19
  • 86
  • 108