design-patterns - 策略的替代模式

Question

我有一段代码开始实施策略模式，如下所示：

IStrategy
StrategyA : IStrategy
StrategyB : IStrategy
StrategyC : IStrategy

该接口上只有一个 Calculate 方法。实施后，结果证明所有 3 个具体类型的 Calculate 方法代码和两个名称相同的 Properties 都具有相同的代码，只是设置了不同的值。

因此，为了消除重复，我将接口设置为抽象类，并将方法和属性向下移动，只需在具体类型的构造中使用它们各自的值设置基本属性。

现在我知道模式不是硬性规定，只是指导方针，但我已经把它从指导方针中扭曲了，我不禁认为还有另一种模式我应该看看？

任何人都可以建议任何其他方法，让我离开，这样就可以很容易地添加新的“策略”。事实证明，我们需要在其中一些新案例中改变逻辑，那么我该如何构建它，这样我就没有重复的代码，但有一个灵活的设计让我可以改变事情呢？

谢谢。

score 5 · Accepted Answer

为什么不创建一个abstract class BaseStrategy具有所有通用功能的类，并在所有具体策略中扩展它？

score 0 · Accepted Answer

很难对几乎不了解您的业务逻辑的模式做出假设，但我建议考虑构建器模式，该模式可让您将一些代码提取到抽象类并让子类实现特定逻辑与访问者模式相结合，以从中提取您的算法具体实现类。

它应该在您编码时自然而然地出现，没有任何模式可以奇迹般地解决您试图实现的目标。

score 0 · Accepted Answer

您可以使用的其他替代方法是模板模式。但它有一个问题：它确实允许您更改新案例的算法，但方式非常有限。

因此，如果您的目标是灵活性，那么 Strategy 仍然是最好的答案，并且您为常见情况创建一个抽象类是正确的。

score 0 · Accepted Answer

有一个接口 IStrategy。实现 IStrategy 的抽象类 BaseStrategy。这样就可以根据有无通用代码来扩展或实现接口，客户端可以参考接口

4 回答 4