【发布时间】：2014-03-13 13:41:43
【问题描述】：
与在显式方法中实现相比，传递策略以作为方法参数执行有什么优势？例如，考虑这个计算器类：
编辑以包含 IOperation 接口
public class Calculator
{
public double DoOperation(IOperation operation, double num1, double num2)
{
return operation.Execute(num1, num2);
}
}
public interface IOperation
{
double Execute(double num1, double num2);
}
public class AddOperation : IOperation
{
public override double Execute(double num1, double num2)
{
return num1 + num2;
}
}
// Leaving out implementations for SubtractOperation, DivideOperation, and MultiplyOperation
相对于：
public class Calculator
{
public double Add(double num1, double num2)
{
return num1 + num2;
}
public double Subtract(double num1, double num2)
{
return num1 - num2;
}
public double Multiply(double num1, double num2)
{
return num1 * num2;
}
public double Divide(double num1, double num2)
{
return num1 / num2;
}
}
使用策略模式，如果需要添加操作，则必须创建并测试一个新类。在第二个示例中，您必须创建并测试一个新方法。对我来说似乎有同样的区别。事实上，我更喜欢显式方法名称版本，因为我认为它更容易理解。
我能想到的策略模式只有一个优势。也就是说，如果您正在开发一个供其他人使用的框架，而您确实无法确定其他人可能会实施什么策略。
在所有其他情况下，始终可以实施有限数量的策略。那么，策略模式与显式方法名称“模式”相比有什么优势？
编辑
感谢 Markus，我可以想到上述模式的另一个优势。在第一个示例中，如果 DoOperation() 方法执行更复杂的算法，并且仅使用该策略来分解出不同的代码，那么这将是 DRY 的示例。而且，如果将不同的代码分解为策略，那么能够单独测试策略和公共部分就会有明显的好处。
【问题讨论】：
-
这看起来不像我所知道的策略模式（没有接口，没有继承）。我将您的示例称为委托模式。据我所知，策略模式的重点是允许您在从正确的角度看待某个类型的变体时将它们视为相同，因为它们都具有相同的方法。我建议你有 3 种计算器，一种用于 bin，一种用于 Deci，一种用于 Hex。驱动程序不知道他们有哪种计算器，但可以在其中任何一个上运行 Add(op1, op2)，并获得特定于实现的结果。
-
这不是策略模式，应该是：
public class Calculator { private IOperationStrategy _innerStrategy; public double DoOperation(double num1, double num2) { return _innerStrategy.Execute(num1, num2); } public void SetOperation(IOperationStrategy strategy) { _innerStrategy = strategy } }抱歉，在 cmets 中格式丢失了。 -
好吧，我没有包括 IOperation 接口和具体实现，因为我认为它很清楚。但是，我可以编辑问题以包含它们。那么，您是说策略模式需要 一个私有成员变量来保存策略吗？这似乎是一个微不足道的区别。
-
这不是策略 - 看起来更像是命令。 en.wikipedia.org/wiki/Command_pattern#Example 优点在en.wikipedia.org/wiki/Command_pattern#Uses模式中说明了
-
@Fuhrmantor 感谢您的链接。他们提供了丰富的信息。然而，关于策略模式的 wiki 文章与我发布的代码几乎相同。我看到的唯一区别是该策略存储为私有成员变量，而不是与方法调用一起传递。与命令模式相比，我发现与 wiki 策略模式有更多相似之处。但是，我可能会误解某些东西——我绝对不是设计模式方面的专家。
标签： oop design-patterns polymorphism strategy-pattern