Rog*_*rio 11 open-closed-principle
这个问题不是关于OCP是什么.我也不是在寻找简单的答案.
所以,这就是我问这个的原因.OCP最初是在80年代后期描述的.它反映了当时的思想和背景.令人担忧的是,在代码已经过测试并投入生产之后,更改源代码以添加或修改功能将最终变得风险太大且成本高昂.因此,我们的想法是尽可能避免更改现有的源文件,并且只以子类(扩展)的形式添加到代码库中.
我可能错了,但我的印象是基于网络的版本控制系统(VCS)当时并未广泛使用.关键是VCS对于管理源代码更改至关重要.
重构的想法是最近的.那些支持自动重构操作的复杂IDE当然不存在.即使在今天,许多开发人员也没有使用最好的重构工具.这里的要点是,这样的现代工具允许开发人员在几秒钟内安全地改变数千行代码.
最后,今天,自动化开发人员测试(单元/集成测试)的想法很普遍.有许多免费和复杂的工具支持它.但是,如果我们从不/很少更改现有代码,那么创建和维护大型自动化测试套件有什么用？正如OCP所要求的那样,新代码只需要新的测试.
那么,OCP今天真的有意义吗？我不这么认为.相反,如果新功能不需要新类,我确实更愿意在添加新功能时更改现有代码.这样做可以使代码库更简单,更小,更易于阅读和理解.破坏以前功能的风险将通过VCS,重构工具和自动化测试套件进行管理.
当您不是代码的消费者时,OCP很有意义.如果我正在写一个课程,而我或我的团队正在编写所有使用它的课程,我同意.随着事情的变化而重构并不是什么大不了的事.
另一方面,如果我正在为我的客户编写API,或者我在一个拥有不同兴趣的大型组织中有多个消费者,那么OCP是至关重要的,因为我无法轻易地重构.
此外,如果你只是为了满足每个人的需要重构你的课程,你就会得到一个臃肿的课程.如果您设计的类允许使用者扩展您的类而不是修改它,那么您就不会遇到这个问题.
我从来没有听说过 OCP 是这样的。也许你指的是别的东西，但我知道的 OCP 说“模块/类必须对扩展开放，但对修改关闭，这意味着你不应该修改模块的源代码来增强它，但是模块或对象应该易于扩展。
想想eclipse（或任何其他基于插件的软件）。您没有源代码，但任何人都可以编写插件来扩展行为或添加其他功能。您没有修改 eclipse，而是扩展了它。
所以，是的，开放/封闭原则确实非常有效并且是一个很好的主意。
更新：
我看到这里的主要冲突是仍在开发中的代码和已经被某人发布和使用的代码之间。所以我去咨询了这个原则的作者Bertrand Meyer。他说：
如果一个模块可供其他模块使用，则称该模块已关闭。这假定模块已被赋予定义明确、稳定的描述（信息隐藏意义上的接口）。在实现层面，一个模块的闭包也意味着你可以编译它，或许将它存储在一个库中，并使其可供其他人（它的客户）使用。
因此，实际上，开放/封闭原则仅指稳定的、准备好编译和使用的实体。