Difference between Strategy pattern and Delegation pattern

Question

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

Toffee

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

Deprivation

Is delegation pattern the same thing as dependency injection? – Madrepore

@ShaChris23: No. Dependency injection removes the hardcoding of dependencies, and allows alternative implementations of those dependencies to be used (either at runtime or compile time). The class that uses the dependency, is not responsible for creating the dependency: it is "injected" in from the outside. The delegation pattern just delegates work to other objects. Those objects may or may not be "dependencies", and they may or may not have been injected in from the outside. – Kalb

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.

Absenteeism

I know how Strategy pattern works using delegation. Wikipedia defines delegation pattern and strategy pattern both without any reference to each other. Which made me wonder if they differ in their intent. en.wikipedia.org/wiki/Strategy_pattern en.wikipedia.org/wiki/Delegation_pattern Thanks. – Toffee

You could consider Strategy to be more high-level (or even more heavyweight) than Delegation. Also, Delegation is probably a lot more common. – Absenteeism

the delegation_pattern in wikipedia looks like bs... i don't think it's a real pattern. it is not a commonly known or accepted pattern. the purpose of a pattern is that you could have a 100 developers in the room and when you talk about a specific pattern, the default classes, structure, methods, and relationships are already known by all of them. i suspect if you mentioned "delegation pattern" to a 100 developers, most would give you quizzical looks. – Deprivation

@mson: To say that "the purpose of a pattern" is so that when one developer talks about it, the other 99 know what (s)he is talking about, is clearly not true. The purpose of a software design pattern is to solve some problem in an efficient way, leaving you with a code-base that works now, and is easy to maintain and change so that it works in the future too. Admittedly, the fact that the other developers on the team know what you are talking about when you discuss a pattern is... desirable! But it isn't the "purpose" of a pattern. – Kalb

@Deprivation Just because a pattern doesn't get used in your favorite programming language doesn't make it not a pattern. Delegation for example is extremely common pattern in idiomatic Objective-C. A fun thought experiment is that if your favorite language seems to have a lot of patterns, there might be something wrong with the language as people are having to work around some deficiency within it. – Scandinavia

@Scandinavia - a 5 year old can mash up the keyboard and call it the fist pattern. most software developers probably wouldn't understand it and it would not really be a pattern. that 5 year old can get his classmates to understand and use the fist pattern. still, most software developers probably wouldn't understand it and it would not really be a pattern... if that 5 year old can get 1000s of computer science professionals and jon skeet and 10s of thousands of developers to understand and use his fist pattern, then it might be a pattern. – Deprivation

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.

Acanthus

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

Platinum