"Open for extension, closed for modification" 原则有意义吗？

Question

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

Open/Closed 如何与单一职责共存，表明 class 应该有单一的变更原因？

如果我想在一个长期存在的系统中跟随 Open/Closed，我是否应该有一个 dozens/hundreds class 链，每个都扩展前一个？

Answer 1

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

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

正如 Bob Martin 在他的一次演讲中所说："We cannot completely conform to the open/closed principle. It doesn't mean we should simply give up on the open/closed principle entirely. It may be difficult to make the entire systems to conform to the open/closed principle but it's not difficult to make functions or classes or smaller components to conform to the open/closed principle"

Answer 2

问题的表述很漂亮！

If I want to follow Open/Closed in a long living system, am I supposed to have a chain of dozens/hundreds classes, each extending the previous?

这正是我前段时间在 "long living system" 上观察到的；数十个类以小位扩展超级类。另一方面，python 的现代构造恰好违背了这一原则，我感觉现代 python 的 Open/Closed 的违背是许多有用和简单的根本原因python 的图书馆。所以我检查了 SO，发现了你的问题。制定得很好！

Answer 3

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

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

上面的例子没有违反单一职责原则，但它以一种相当明显的方式违反了Open/Closed原则：每当你需要一个不同固定大小的 FixedSizeCache 时，你需要修改class.

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

但是如果相同的业务需求发生了 7 次变化，您需要修改代码 7 次，那么您可能违反了 Open/Closed 原则，需要进行重构。

"Open for extension, closed for modification" 原则有意义吗？

Does the "Open for extension, closed for modification" principle make any sense?

oop

design-patterns

open-closed-principle

solid-principles