open-closed-principle - 开放/封闭原则是个好主意吗？

Question

很难说出这里问的是什么。这个问题模棱两可、含糊不清、不完整、过于宽泛或言辞激烈，无法以目前的形式合理回答。如需帮助澄清此问题以便可以重新打开，visit the help center .




12 年前关闭。




这个问题不是关于 OCP 是什么。我也不是在寻找简单的答案。

所以，这就是我问这个的原因。 OCP 在 80 年代后期首次被描述。它反射(reflect)了那个时代的思想和语境。令人担忧的是，在代码已经过测试并投入生产之后，更改源代码以添加或修改功能最终会带来太大的风险和成本。所以这个想法是尽可能避免改变现有的源文件，只以子类(扩展)的形式添加到代码库中。

我可能错了，但我的印象是基于网络的版本控制系统 (VCS) 在当时并未得到广泛使用。关键是 VCS 对于管理源代码更改至关重要。

重构的想法是最近出现的。支持自动重构操作的复杂 IDE 在当时肯定是不存在的。即使在今天，许多开发人员也不使用可用的最佳重构工具。这里的重点是，这种现代工具允许开发人员更改数千行代码，安全 ，在几秒钟内。

最后，今天自动化开发人员测试(单元/集成测试)的想法很普遍。有许多免费和复杂的工具支持它。但是，如果我们从不/很少更改现有代码，那么创建和维护大型自动化测试套件有什么好处呢？新代码，正如 OCP 所要求的，只需要新的测试。

那么，OCP 在今天真的有意义吗？我不这么认为。相反，如果新功能不需要新类，我确实更愿意在添加新功能时更改现有代码。这样做将使代码库更简单、更小、更易于阅读和理解。破坏先前功能的风险将通过 VCS、重构工具和自动化测试套件进行管理。

Answer 1

当您不是代码的使用者时，OCP 很有意义。如果我正在编写一个类，并且我或我的团队正在编写使用它的所有类，我同意。随着事情的变化而重构根本没有什么大不了的。

另一方面，如果我正在为我的客户编写 API，或者我在一个大型组织中有多个具有不同兴趣的消费者，则 OCP 至关重要，因为我不能那么容易地重构。

此外，如果你只是重构你的类来满足每个人的需求，结果你会得到一个臃肿的类。如果您将类设计为允许消费者扩展您的类而不是修改它，那么您就不会真正遇到这个问题。