战略的替代模式
我有一段代码，我开始将策略模式放在适当的位置，如下所示：
IStrategy
StrategyA : IStrategy
StrategyB : IStrategy
StrategyC : IStrategy
该接口只有一个计算方法。实现后，结果发现所有 3 个具体类型都具有相同的计算方法代码和两个名称相同的属性，只是设置了不同的值。
因此，为了消除重复，我将接口设置为抽象类，并将方法和属性移至该抽象类，只需在具体类型的构造中设置基本属性及其各自的值即可。
现在我知道模式并不是硬性规定，而只是指导方针，但我已经偏离了指导方针，以至于我不禁认为还有另一种模式我应该考虑？
任何人都可以建议任何其他方法吗？请让我留下，这样就可以很容易地添加新的“策略”。事实可能是，我们需要改变其中一些新情况的逻辑，那么我该如何构建它，这样我就没有重复的代码，但有一个灵活的设计，让我可以改变事情呢？
谢谢。
I have a piece of code where I started to put the strategy pattern in place, say as follows:
IStrategy
StrategyA : IStrategy
StrategyB : IStrategy
StrategyC : IStrategy
The interface just has a Calculate method on it. After implementing, it turned out that all 3 concrete types had identical code for the Calculate method and two identically named Properties, just with different values set.
So to remove duplication I made the interface an abstract class and moved the method and properties down to that, just setting the base properties with their respective values from within construction of the concrete types.
Now I know patterns aren't hard and fast rules, merely guidelines, but I've warped this so far from the guidelines that I can't help but think there's another pattern I should be looking at?
Can anyone suggest any other approaches please, that leave me so it would be easy to add on new 'Strategies' down the line. It may turn out that we need to alter the logic in some of these new cases, so how could I structure that so I don't have repeating code, but have a flexible design that lets me alter things down the line?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
为什么不创建一个具有所有常见功能的抽象类 BaseStrategy 类，并在所有具体策略中扩展它呢？
Why don't you create a
abstract class BaseStrategyclass that has all the common functionality, and extend it in all concrete strategies?您可以使用的其他替代方案是 模板 模式。但它有问题：它确实允许您更改新案例的算法，但方式非常有限。
因此，如果灵活性是您的目标，那么策略仍然是最好的答案，并且您为常见情况创建抽象类是正确的。
Other alternative you can use is Template pattern. But it has problem: it does allow you to change the algorithm for the new cases but in a very limited way.
So if flexibility is your aim, Strategy is still the best answer and you are correctly right to create an abstract class for the common case.
在对业务逻辑几乎一无所知的情况下很难对模式做出假设，但我建议考虑构建器模式，它允许您将一些代码提取到抽象类，并让子类实现与访问者模式相结合的特定逻辑，以从中提取算法具体实现类。
它应该在你编码时自然而然地出现，没有任何模式会奇迹般地解决你想要实现的目标。
Its hard to make assumption on paterns with knowing almost nothing about your business logic, but I would suggest to consider Builder pattern that lets you extract some code to abstract class and have sublasses have implement particular logic combined with Visitor patern to extract your algorythm from those concrete implementations classes.
It should naturaly come as you are coding, no patern is going to miraculously solve the goal you are trying to achieve.
有一个接口IStrategy。
实现 IStrategy 的抽象类 BaseStrategy。这样你就可以根据公共代码的存在与否来扩展或实现接口，并且客户端可以引用该接口
Have an interface IStrategy.
An abstract class BaseStrategy which implements IStrategy. This way you can extend or implement the interface based on the presence or absence of the common code and the client can refer to the interface