战略模式与开放-封闭原则冲突

Question

我在阅读战略模式，并试图实施它，但我一直坚持决定战略的实施，我觉得这违反了开放-封闭原则。

在策略模式中，我们编码为接口，基于客户端交互，我们将在战略实施中传递。

现在，如果我们有很多策略，那么我们需要决定使用什么样的策略，客户端选择这样的策略

IStrategy str;
    if(stragety1) {
     str = new Strategy1()
    } else if (stragety2) {
     str = new Strategy2()
    } and so on..
str.run()

现在，按照开放-封闭原则，上述对扩展开放，但不对修改关闭。

如果我将来需要添加另一个策略(扩展)，我确实需要修改这段代码。

有什么办法可以避免这种情况，还是我们需要如何实施战略模式？

Answer 1

这确实不是封闭的修改，但这是由于您初始化的方式。您正在使用一个值(enum?)以确定应使用哪个策略子类。正如@bpjoshi指出他们的评论一样，这更像是一个工厂模式。

维基百科讨论了一个策略模式如何能够支持开放/封闭原则，而不是阻碍它。

在该示例中，它们使用带有Car策略的Brake类。有些汽车使用防抱死制动，有些则没有。不同的Car子类和实例可以给出不同的制动策略。

要使代码关闭以进行修改，您需要以不同的方式选择策略。您希望在定义新行为或子类的位置选择策略。您必须重构代码，以便在扩展代码的地方应用特定的策略子类。

Answer 2

1)必须将选择/创建具体策略与其使用分开。即使用函数selectStrategy，将其作为(构造函数)参数传递，等等。

2)没有办法完全避免条件创建，但您可以隐藏它(例如，使用一些字典来映射state=>strategy)和/或将其转换到应用程序的另一个级别。最后一种方法非常强大和灵活，但取决于任务。在某些情况下，您可能会将选择/创建放在与使用它相同的级别上。在其他情况下，您甚至可能会选择/创建到最高/最低级别的委托。

2.1)您可以使用Registry模式，并在添加新策略时避免修改“核心”对象。

Answer 3

我认为，人们对封闭以供修改存在误解。

1988年，梅耶尔说：

当您的应用程序以新功能扩展时，当可能的不被更改时，工作软件就应该工作。

罗伯·C·马特林说：

这一定义显然是过时的。仔细考虑一下。如果可以扩展系统中所有模块的行为，而不需要修改它们，那么您可以在不修改任何旧代码的情况下向系统添加新特性。这些特性将仅通过编写新代码来添加。https://8thlight.com/blog/uncle-bob/2014/05/12/TheOpenClosedPrinciple.html

在不修改旧码的情况下增加一些新码不与开闭原理相冲突.