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

Question

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

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

谢谢!

-tep

Answer 1

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

策略时使用接口/实现方法:

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

否则,倾向于使用基于Func <>或Action <>的委托,尤其是如果

1. 可能有很多种策略(想想排序表达式)
2. 该策略最好表达为lambda
3. 您想要利用现有方法

Answer 2

代表们支持:

• 使用lambda表达式和动态方法,代表更容易以轻量级方式实现
• 可以使用正确的签名从"普通"方法创建代理
• 代表们是多播可以是多次使用(虽然相对很少的外部三项赛)

支持接口:

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

可以去任何一种方式:

• 使用接口,您最终会得到两个名称:接口和方法.与代表你只有一个.我经常发现单方法接口重复相同的名称两次(带变化)或方法名称非常乏味

就个人而言,我是代表们的忠实粉丝,但这实际上取决于具体情况.

Answer 3

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

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

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

和许多事情一样......这不是"你能做到吗？"的问题,而是"你应该这样做吗？".