“开放扩展，封闭修改”的原则有意义吗？答案

【问题标题】：Does the "Open for extension, closed for modification" principle make any sense?“开放扩展，封闭修改”的原则有意义吗？
【发布时间】：2016-06-10 01:07:46
【问题描述】：

在我看来，Bob Martin 需要一些以 O 开头的东西来制作 SOLID，并在一些旧书中发现了这个（可能没用的）开放/封闭原则。

Open/Closed 如何与 Single Responsibility 共存，这表明一个类应该有一个单一的改变原因？

如果我想在一个长期存在的系统中遵循 Open/Closed，我是否应该拥有数十/数百个类的链，每个类都扩展前一个？

【问题讨论】：

这个问题的答案是“是”，这将是一个非常糟糕的答案......
这对于 SO 来说可能过于开放了——但我发现这两个帖子在考虑 SOLID 时很有用：accu.org/index.php/journals/1957 和 accu.org/index.php/journals/1957
它们相辅相成。 A) 类应该只做一件事，但是 B) 如果它们的行为可能被扩展，它们应该以这样一种方式编写，即它们可以被扩展而不会被撕开。每次扩展课程时，您都应该确保它仍然遵守 A)。如果没有，很可能是时候重构了。
还有lostechies.com/joeocampo/2008/03/21/…
Robert C. Martin 在首字母缩略词出现之前编纂了这些原则。 Michael Feathers 后来添加了这个首字母缩略词。见the tag info for solid-principles。

标签： oop design-patterns solid-principles open-closed-principle

【解决方案1】：

我也来到这里想知道整个“关闭以供修改”，但我得出的结论是，我觉得最好用一个例子来说明：

public class FixedSizeCache {
    private int maxCacheSize = 8192;
    public FixedSizeCache() {
      // ...
    }
    // ...
}

上面的例子没有违反单一责任原则，但它以一种相当明显的方式违反了开放/封闭原则：当你需要一个不同的固定大小的 FixedSizeCache 时，你需要修改类的源。

换句话说，我们应该努力编写不以明显方式违反开放/封闭原则的代码，但这并不意味着我们需要编写完全锁定永不修改的代码（因为业务需求发生变化，这应该反映在我们的代码中）。

但是，如果相同的业务需求更改了 7 次，而您需要修改代码 7 次，那么您可能违反了开放/封闭原则，需要进行重构。

【讨论】：

【解决方案2】：

设计精美的问题！

如果我想在一个长期存在的系统中遵循 Open/Closed，我是否应该拥有数十/数百个类的链，每个类都扩展前一个？

这正是我前段时间在“长寿系统”中观察到的；几十个类通过小部分扩展超类。另一方面，python 的现代构造恰恰违背了这一原则，我觉得现代 python 对 Open/Closed 的违反是许多 python 库有用和简单的根本原因。所以我检查了，发现了你的问题。配方好！

【讨论】：

【解决方案3】：

开放/封闭原则意味着您可以通过添加新代码而不是更改旧代码来创建添加新功能的系统。为了完全符合开放/封闭原则，必须具有完美的远见。因为为了创建一个对扩展完全开放、对所有修改关闭的系统，必须能够完美地预测未来。必须提前知道客户需要哪些新功能才能将扩展点添加到代码中。

话虽如此，我们可以开发出完全符合开放/封闭原则的系统。通过使用包含大量反馈和重构的迭代过程，我们可以改进系统中最常更改的部分，使它们对扩展开放，对修改关闭。

正如 Bob Martin 在他的一次演讲中所说：“我们不能完全遵循开/闭原则。这并不意味着我们应该完全放弃开/闭原则。可能很难做到整个系统都符合开闭原则，但让函数或类或更小的组件符合开闭原则并不难”

【讨论】：