策略模式和委托模式的区别
策略模式和委派模式（不是代表）有什么区别？
What is the difference between Strategy pattern and Delegation pattern (not delegates)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
策略模式和委派模式（不是代表）有什么区别？
What is the difference between Strategy pattern and Delegation pattern (not delegates)?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（4）
策略模式是针对常见软件问题的非常具体的设计解决方案。
策略模式意味着将有
委托的上下文类，它更多的是一个主体而不是一个模式。 委托意味着不是让单个对象负责所有事情，而是将责任委托给其他对象。 这是一种常见技术的原因是，它通过减少耦合和增加内聚性来强制执行软件开发的两个更基本的原则。
说了这么多，不用担心模式。 专注于原理，如果您认为您的解决方案可以改进 - 查看模式，看看是否有更好的捕鼠器。 如果您关注模式而不是原则，您会发现自己迷失在所有模式中，并且为了实现模式而实现模式......
the strategy pattern is a very specific design solution to a common software problem.
the strategy pattern implies that there will be
delegation is more a principal than a pattern. delegation implies that instead of having a single object be in charge of everything, it delegates responsibilities to other objects. the reason this is a common technique is that it enforces two even more fundamental principals of software development by lessening coupling and increasing cohesiveness.
Having said all that, don't worry about patterns. Focus on the principals and if you feel your solution could be improved upon - look to the patterns to see if there is a better mousetrap. If you focus on patterns instead of principals, you will find yourself getting lost in all the patterns and implementing patterns for the sake of implementing patterns...
“委托”并不是真正的设计模式，它更像是一种通用编程技术，其中组件 A 将任务（无论是什么类型的任务）委托给组件 B。委托可以在许多上下文中使用。
另一方面，策略模式是一种特定的模式，通常大量使用委托作为实现细节。
例如，您可以实现策略模式并使用调用它。
策略模式涉及策略接口的各种实现，并在运行时选择适当的实现。 调用该实现的行为就是委托。
所以这不是非此即彼的问题，这些概念是互补的。
"Delegation" isn't really a design-pattern, it's more of a general programming technique, where component A delegates the task (whatever kind of task that may be) to component B. Delegation can be used in many contexts.
The Strategy pattern,on the other hand, is a specific pattern which typically makes heavy use of delegation as an implementation detail.
For example, you might implement the strategy pattern and invoke it using
The strategy pattern involves having various implementations of your Strategy interface, and selecting the appropriate implementation at runtime. The act of invoking that implementation is delegation.
So it's not either/or, the concepts are complimentary.
如果您指的是策略模式与委托，就像作为参数传递的函数/lambda 一样，
那么至少我知道需要为委托编译的类的开销更少。
事实上，我发现这个页面正在寻找有人向我提供他们对仍然使用设计模式路线的好处的想法，因为 java 8 和 C# 现在都支持将函数作为参数传递
if you meant strategy pattern vs delegates, as in functions/lambdas passed as arguments,
then at least I know there is less overhead in terms of classes that need to be compiled for delegates.
I actually found this page looking for someone to give me their thoughts on the benefits of still using the design pattern route given that both java 8 and C# now support passing functions as arguments
这是一个想法：
委托模仿委托类（至少在我使用它们时，不确定这是否是规范的方式，但我通常就是这样做的）。 所以基本上，如果我有一个具有多个入口点（方法）的类，并且我想在运行时更改实现，我将创建实现相同接口的委托。
另一方面，如果我希望能够在运行时交换类的一部分，我将使用单个方法接口（例如executeCalculation）创建策略类，并将其作为包含类的聚合组件。
总之，策略包含单个行为，委托实现一组行为，并且您可以使用委托来实现策略。
Here's a thought:
Delegates mimic the delegating class (at least as I've used them, not sure if that's the canonical way or not but that's how I usually do it). So basically, if I have a class that has multiple entry points (methods) and I want to change the implementation at runtime, I would create delegates the implement the same interface.
If, on the other hand, I had one part of a class that I want to be able to interchange at runtime, I would create Strategy classes with a single method interface (eg. executeCalculation) and make it an aggregate component of the containing class.
So in summary, a strategy encompasses a single behavior, delegates implement a set of behaviors, and you could use delegates to implement strategies.