在 C# 中，策略模式和委托有什么区别？
我一直在研究策略模式实现示例，在我看来它们与 C# 委托非常相似。 我看到的唯一区别是策略模式实现不需要显式声明委托。
但除此之外，它们似乎都指向需要特定签名的函数，并且都可以用来确定在运行时执行的内容。
我错过了更明显的区别吗？
我想一个相关的问题是，如果它们相似，那么使用其中一个相对于另一个有什么优势？
I've been looking at strategy pattern implementation examples and it seems to me like they are very similar to c# delegates. The only difference I see is that strategy pattern implementations don't need to explicitly declare a delegate.
But other than that, they both seem to point to functions that need a specific signature and they can both be used to determine what to execute at run time.
Is there a more obvious difference that I am missing?
I guess a related question would be, IF they are similar, what's the advantage of using one over the other?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
简而言之，您可以使用委托来实现策略模式。
战略模式是一种模式。 委托是一种语言功能。 您可以使用语言功能来实现该模式。 它们完全属于两个不同的概念类别，但彼此之间的相互作用相关。
换句话说，策略模式是蓝图，C# 代表是砖块。 没有这两者，你就无法建造（战略模式）房子。 （您也可以使用其他类型的砖块来构建它，但是委托的语言特性中没有任何内容本质上描述了策略模式）。
Put simply, you can use delegates to implement strategy pattern.
Strategy pattern is a pattern. Delegates are a language feature. You use the language feature to implement the pattern. They reside in two separate categories of concepts altogether, but are related in their interaction with each other.
In other words, strategy pattern is the blueprint, the C# delegates are the bricks. You can't build the (strategy pattern) house without either. (You could build it with other kinds of bricks also, but nothing in the language feature of delegates inherently describes strategy pattern).
设计模式是与语言无关的、针对常见问题的高级解决方案。
委托可用于 .NET 策略模式的特定于平台实现，但并不是实现此类解决方案的唯一方法。
另一种解决方案是定义一个接口，如下所示：
然后，策略将由实现该接口的类来表示，而不是由委托来表示。
如果您希望您的策略非常简单，那么委托可能是一个不错的实现。 对于任何相当复杂的事情，将策略实现为接口可以为您提供更多选择，例如跟踪状态、将事物组织到多个方法中、在实现之间共享代码等。
Design Patterns are language agnostic, high-level solutions to commonly-encountered problems.
Delegates can be used in a platform-specific implementation of the strategy pattern for .NET, but aren't the only way of implementing such a solution.
An alternative solution is to define an interface like:
Strategies would then be represented by classes implementing this interface, rather than by a delegate.
Delegates may be an okay implementation if you expect your strategies to be very simple. For anything reasonably complex, implementing strategies as interfaces gives you a lot more options when it comes to keeping track of state, organizing things into multiple methods, sharing code between implementations, etc.
您还如何在 C# 中实现策略模式？
How else would you implement the strategy pattern in C#?
模式是一个架构问题。 代表是执行的问题。
在 C# 中，策略模式几乎总是使用委托来实现。
Patterns are a matter of architecture. Delegates are a matter of implementation.
In C#, a strategy pattern will nearly always be implemented using a delegate.
策略模式是一种设计模式，允许您在执行时选择不同的函数，而委托是一种语言构造，允许您创建对函数的引用并将其用作变量。
策略模式最好用多态而不是委托来实现，因为多态分派往往更优雅。
The strategy pattern is a design pattern that allows you to choose distinct functions at execution time while a delegate is a language construct that allows you to create a reference to a function and use it as a variable.
The strategy pattern is better implemented with polymorphism rather than delegates as polymorphic dispatch tends to be more elegant.
委托可以被视为类似于 Java 中使用的函数式接口 - 本质上是一个只有一种方法的接口。
从 Java8 开始，您实际上可以以更加匿名/内嵌的方式提供函数式接口的实现。
对于可以用单一方法覆盖的行为，执行策略实施有点矫枉过正，而且过于冗长。
它们本质上解决了“在类中插入可交换行为”的相同目的
Delegates can be seen similar to a functional interface used in Java - Essentially an interface with just one method.
Starting Java8, you can actually provide implementations to functional interfaces, in a much more anonymous/in-line way.
For a behaviour that can be covered by a single method, doing a strategy implementation is kind of an overkill, and too verbose.
They essentially solve the same purpose of "inserting swappable behaviours in a class"