委托与OOP的C＃策略设计模式
我想知道在实施战略设计模式时使用委托与OOP的优缺点是什么？
你建议使用哪一种？ 或委托解决什么样的问题？ 如果OOP更好，我们为什么要使用OOP？
谢谢！
-tep
这两种技术都是强大而有价值的 – 以下是我对何时使用哪种技术的看法。
策略时使用接口/实现方法：
- 维持国家
- 需要配置
- 使用dependency injection
- 需要由IoC容器配置（想想ConnectionProvider）
- 结合多种职责（想想ADO.NET中的DataAdapter）
- 太复杂或太长，只是一种方法
- 可能会被子类化以创建新策略
- 需要将状态信息返回给调用者
- 需要访问对象的内部是适用的
- 需要太多的直接参数
否则，倾向于使用基于Func <>或Action <>的委托，尤其是如果
- 可能有很多种策略（想想排序表达式）
- 该策略最好表达为lambda
- 您想要利用现有方法
代表们支持：
- 使用lambda表达式和动态方法，代表更容易以轻量级方式实现
- 可以使用正确的签名从“普通”方法创建代理
- 多播的代表有时会很有用（尽管外部事件相对较少）
赞成接口：
- 一个对象可以实现一个接口，还可以做其他事情：委托只是一个委托
- 一个接口可以有多种方法; 代表只有一个
可以去任何一种方式：
- 使用接口，您最终会得到两个名称：接口和方法。 与代表你只有一个。 我经常发现单方法接口重复相同的名称两次（带变化）或方法名称非常乏味
就个人而言，我个人非常喜欢他们的灵活性，但这取决于具体情况。
在我看来，如果你使用代理，那么你实际上并没有实现战略模式 。 你实际上正在实现更类似于Observer模式的东西。 设计模式的全部意义在于，当你说“我在这里使用了战略模式”时，每个人都有很多关于你所做的事情的背景。 当你开始说“我已经使用了战略模式，除了我自己的个人修改，”然后事情变得冒险。
但是，如果我理解你要说的是什么，关于策略模式的一个好处就是代理人不太清楚，你可以拥有一个实现策略的对象层次结构。
让我们说我正在测试一些软件。 我想用鼠标和键盘测试它。 所以我将实现一个策略模式来插入用于每个测试用例的接口方法……所以我可以编写一次测试用例并使用MouseStrategy和KeyboardStrategy完全运行它。 从那里我可以实现专业化，如MouseExceptForDialogsStrategy，MouseStrategy的专业化。 任何熟悉OOP概念的人都很容易理解这种层次结构，如何扩展它并覆盖它……而如何用代表实现和扩展它更复杂，更加模糊。
和许多事情一样……这不是“你能做到吗？”的问题，而是“你应该这样做吗？”。
我喜欢使用界面来抽象我的策略。 然后，我的具体实现为每个策略都有一个可见文件。 使用Class而不是方法时，它会为您提供更大的灵活性。 我可以使用Rhino模拟来模拟测试它的策略。 我也可以很容易地使用像Ninject这样的DI框架来非常容易地绑定策略应用程序。 我使用Delegates主要在WinForm对话框中提取实现。