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

Question

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

开放/封闭如何与单一职责共存，即一个类应该有一个改变的原因？

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

Answer 1

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

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

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

Answer 2

我也来到这里想知道整个“关闭修改”位，但我得出了一个结论，我认为最好用一个例子来证明：

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

上面的示例并没有违反单一职责原则，但它以相当明显的方式违反了开放/关闭原则：每当您需要不同固定大小的固定大小缓存时，您都需要修改类的源代码。

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

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