C# Strategy Design Pattern by Delegate vs OOP

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

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.

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