C# Strategy Design Pattern by Delegate vs OOP

Question

I wonder what's the pros/cons of using delegate vs OOP when implementing strategy design pattern?

Which one do you recommend to use? or what kind of problem does delegate solve? and why should we use OOP if OOP is better?

Thanks!

-tep

Answer 1

Both techniques can be powerful and valuable - here are some of my opinions about when to use which.

Use an Interface/Implementation approach when the strategy:

2. maintains state
3. needs configuration
4. uses dependency injection
5. needs to be configured by an IoC container (think ConnectionProvider)
6. combines multiple responsibilities (think DataAdapter from ADO.NET)
7. is too complex or long as a single method
8. is likely to be subclassed to create new strategies
9. needs to return state information to the caller
10. needs to access internals of the object is applies to
11. Would require too many direct parameters

Otherwise, tend to use delegates based on Func<> or Action<>, especially if

1. There are likely to be a very large variety of strategies (think sort expressions)
2. The strategy is best expressed as as lambda
3. There's an existing method you want to leverage

Answer 2

In favour of delegates:

• Delegates are easier to implement in a light-weight way using lambda expressions and dynamic methods
• Delegates can be created from "normal" methods with the right signature
• Delegates being multi-cast can be useful at times (though relatively rarely outside eventing)

In favour of interfaces:

• An object can implement an interface and still do other things: a delegate is just a delegate
• An interface can have multiple methods; a delegate just has the one

Could go either way:

• With interfaces you end up with two names: the interface and the method. With delegates you just have the one. Often I find that single-method interfaces either repeat the same name twice (with variations) or the method name is very bland

Personally I'm a big fan of delegates for their flexibility, but it really depends on the situation.

Answer 3

In my opinion, if you use delegates then you're not actually implementing the Strategy pattern. You're actually implementing something more akin to the Observer pattern. The whole point of design patterns is that when you say "I've used the Strategy pattern here," everyone has a lot of context on what you've done. When you start saying things like "I've used the Strategy pattern except with my own personal modifications," then things get dicey.

But, if I understand what you're trying to say, one of the nice things about the Strategy pattern that isn't so clear with delegates is you can have a hierarchy of objects that implement a strategy.

Let's say that I'm testing some piece of software. I want to test it using the mouse and using the keyboard. So I'll implement a Strategy pattern to plug in the interface method to use for each test case ... so I can write the test case once and run it completely using the MouseStrategy and KeyboardStrategy. From there I can implement specializations such as MouseExceptForDialogsStrategy, a specialization of MouseStrategy. This sort of hierarchy, how to extend it and override it is easily understood by anyone familiar with OOP concepts ... whereas how to achieve and extend the same with delegates is much more complicated and very much more obscure.

As with many things ... it is not a question of "can you do it?", but "should you do it?".

Answer 4

I like to use an interface to abstract my strategy. My concrete implementations then have a visible file for each strategy. When working with a Class instead of a method it gives you more flexibility. I can use Rhino mocks to mock out the strategy to test around it. I can also easy use DI frameworks such as Ninject to bind the strategy application wide very easily. I use Delegates to extract the implementation mostly in WinForm Dialogs.