Design patterns 战略模式与授权模式的区别

策略模式和委派模式（不是委派）之间有什么区别？

委派”实际上不是一种设计模式，它更多的是一种通用编程技术，组件a将任务（无论是什么类型的任务）委派给组件B。委派可以在许多上下文中使用

另一方面，策略模式是一种特定的模式，通常大量使用委托作为实现细节

例如，您可以实现策略模式并使用

strategy.execute(x)

策略模式包括拥有策略接口的各种实现，并在运行时选择适当的实现。调用该实现的行为就是委托

---

因此，这不是非此即彼，概念是互补的。

策略模式是针对常见软件问题的非常具体的设计解决方案。 战略模式意味着

• 一个名为Strategy（或名称中包含Strategy）的接口。此接口应具有名为execute（）的方法
• 一个或多个称为ConcreteStrategyA、ConcreteStrategyB等的具体类，用于实现策略接口
• 还应该有一个包含策略的上下文类

授权与其说是一种模式，不如说是一种原则。委托意味着，它不是让一个对象负责所有事情，而是将责任委托给其他对象。这是一种常见技术的原因是，它通过减少耦合和增加内聚性来强化软件开发的两个更基本的原则

说到这里，不要担心模式。专注于原则，如果你觉得你的解决方案可以改进，看看模式，看看是否有更好的捕鼠器。如果你专注于模式而不是原则，你会发现自己迷失在所有模式中，为了实现模式而实现模式

这里有一个想法：

委托模仿委托类（至少在我使用它们时是这样，不确定这是否是规范的方式，但我通常是这样做的）。因此，基本上，如果我有一个具有多个入口点（方法）的类，并且我想在运行时更改实现，那么我将创建委托来实现相同的接口

另一方面，如果我希望在运行时能够交换类的一部分，我将使用单个方法接口（例如executeCalculation）创建策略类，并使其成为包含类的聚合组件

---

总之，一个策略包含一个行为，代理实现一组行为，您可以使用代理来实现策略

如果您指的是策略模式与委托，如函数/lambda作为参数传递， 然后，至少我知道，就需要为委托编译的类而言，开销较小

---

事实上，我发现这个页面正在寻找一些人来告诉我仍然使用设计模式路线的好处，因为java 8和C#现在都支持将函数作为参数传递

我知道使用委托的策略模式是如何工作的。维基百科定义了委托模式和策略模式，两者都没有相互引用。这让我怀疑他们是否有不同的意图。谢谢。你可以认为战略比代表团更高级（甚至更重）。此外，委派可能更常见。维基百科中的委派模式看起来像bs。。。我认为这不是一个真正的模式。这不是一种普遍已知或公认的模式。模式的目的是让100名开发人员在房间里，当你谈论一个特定的模式时，他们都知道默认的类、结构、方法和关系。我怀疑，如果你向100名开发人员提到“委托模式”，大多数人都会给你带去疑惑的表情。@mson：说“模式的目的”是当一名开发人员谈论它时，其他99名开发人员知道他在说什么，这显然是不正确的。软件设计模式的目的是以一种有效的方式解决一些问题，为您留下一个现在可以使用的代码库，并且易于维护和更改，以便将来也可以使用。诚然，当您讨论模式时，团队中的其他开发人员知道您在谈论什么，这一事实是。。。令人向往！但这不是模式的“目的”。@mson仅仅因为模式没有在您喜爱的编程语言中使用，并不意味着它不是模式。例如，这是惯用Objective-C中极为常见的模式。一个有趣的思维实验是，如果你最喜欢的语言似乎有很多模式，该语言可能有问题，因为人们不得不解决其中的一些缺陷。委派模式与依赖项注入相同吗？@ShaChris23:否。依赖项注入删除依赖项的硬编码，并允许使用这些依赖项的替代实现（在运行时或编译时）。使用依赖项的类不负责创建依赖项：它是从外部“注入”的。委派模式只是将工作委派给其他对象。这些对象可能是也可能不是“依赖项”，它们可能是也可能不是从外部注入的。