我有一段代码，我开始制定策略模式，如下所示：
IStrategy
StrategyA : IStrategy
StrategyB : IStrategy
StrategyC : IStrategy
界面上只有一个Calculate方法。实现之后，事实证明，所有3种具体类型都有相同的Calculate方法代码和两个同名的Properties，只是设置了不同的值。
因此，为了删除重复，我将接口设置为抽象类，并将方法和属性向下移动到那里，只需在具体类型的构造中设置基本属性及其各自的值。
现在我知道模式并不是硬性规定，而是指导方针，但是我已经对指南进行了歪曲，我不禁会想到我应该看到另一种模式吗？
任何人都可以建议任何其他方法，这样我就可以轻松添加新的“策略”了。可能会发现我们需要改变其中一些新案例中的逻辑，所以我怎么能构造它以便我没有重复的代码，但是有一个灵活的设计让我可以改变一些事情呢？
感谢。
答案 0 :(得分：5)
为什么不创建一个具有所有常用功能的abstract class BaseStrategy类，并在所有具体策略中扩展它？
答案 1 :(得分：0)
很难对paterns做出假设，对你的业务逻辑几乎一无所知，但我建议考虑使用Builder模式，让你提取一些代码来抽象类，并让子类实现特定的逻辑结合Visitor patern来提取你的来自那些具体实现类的algorythm。
当你编码时，它应该是自然而然的，没有任何人会奇迹般地解决你想要实现的目标。
答案 2 :(得分：0)
您可以使用的其他替代方法是Template模式。但它存在问题：它确实允许您以非常有限的方式更改新案例的算法。
因此，如果灵活性是您的目标，那么策略仍然是最佳答案，您正确地为常见案例创建抽象类是正确的。
答案 3 :(得分：0)
有一个界面IStrategy。 实现IStrategy的抽象类BaseStrategy。这样您就可以根据公共代码的存在与否来扩展或实现接口，客户端可以参考接口