【发布时间】：2010-11-16 12:37:21
【问题描述】：
策略模式和委托模式（不是委托）有什么区别？
【问题讨论】：
标签： design-patterns delegation strategy-pattern
【发布时间】：2010-11-16 12:37:21
【问题描述】：
策略模式是针对常见软件问题的一种非常具体的设计解决方案。 策略模式意味着会有
- 一个名为 Strategy 的接口（或以 Strategy 作为名称的一部分）。这个接口应该有一个名为 execute() 的方法。
- 一个或多个具体类，称为具体策略 A、具体策略 B 等，它们实现了策略接口。
- 还应该有一个包含策略的上下文类
委托与其说是一种模式，不如说是一种主体。委托意味着不是让单个对象负责所有事情，而是将职责委托给其他对象。这是一种常见技术的原因是，它通过减少耦合和增加内聚性来强制执行软件开发的两个更基本的原则。
说了这么多，不用担心模式。专注于原则，如果您觉得您的解决方案可以改进 - 查看模式，看看是否有更好的捕鼠器。如果你专注于模式而不是原则，你会发现自己迷失在所有模式中，为了实现模式而实现模式......
【讨论】：
-
委托模式和依赖注入一样吗？
-
@ShaChris23：不。依赖注入消除了依赖的硬编码，并允许使用这些依赖的替代实现（在运行时或编译时）。使用依赖项的类不负责创建依赖项：它是从外部“注入”的。委托模式只是将工作委托给其他对象。这些对象可能是也可能不是“依赖项”，它们可能是从外部注入的，也可能不是。
“委托”并不是真正的设计模式，它更像是一种通用编程技术，其中组件 A 将任务（可能是任何类型的任务）委托给组件 B。委托可以在许多情况下使用。
另一方面，策略模式是一种特定模式，通常大量使用委托作为实现细节。
例如，您可以实现策略模式并使用
strategy.execute(x)
策略模式涉及策略接口的各种实现，并在运行时选择适当的实现。调用该实现的行为就是委托。
所以不是非此即彼，概念是互补的。
【讨论】：
-
我知道策略模式是如何使用委托的。 Wikipedia 定义了委托模式和策略模式，彼此之间没有任何引用。这让我想知道他们的意图是否不同。 en.wikipedia.org/wiki/Strategy_patternen.wikipedia.org/wiki/Delegation_pattern 谢谢。
-
您可以认为策略比委托更高级（甚至更重量级）。此外，委托可能更常见。
-
wikipedia 中的delegation_pattern 看起来像bs ......我不认为这是一个真正的模式。它不是一种众所周知或公认的模式。模式的目的是你可以在房间里有 100 名开发人员，当你谈论一个特定的模式时，默认的类、结构、方法和关系已经为所有人所知。我怀疑如果你向 100 名开发人员提到“委托模式”，大多数人都会给你一个奇怪的表情。
-
@mson：说“模式的目的”是为了当一个开发人员谈论它时，其他 99 人知道他在说什么，显然是不正确的。软件设计模式的目的是以有效的方式解决某些问题，为您留下一个现在可以工作的代码库，并且易于维护和更改，以便将来也可以工作。诚然，当您讨论模式时，团队中的其他开发人员知道您在说什么这一事实是……可取的！但这不是模式的“目的”。
-
@mson 仅仅因为一个模式没有在你最喜欢的编程语言中被使用并不意味着它不是一个模式。 Delegation 例如是惯用的 Objective-C 中极为常见的模式。一个有趣的思想实验是，如果您最喜欢的语言似乎有很多模式，那么该语言可能存在问题，因为人们不得不解决其中的一些缺陷。
这是一个想法：
代表模仿委托类（至少在我使用它们时，不确定这是否是规范的方式，但我通常是这样做的）。所以基本上，如果我有一个有多个入口点（方法）的类，并且我想在运行时更改实现，我会创建委托来实现相同的接口。
另一方面，如果我希望能够在运行时交换某个类的一部分，我将创建具有单个方法接口（例如 executeCalculation）的 Strategy 类，并使其成为包含类。
总而言之，策略包含一个行为，委托实现一组行为，您可以使用委托来实现策略。
【讨论】：
如果您的意思是策略模式与委托，例如作为参数传递的函数/lambda， 那么至少我知道需要为委托编译的类的开销更少。
实际上，我发现这个页面正在寻找有人给我他们关于仍然使用设计模式路由的好处的想法，因为 java 8 和 C# 现在都支持将函数作为参数传递
【讨论】：