策略模式和委托模式(不是委托)有什么区别?
4 回答
策略模式是针对常见软件问题的一种非常具体的设计解决方案。策略模式意味着将有
- 一个称为 Strategy 的接口(或以 Strategy 作为名称的一部分)。这个接口应该有一个叫做execute()的方法。
- 一个或多个具体类,称为具体策略 A、具体策略 B 等,它们实现了策略接口。
- 还应该有一个包含 Strategy 的上下文类
委托与其说是一种模式,不如说是一种主体。委托意味着不是让单个对象负责所有事情,而是将职责委托给其他对象。这是一种常见技术的原因是它通过减少耦合和增加内聚性来强制执行软件开发的两个更基本的原则。
说了这么多,不要担心模式。专注于原则,如果您觉得您的解决方案可以改进 - 查看模式,看看是否有更好的捕鼠器。如果你专注于模式而不是原则,你会发现自己迷失在所有模式中,为了实现模式而实现模式......
“委托”并不是真正的设计模式,它更像是一种通用的编程技术,组件 A 将任务(可能是任何类型的任务)委托给组件 B。委托可以在许多情况下使用。
另一方面,策略模式是一种特定模式,通常大量使用委托作为实现细节。
例如,您可以实现策略模式并使用
strategy.execute(x)
策略模式涉及拥有 Strategy 接口的各种实现,并在运行时选择适当的实现。调用该实现的行为是委托。
所以这不是非此即彼的,这些概念是互补的。
这里有一个想法:
代表模仿委托类(至少在我使用它们时,不确定这是否是规范的方式,但我通常是这样做的)。所以基本上,如果我有一个有多个入口点(方法)的类,并且我想在运行时更改实现,我会创建委托来实现相同的接口。
另一方面,如果我希望能够在运行时交换类的一部分,我将创建具有单个方法接口(例如 executeCalculation)的 Strategy 类,并使其成为包含类的聚合组件.
所以总而言之,一个策略包含一个行为,委托实现一组行为,你可以使用委托来实现策略。
如果您的意思是策略模式与委托,例如作为参数传递的函数/lambda,那么至少我知道在需要为委托编译的类方面开销较少。
实际上,我发现这个页面正在寻找有人给我他们关于仍然使用设计模式路由的好处的想法,因为 Java 8 和 C# 现在都支持将函数作为参数传递