design-patterns - 如果我们有良好的测试覆盖率，是否需要遵守开放封闭原则？

Question

为什么 Open-Closed Principle有这么大的事吗？如果您有测试，为什么还要担心代码修改？

Answer 1

If you have tests why you should worry about code modifications?

在单元测试的上下文中，开闭 原则是一种设计原则，它允许您添加新代码，同时对之前编写的代码的影响最小。已经测试的内容不会因为新的需求而改变，因此减少了程序员可以在稳定的代码库上创建的损坏区域。考虑以下不遵循开闭原则的伪面向对象代码示例:

class NumberOperations {
   public void add(Number a,Number b) {
      Number result = null;
      if(a instanceof Integer && b instanceof Integer) {
         Integer aInt = (Integer)a;
         Integer bInt = (Integer)a;
         result = aInt + bInt;
      } else {
          //failure/error : only integer operations supported.
      }
      return result;
   }
}

您测试上面的代码，一切都按预期工作。您现在决定也支持小数运算，因此您修改 add 函数如下:

public void add(Number a,Number b) {
    Number result = null;
    if(a instanceof Integer && b instanceof Integer) {
        Integer aInt = (Integer)a;
        Integer bInt = (Integer)a;
        result = aInt + bInt;
    } else if(a instanceof Double && b instanceof Double) {
        Double aDecimal = (Double)a;
        Double bDecimal = (Double)b;
        result = aDecimal + bDecimal ;
    } else {
      //failure/error : only integer and double operations supported.
    }
    return result;
}

只需要一个支持小数加法的新简单需求，你就增加了4行新代码，重新排列了一行代码，你的伤害面积增加了一倍。对于这样一个简单的例子，这可能看起来微不足道，但现实世界的代码很少有这么基本的。您可能会在现有代码中引入任何测试用例都无法理解的副作用。

如果您遵守开闭原则，您可以从 NumberOperations 扩展名为 IntegerOperations 和 DoubleOperations 的子类code>(现在可以是抽象的)实现 add 方法。上面显示的 add 方法中的第一个 if 中的代码可以移动到 IntegerOperations 类中的 add 方法中else-if 中的代码可以移至 DoubleOperations 类中的 add 方法。如果您的语言支持泛型，您甚至可以去掉上面示例中显示的类型检查。

然后您分别测试这两个新类。当您收到添加两个 String 的要求时，您可以创建一个名为 StringOperations 的新类。您不必担心对 IntegerOperations 或 DoubleOperations 进行任何不需要的更改，因此不必再次测试它们。您只需要测试 StringOperations 类。

总结:OCP 不仅减少了您可能会暴露您的代码库的损坏区域，而且还允许您的 API 用户添加新功能(例如通过子类化)，而无需依赖对你做出这些改变。您也许能够确保所有关键代码路径都在没有 OCP 的情况下进行测试。您无法保护您的代码库免受其他人破坏已经过测试的代码的风险，这会引入您甚至没有在测试中考虑的错误。