+10  A: 

You sir are correct and your coworker needs to read the GoF.

"The strategy pattern lets the algorithms vary independently from clients that use them."

See:

http://www.dofactory.com/Patterns/PatternStrategy.aspx

D. P. Bullington
it lets the algorithms vary, but does it let their result vary? i.e.: it lets the implementation vary, but what about the interface? that's what the question is about.
?? the question specifically stated "We both agree that the strategy pattern allows for the guts of a class (e.g., the behavior) to be swapped out at runtime while maintaining the same interface"
Bob The Janitor
"vary independently from clients" ok, but how do they vary amongst each other (strategy vs. strategy)? That's the question.
eljenso
bob: by interface i mean contract, i.e. behavior
eljenso: they vary as they can output different results
tranced_UT3
What about the example of using different hashing algorithms, e.g. Each subclass might have a method called: ReturnHash(), but one might implement SHA1 and one might implement MD5. The net result of these subclasses is a hash, but it is a different hash, so the output is different. Would SHA1 and MD5 be different strategies?The output of each method is different, but they are both hashes.
funkymushroom
+3  A: 

I support your opinion. Different strategies can do very different things as long as they can be used in the same context.

For example, if you want to visit each node in a tree, valid strategies could be:

  • Depths-first search pre-order
  • DFS post-order
  • BFS
  • randomized
  • ...

All strategies would visit the nodes in a different order, yet the objective (visiting each node) would be the same. So if the order does not matter, either strategy fits your needs.

Ferdinand Beyer
A: 

I also have to agree. A good example would be a pricing calculator strategy. You could have different strategies for calculating the final amount of an invoice depending on several variables like quantity of items, type of customer, shipping destination, etc. Each of those strategies would definitely be expected to return a different result and it would still be considered a Strategy pattern.

Rezlaj
+1  A: 

According to "Head first Design Patterns" (see here) page 24

"The Strategy Pattern defines a family of algorithms,
encapsulates each one, and makes them interchangeable.
Strategy lets the algorithm vary independently from
clients that use it. "

so sir you are correct, at least according to the people who defined the pattern, but what do they know.

Bob The Janitor
+2  A: 

FWIW, the Wikipedia article agrees with you and has never heard of her position.

chaos
+5  A: 

Technically, strategies can do whatever they want.

It is only when the "outer context" dictates some fixed and repeatable behaviour that cannot be captured in the programmatical interface (call them "desirable properties"), that you need to take care that your strategies are truly substitutable à la Liskov with respect to these desirable properties.

eljenso
+1  A: 

You are. The point of the strategy is to substitute the algorithm. Whether they deliver the same result is a by-product of the desired behavior.

Jack BeNimble
+2  A: 

The first two are strategies. Becuase for any input they will give you the EXACT same answer. the last one is not. Just becuase it gives you an int does not make it a strategy. They have to "DO" the same thing.

They have to do the same thing, but that doesn't mean they give the exact same result. The motivating example from the GoF is one of different layout algorithms, or different register allocation algorithms. The strategies have the same goal - layout blocks of text and images on a page, or assigning virtual registers to hardware registers - but they don't have to create exactly the same result.

So if the goal of the Strategy in your example is to do any arithmetic with the input, then each example is a strategy for that goal. If the goal was to sum the array it is passed, DoArithmatic would have been called CalculateSum, and the final example would fail to conform to the contract of the strategy, and so violate LSP.

Pete Kirkham
+1  A: 

I think it would be more correct to say that the question of whether the strategies must be deterministically identical is outside the scope of the definition of the strategy pattern.

If a function always returns the same result for given inputs, it is deterministic. If two functions are deterministic and they always return the same value for the same inputs then they are deterministically equivalent. They may or may not have the same side effects; if they do then they are just plain equivalent.

Typically this is not the case. Let us consider an example that appears to require deterministic equivalence: sorting. You might think that if two comparer implementations fail to return the same result for the same inputs then at least one of them must be faulty, but this is not necessarily the case.

Sort orders vary between countries. Some places sort accent-insensitively. Some put McDuck with MacDuck, and so forth. These are strategies, this is a perfect application of strategy pattern, and the strategies are most certainly not deterministically equivalent.

You win.

Peter Wone