views:

502

answers:

2

What is the difference between strategy pattern and delegation pattern (not delegates)?

+2  A: 

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

skaffman
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. http://en.wikipedia.org/wiki/Strategy_patternhttp://en.wikipedia.org/wiki/Delegation_patternThanks.
hIpPy
You could consider Strategy to be more high-level (or even more heavyweight) than Delegation. Also, Delegation is probably a lot more common.
skaffman
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.
mson
+5  A: 

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

mson
Is delegation pattern the same thing as dependency injection?
ShaChris23