Difference between Strategy pattern and Delegation pattern

Question

What is the difference between Strategy pattern and Delegation pattern (not delegates)?

Answer 1

the strategy pattern is a very specific design solution to a common software problem. the strategy pattern implies that there will be

• an interface called Strategy (or with Strategy as part of the name). this interface should have a method called execute().
• one or more concrete classes called something like ConcreteStrategyA, ConcreteStrategyB, etc. that implement the Strategy interface.
• there should also be a context class that contains the Strategy

delegation is more a principal than a pattern. delegation implies that instead of having a single object be in charge of everything, it delegates responsibilities to other objects. the reason this is a common technique is that it enforces two even more fundamental principals of software development by lessening coupling and increasing cohesiveness.

Having said all that, don't worry about patterns. Focus on the principals and if you feel your solution could be improved upon - look to the patterns to see if there is a better mousetrap. If you focus on patterns instead of principals, you will find yourself getting lost in all the patterns and implementing patterns for the sake of implementing patterns...

Answer 2

"Delegation" isn't really a design-pattern, it's more of a general programming technique, where component A delegates the task (whatever kind of task that may be) to component B. Delegation can be used in many contexts.

The Strategy pattern,on the other hand, is a specific pattern which typically makes heavy use of delegation as an implementation detail.

For example, you might implement the strategy pattern and invoke it using

strategy.execute(x)

The strategy pattern involves having various implementations of your Strategy interface, and selecting the appropriate implementation at runtime. The act of invoking that implementation is delegation.

So it's not either/or, the concepts are complimentary.

Answer 3

Here's a thought:

Delegates mimic the delegating class (at least as I've used them, not sure if that's the canonical way or not but that's how I usually do it). So basically, if I have a class that has multiple entry points (methods) and I want to change the implementation at runtime, I would create delegates the implement the same interface.

If, on the other hand, I had one part of a class that I want to be able to interchange at runtime, I would create Strategy classes with a single method interface (eg. executeCalculation) and make it an aggregate component of the containing class.

So in summary, a strategy encompasses a single behavior, delegates implement a set of behaviors, and you could use delegates to implement strategies.

Answer 4

if you meant strategy pattern vs delegates, as in functions/lambdas passed as arguments, then at least I know there is less overhead in terms of classes that need to be compiled for delegates.

I actually found this page looking for someone to give me their thoughts on the benefits of still using the design pattern route given that both java 8 and C# now support passing functions as arguments