为什么许多软件开发人员违反开放/封闭原则？

#1 楼

IMHO JacquesB的回答虽然包含很多事实，但显示出对OCP的根本误解。公平地说，您的问题也已经表达了这种误解-重命名功能破坏了向后兼容性，但没有破坏OCP。如果似乎需要打破兼容性（或维护同一组件的两个版本以不破坏兼容性），那么OCP之前就已经被破坏了！ “您不能修改组件的行为”-它说，应该尝试以一种开放的方式设计组件，以便以多种方式重复使用（或扩展）蜜蜂，而无需进行修改。这可以通过提供正确的“扩展点”来完成，或者如@AntP所述，“通过将类/函数结构分解为默认情况下每个自然扩展点都存在的点”来完成。遵循OCP的恕我直言与“保持旧版本保持不变以向后兼容”没有任何共同点！或者，在下面引用@DerekElkin的评论：OCP是有关如何编写模块的建议，而不是有关实现永远不允许模块进行更改的更改管理过程的建议。


优秀的程序员利用他们的经验设计具有“正确”扩展点的组件（或者-甚至更好-不需要人工扩展点）。但是，要正确执行此操作且没有不必要的过度设计，您需要事先了解组件的未来用例会是什么样子。即使是经验丰富的程序员也无法展望未来，也无法事先了解所有即将出现的需求。这就是为什么有时需要向后兼容的原因-无论您的组件具有多少个扩展点，或者在某些类型的要求上遵循OCP的程度如何，总会有一个要求，如果不进行修改就无法轻松实现。组件。

#2 楼

开放/封闭原则有好处，但也有一些严重的缺点。如果一个类有一些新要求，则您永远不要修改该类本身的源代码，而是创建一个子类，该子类仅覆盖更改行为所需的适当成员。因此，针对该类原始版本编写的所有代码均不受影响，因此您可以确信所做的更改不会破坏现有代码。
实际上，您很容易陷入代码膨胀和混乱的过时类混乱之中。如果无法通过扩展修改组件的某些行为，则必须提供具有所需行为的组件的新变体，并保持旧版本不变以实现向后兼容性。
如果发现一个基本类的基本设计缺陷，许多类都可以从中继承。说该错误是由于私有字段的类型错误引起的。您无法通过覆盖成员来解决此问题。基本上，您必须重写整个类，这意味着您最终需要扩展Object以提供替代的基类-现在您还必须提供所有子类的替代方法，从而最终导致重复的对象层次结构，一个层次结构存在缺陷，一个层次结构改善。但是您不能删除有缺陷的层次结构（因为修改代码是修改代码），所有未来的客户端都将同时处于这两个层次结构中。如果代码被完美地分解，没有任何缺陷或错误，并且设计有为将来所有可能的需求变更准备的扩展点，那么您可以避免混乱。但是实际上每个人都会犯错，没有人能完美预测未来。
像.NET框架这样的东西-它仍然包含了集合类的集合，这些集合类是在十多年前引入泛型之前设计的。这无疑是向后兼容性的福音（您可以升级框架而无需重写任何内容），但是它也使框架膨胀，并为开发人员提供了很多选择，而其中许多选择已经过时了。觉得严格遵循开放/封闭原则并不值得付出复杂性和繁琐的代码。
开放/封闭的实用替代方法是控制弃用。不会在单个发行版本中破坏向后兼容性，而是将旧组件保留一个发行周期，但是会通过编译器警告通知客户端，该旧方法将在以后的发行版中删除。这使客户有时间修改代码。在这种情况下，这似乎是React的方法。
（我对原理的解释是基于Robert C. Martin的“开放-闭合原理”）

#3 楼

我将开放/封闭原则称为理想。像所有理想一样，它几乎没有考虑软件开发的现实。同样，与所有理想一样，在实践中也无法真正实现它-一个人只是努力地尽力实现这一理想。

故事的另一面被称为“金手铐”。当您过多地拥护开放/封闭原则时，您会得到金手铐。当您的产品永远不会向后兼容时，因为过去的错误太多而无法增长时，就会出现金手铐。

Windows 95内存管理器中就是一个著名的例子。作为Windows 95营销的一部分，据说所有Windows 3.1应用程序都可以在Windows 95中运行。微软实际上获得了数千个程序的许可以在Windows 95中对其进行测试。问题之一就是Sim City。 Sim City实际上有一个错误，导致该错误写入未分配的内存。在Windows 3.1中，没有``适当的''内存管理器，这只是次要的假装。但是，在Windows 95中，内存管理器将捕获此错误并导致分段错误。解决方案？在Windows 95中，如果您的应用程序名称为simcity.exe，则操作系统实际上将放宽内存管理器的约束以防止分段错误！

