C#委托与面向对象的策略设计模式

我想知道在实现策略设计模式时，使用委托与OOP的利弊是什么

你推荐用哪一种？或者代表解决了什么样的问题？如果OOP更好，我们为什么要使用OOP呢

谢谢

---

-tep

我喜欢使用界面来抽象我的策略。然后，我的具体实现为每个策略提供了一个可见的文件。当使用类而不是方法时，它为您提供了更大的灵活性。我可以使用Rhino模拟来模拟策略，并围绕它进行测试。我还可以很容易地使用DI框架，比如Ninject，非常容易地在应用程序范围内绑定策略。我主要在WinForm对话框中使用代理来提取实现。

这两种技术都是强大而有价值的——以下是我对何时使用哪种技术的一些看法

当策略：

维持状态

需要配置

使用依赖项注入

需要由IoC容器配置（考虑ConnectionProvider）

结合多种职责（想想ADO.NET中的DataAdapter）

太复杂或与单个方法一样长

很可能被子类化以创建新策略

需要将状态信息返回给调用方

需要访问应用于的对象的内部

将需要太多的直接参数

否则，倾向于使用基于Func或Action的委托，尤其是在

可能有各种各样的策略（思考排序表达式）

策略最好用lambda表示

您希望利用现有的方法

---

赞成代表们：

• 使用lambda表达式和动态方法以轻量级的方式更容易实现委托
• 可以使用具有正确签名的“普通”方法创建委托
• 多播代理有时会很有用（尽管在事件之外相对较少）

有利于接口：

• 一个对象可以实现一个接口，还可以做其他事情：委托就是委托
• 一个接口可以有多种方法；一个代理只有一个

可以走任何一条路：

• 对于接口，最终有两个名称：接口和方法。对于代表，你只需要一个。我经常发现单个方法接口要么重复相同的名称两次（有变化），要么方法名称非常平淡

---

就我个人而言，我非常喜欢代理的灵活性，但这取决于具体情况。

在我看来，如果使用代理，那么实际上并不是在实现代理。实际上，您正在实现更类似于。设计模式的全部要点是，当你说“我在这里使用了策略模式”时，每个人对你所做的事情都有很多背景知识。当你开始说“除了我自己的修改之外，我一直在使用策略模式”之类的话时，事情就变得危险了

但是，如果我理解你想说的话，策略模式的一个优点是，对于委托来说，它不是很清楚，你可以有一个实现策略的对象层次结构

假设我正在测试某个软件。我想用鼠标和键盘来测试它。因此，我将实现一个策略模式，以插入用于每个测试用例的接口方法。。。因此，我可以编写一次测试用例，并使用MouseStragy和KeyboardStrategy完全运行它。从那里我可以实现专门化，比如MouseeExceptForDialogsStrategy，MouseStragey的专门化。熟悉OOP概念的人很容易理解这种层次结构，以及如何扩展和覆盖它。。。然而，如何在代表中实现和扩展这一点要复杂得多，也非常模糊

---

就像很多事情一样。。。这不是一个“你能做到吗？”的问题，而是“你应该做到吗？”。

根据这一观点：

委托和接口之间的主要区别在于，虽然委托减少了代码基础并提高了代码的可读性，但必须小心使用它们，否则最终可能会牺牲可测试性。接口编码通常更可靠，即使它需要更多的代码