【发布时间】：2009-06-11 22:15:51
【问题描述】：
我想知道在实施策略设计模式时使用委托与 OOP 的优缺点是什么？
你推荐使用哪一个？或者委托解决什么样的问题？如果 OOP 更好，我们为什么要使用 OOP？
谢谢！
-步
【问题讨论】：
标签： c# design-patterns
【发布时间】：2009-06-11 22:15:51
【问题描述】：
这两种技术都非常强大且有价值 - 以下是我对何时使用哪种技术的一些看法。
策略时使用接口/实现方法：
- 保持状态
- 需要配置
- 使用依赖注入
- 需要由 IoC 容器配置（想想 ConnectionProvider）
- 结合了多种职责（想想来自 ADO.NET 的 DataAdapter）
- 太复杂或像单一方法一样冗长
- 可能会被子类化以创建新策略
- 需要将状态信息返回给调用者
- 需要访问对象内部的适用于
- 需要太多直接参数
否则，倾向于使用基于 Func 或 Action 的委托，尤其是在
- 可能有各种各样的策略（想想排序表达式）
- 该策略最好表示为 lambda
- 您想要利用现有的方法
【讨论】：
赞成代表：
- 使用 lambda 表达式和动态方法更容易以轻量级方式实现委托
- 可以通过具有正确签名的“正常”方法创建委托
- 多播的代表可能有时很有用（尽管在事件之外相对很少）
支持接口：
- 一个对象可以实现一个接口并且仍然可以做其他事情：一个委托只是一个委托
- 一个接口可以有多个方法；一个代表只有一个
无论哪种方式都可以：
- 对于接口，您最终会得到两个名称：接口和方法。有了代表，你就只有一个。我经常发现单方法接口要么重复两次相同的名称（有变体），要么方法名称非常平淡
我个人非常喜欢代表的灵活性，但这确实取决于具体情况。
【讨论】：
在我看来，如果您使用委托，那么您实际上并没有实现Strategy pattern。您实际上正在实现更类似于Observer pattern 的东西。设计模式的全部意义在于，当你说“我在这里使用了策略模式”时，每个人都对你所做的事情有很多背景。当你开始说“我使用了策略模式，除了我自己的个人修改”之类的话时，事情就会变得很冒险。
但是，如果我理解您的意思，关于策略模式的好处之一是委托不太清楚，您可以拥有实现策略的对象层次结构。
假设我正在测试某个软件。我想用鼠标和键盘来测试它。所以我将实现一个策略模式来插入用于每个测试用例的接口方法......这样我就可以编写一次测试用例并使用 MouseStrategy 和 KeyboardStrategy 完全运行它。从那里我可以实现专门化，例如 MouseExceptForDialogsStrategy，MouseStrategy 的专门化。任何熟悉 OOP 概念的人都可以轻松理解这种层次结构，如何扩展和覆盖它……而如何使用委托实现和扩展同样的层次结构要复杂得多，也更加晦涩难懂。
与许多事情一样......这不是“你能做到吗？”的问题，而是“你应该这样做吗？”。
【讨论】：
我喜欢使用接口来抽象我的策略。然后，我的具体实现对每个策略都有一个可见的文件。当使用类而不是方法时，它为您提供了更大的灵活性。我可以使用 Rhino 模拟来模拟策略来测试它。我还可以很容易地使用 Ninject 等 DI 框架来非常轻松地绑定策略应用程序。我主要在 WinForm 对话框中使用 Delegates 来提取实现。
【讨论】：
据此 Pluralsight blog post：
委托和接口之间的主要区别在于，虽然委托减少了代码库并提高了代码的可读性，但您必须谨慎使用它们，否则最终可能会牺牲可测试性。对接口进行编码通常更可靠，即使它需要更多代码
【讨论】：