这个理想背后的真正问题是产品和服务的精简概念。没有人真正做过一个。一切都排列在两者之间的灰色区域中的某个位置。如果您从面向产品的角度考虑，打开/关闭听起来很理想。您的产品是可靠的。但是，涉及服务时，故事会发生变化。很容易证明，采用开放/封闭原则，您的团队必须支持的功能量必须渐近地趋近于无穷大，因为您永远无法清理旧的功能。这意味着您的开发团队每年必须支持越来越多的代码。最终您会达到一个突破点。

当今，大多数软件（尤其是开源软件）遵循开放/封闭原则的通用宽松版本。在次要版本中看到开/关紧随其后是很普遍的，而在主要版本中却被放弃。例如，Python 2.7包含了来自Python 2.0和2.1天的许多“错误选择”，但是Python 3.0席卷了所有这些。 （此外，当他们发布Windows 2000时，从Windows 95代码库向Windows NT代码库的转变打破了所有事情，但这确实意味着我们永远不需要处理内存管理器来检查应用程序名称来决定行为！） />

#4 楼

布朗博士的答案最接近准确，其他答案则说明了开放封闭原则的误解。

为了明确表达这种误解，似乎有人认为OCP意味着您不应该使向后不兼容更改（或什至是任何更改或类似的更改。）OCP是关于设计组件的，因此您无需对它们进行更改即可扩展其功能，无论这些更改是否向后兼容。除了添加功能外，还有许多其他原因，您可以对组件进行更改，无论它们是向后兼容（例如，重构或优化）还是向后不兼容（例如，过时和删除功能）。您可能进行这些更改并不意味着您的组件违反了OCP（并且绝对不意味着您违反了OCP）。

真的，这根本与源代码无关。 OCP的一个更抽象和相关的陈述是：“组件应允许扩展而无需违反其抽象边界”。我会进一步讲，更现代的再现是：“组件应强制其抽象边界，但允许扩展”。甚至在鲍勃·马丁（Bob Martin）在OCP上发表的文章中，“将”接近修改“描述为”源代码被侵犯“时，他后来也开始谈论封装，它与修改源代码无关，而与抽象有关边界。

因此，该问题的错误前提是，OCP（旨在作为）有关代码库演变的指南。 OCP通常被口号为“一个组件应该对扩展开放，而对消费者不应该进行修改”。基本上，如果某个组件的使用者希望向该组件添加功能，则他们应该能够将旧组件扩展为具有附加功能的新组件，但他们应该不能更改旧组件。

OCP对于更改或删除功能的组件的创建者一无所知。 OCP并不主张永远保持错误兼容性。作为创建者，您不会通过更改甚至删除组件来违反OCP。如果消费者可以向组件添加功能的唯一方法是对其进行突变，例如，您或您编写的组件违反了OCP。通过猴子补丁或访问源代码并重新编译。在许多情况下，这些都不是使用者的选择，这意味着如果您的组件没有“开放供扩展”，那么它们就倒霉了。他们根本无法使用您的组件来满足他们的需求。 OCP争辩说，至少在某些可识别的“扩展名”方面，不要让您的图书馆的用户处于这种位置。即使可以对源代码甚至源代码的主副本进行修改，也最好“假装”您不能对其进行修改，因为这样做有很多潜在的负面影响。

因此，请回答您的问题：不，这些都不违反OCP。作者所做的任何更改都不能违反OCP，因为OCP并非更改的一部分。但是，所做的更改可能会违反OCP，并且它们可能是由先前版本的代码库中的OCP失败引起的。 OCP是特定代码段的属性，而不是代码库的演进历史。

相比之下，向后兼容是代码更改的属性。说某些代码向后兼容或不向后兼容是没有道理的。谈论某些代码相对于某些较旧代码的向后兼容性才有意义。因此，谈论某些代码是否具有向后兼容性是没有道理的。代码的第一部分可以满足或不满足OCP，通常，我们可以在不参考任何历史版本的情况下确定某些代码是否满足OCP。对于StackExchange来说，它基本上是基于观点的，因此通常可以说是离题的，但是对于技术（尤其是JavaScript）来说，它的短处是受欢迎的，在过去的几年中，您描述的现象被称为JavaScript疲劳。 （可以随时从Google查找各种其他文章，有些是讽刺性的，从多个角度讨论这个问题。）