开放/封闭原则是个好主意吗? [英] Is the Open/Closed Principle a good idea?

问题描述

此问题与OCP是什么无关.而且我也不是在寻找简单的答案.

This question is not about what OCP is. And I am not looking for simplistic answers, either.

所以，这就是为什么我问这个. OCP最早是在80年代后期出现的.它反映了当时的思想和背景.令人担心的是，在已经对代码进行测试并将其投入生产之后，更改源代码以添加或修改功能最终会带来太大的风险和成本.因此，我们的想法是尽可能避免更改现有的源文件，而仅以子类(扩展名)的形式添加到代码库中.

So, here is why I ask this. OCP was first described in the late 80s. It reflects the thinking and context of that time. The concern was that changing source code to add or modify functionality, after the code had already been tested and put into production, would end up being too risky and costly. So the idea was to avoid changing existing source files as much as possible, and only add to the codebase in the form of subclasses (extensions).

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

I may be wrong, but my impression is that network-based version control systems (VCS) were not widely used back then. The point is that a VCS is essential to manage source code changes.

重构的想法是最近的.那时肯定不存在支持自动重构操作的复杂IDE.即使在今天，许多开发人员仍未使用可用的最佳重构工具.这里的要点是，这样的现代工具允许开发人员在几秒钟内安全真正地更改成千上万行代码.

The idea of refactoring is much more recent. The sophisticated IDEs that enable automated refactoring operations were certainly inexistent back then. Even today, many developers don't use the best refactoring tools available. The point here is that such modern tools allow a developer to change literally thousands of lines of code, safely, in a few seconds.

最后，今天，自动化的开发人员测试(单元/集成测试)的想法非常普遍.有许多免费且完善的工具支持它.但是，如果我们从不/很少更改现有代码，那么创建和维护大型自动化测试套件有什么好处?根据OCP的要求，新代码将仅需要新测试.

Lastly, today the idea of automated developer testing (unit/integration tests) is widespread. There are many free and sophisticated tools that support it. But what good is creating and maintaining a large automated test suite if we never/rarely change existing code? New code, as the OCP requires, will only require new tests.

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

So, does the OCP really makes sense today? I don't think so. Instead, I would indeed prefer to change existing code when adding new functionality, if the new functionality does not require new classes. Doing so will keep the codebase simpler, smaller, and much easier to read and understand. The risk of breaking previous functionality will be managed through a VCS, refactoring tools, and automated test suites.

推荐答案

当您不是代码的使用者时，OCP很有意义.如果我正在编写一个类，而我或我的团队正在编写所有使用该类的类，那么我同意.随着情况的变化进行重构根本不是什么大问题.

OCP makes a lot of sense when you aren't the consumer of your code. If I'm writing a class, and I or my team am writing all of the classes which consume it, I agree. Refactoring as things change is no huge deal at all.

另一方面，如果我正在为我的客户编写API，或者我在一个利益不同的大型组织中有多个客户，则OCP至关重要，因为我无法轻松地进行重构.

If, on the other hand, I am writing an API for my customers, or I have multiple consumers in a large organization with varying interests, the OCP is critical because I can't refactor as easily.

此外，如果您只是重构班级来满足每个人的需求，结果将是class肿的班级.如果您设计类的目的是允许使用者扩展您的类而不是对其进行修改，那么您就不会遇到这个问题.

Also, if you just refactor your class to meet everyone's needs, you'll get a bloated class as a result. If you designed the class to allow consumers to extend your class rather than modify it, you wouldn't really have this problem.

这篇关于开放/封闭原则是个好主意吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！