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 de

Answer 1

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