在我看来,Bob Martin 需要以 O 开头的东西来制作 SOLID,并在一些旧书中找到了这个(可能没用的)开放/封闭原则。
Open/Closed 如何与 Single Responsibility 共存,这表明一个类应该有一个单一的改变理由?
如果我想在一个长寿系统中遵循 Open/Closed,我是否应该拥有数十/数百个课程链,每个课程都扩展了前一个?
在我看来,Bob Martin 需要以 O 开头的东西来制作 SOLID,并在一些旧书中找到了这个(可能没用的)开放/封闭原则。
Open/Closed 如何与 Single Responsibility 共存,这表明一个类应该有一个单一的改变理由?
如果我想在一个长寿系统中遵循 Open/Closed,我是否应该拥有数十/数百个课程链,每个课程都扩展了前一个?
开放/封闭原则意味着您可以创建通过添加新代码而不是更改旧代码来添加新功能的系统。为了完全符合开放/封闭原则,必须具有完美的远见。因为为了创建一个对扩展完全开放、对所有修改关闭的系统,必须能够完美地预测未来。必须提前知道客户需要哪些新功能才能将扩展点添加到代码中。
话虽如此,我们可以开发出完全符合开放/封闭原则的系统。通过使用具有大量反馈和重构的迭代过程,我们可以通过使它们对扩展开放而对修改关闭,从而改进系统中最常更改的部分。
正如 Bob Martin 在他的一次演讲中所说:“我们不能完全遵循开闭原则。这并不意味着我们应该完全放弃开闭原则。可能很难让整个系统符合开闭原则但不难使函数或类或更小的组件符合开闭原则"
我也来到这里想知道整个“为修改而关闭”位,但我得出的结论是,我觉得最好用一个例子来证明:
public class FixedSizeCache {
private int maxCacheSize = 8192;
public FixedSizeCache() {
// ...
}
// ...
}
上面的例子没有违反单一职责原则,但它以一种相当明显的方式违反了开放/封闭原则:当你需要一个不同的固定大小的 FixedSizeCache 时,你需要修改类的源。
换句话说,我们应该努力编写不以明显方式违反开放/封闭原则的代码,但这并不意味着我们需要编写完全固定不变的代码,永远不会被修改(因为业务需求会发生变化和这应该反映在我们的代码中)。
但是,如果相同的业务需求更改了 7 次,而您需要修改代码 7 次,那么您可能违反了开放/封闭原则,需要进行重构。
精美的问题!
如果我想在一个长寿系统中遵循 Open/Closed,我是否应该拥有数十/数百个课程链,每个课程都扩展了前一个?
这正是我前段时间在“长寿系统”上观察到的。几十个类通过小部分扩展超类。另一方面,python 的现代构造恰恰违背了这一原则,我觉得现代 python 对 Open/Closed 的违反是许多 python 库有用和简单的根本原因。所以我检查了,发现了你的问题。配方好!