委托与OOP的C＃策略设计模式

Question

我想知道在实施策略设计模式时使用委托与OOP的优缺点是什么？

您建议使用哪一个？或委托解决什么样的问题？如果OOP更好，我们为什么要使用OOP？

谢谢！

-tep

Answer 1

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

策略时使用接口/实施方法：

1. 维持状态
2. 需要配置
3. 使用依赖注入
4. 需要由IoC容器（想想ConnectionProvider）配置
5. 结合了多个职责（想想来自ADO.NET的DataAdapter）
6. 过于复杂或长篇为单一方法
7. 可能会被创建子类以创建新策略
8. 需要将状态信息返回给调用者
9. 需要访问对象的内部适用于
10. 需要太多直接参数

否则，倾向于使用基于Func＆lt;＆gt;的委托。或动作＆lt;＆gt;，尤其是

1. 可能存在各种各样的策略（想想排序表达式）
2. 策略最好表达为lambda
3. 您希望利用现有方法

Answer 2

赞成代表：

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

赞成接口：

• 一个对象可以实现一个接口，但仍然可以做其他事情：一个委托是只是一个委托
• 界面可以有多种方法;代表只有一个

可以采取任何一种方式：

• 使用接口，您最终会得到两个名称：接口和方法。与代表你只有一个。通常我发现单方法接口重复相同的名称两次（带变化）或方法名称非常乏味

就个人而言，我个人非常喜欢他们的灵活性，但这实际上取决于具体情况。

Answer 3

在我看来，如果你使用代理，那么你实际上并没有实现Strategy pattern。你实际上正在实现更类似于Observer pattern的东西。设计模式的重点在于，当你说“我在这里使用了战略模式”时，每个人都有很多关于你所做的事情的背景。当你开始说“我已经使用了战略模式，除了我自己的个人修改，”然后事情变得冒险。

但是，如果我理解你要说的是什么，关于策略模式的一个好处就是代理人不太清楚，你可以拥有一个实现策略的对象层次结构。

假设我正在测试一些软件。我想用鼠标和键盘测试它。所以我将实现一个策略模式来插入用于每个测试用例的接口方法......所以我可以编写一次测试用例并使用MouseStrategy和KeyboardStrategy完全运行它。从那里我可以实现专业化，如MouseExceptForDialogsStrategy，MouseStrategy的专业化。任何熟悉OOP概念的人都很容易理解这种层次结构，如何扩展它并覆盖它......而如何用代理实现和扩展它更复杂，更加模糊。

与许多事情一样......这不是“你能做到吗？”的问题，而是“你应该这样做吗？”。

Answer 4

我喜欢使用界面来抽象我的策略。然后，我的具体实现为每个策略都有一个可见文件。使用Class而不是方法时，它会为您提供更大的灵活性。我可以使用Rhino模拟来模拟测试它的策略。我也可以很容易地使用像Ninject这样的DI框架来非常容易地绑定策略应用程序。我使用Delegates主要在WinForm对话框中提取实现。

Answer 5

根据Pluralsight blog post：

  

委托与接口之间的主要区别在于，尽管委托减少了代码库并提高了代码的可读性，但您必须谨慎使用它们，否则可能会牺牲可测试性。即使需要更多代码，对接口进行编码通常也更可靠