很多刚学面向对象编程的朋友，都会听到开闭原则这个说法，但翻了一堆资料，还是没搞懂它到底说啥，为啥大家都把它捧成设计原则里的头把交椅。

今天咱们就用大白话掰扯清楚，顺便说说为什么“对扩展开放，对修改关闭”能让代码更好维护。

先举个生活里的例子，你就懂了。比如你租了个老房子，原来的墙刷的是白色，你想换个蓝色。正常操作肯定是直接买涂料刷上去，不用把整面墙砸了重新砌，对不对？如果换个颜色就得砸墙重建，那成本也太高了，没人会这么干。

开闭原则说的其实就是这么个事儿。它的标准定义里说，软件实体比如类、模块、函数这些，应该对扩展开放，对修改关闭。

翻译成人话就是，你要给现有代码加新功能的时候，尽量去写新的代码，不要去改原来已经跑通的旧代码。

你可能会说，不改旧代码怎么加新功能？这不是矛盾吗？其实不矛盾，咱们拿实际写代码的场景来说。

比如你做一个电商网站，一开始只有满减活动，你写了一个计算价格的类，里面直接写了满减的计算逻辑，上线跑的好好的。过了俩月，老板说要加个打折活动，原来的满减还要保留。

这个时候你有两种选择。第一种，打开原来那个计算价格的类，把原来的代码改一改，加个if判断，如果是打折活动就走打折逻辑，满减就走原来的逻辑。

第二种呢，你先抽一个通用的优惠接口出来，里面定好计算价格的方法，原来的满减逻辑做成一个实现类，新的打折逻辑再做一个新的实现类，最后调用的时候只要传不同的实现类就行，原来计算价格的核心类一点不用改。

你看，第一种就是改了原来的代码，第二种就是加新代码扩展，没碰原来的。这两种做法，区别在哪？

第一种改旧代码的做法，看起来快，其实坑很多。原来的满减逻辑已经跑了很久，线上没出过问题。你这次改代码，哪怕只是加了个if，万一不小心碰了原来的逻辑，比如改了个变量名，不小心删了半行代码，那原来好好的满减功能直接就出bug了。你还要花时间重新测试原来的功能，改的越多，测试量越大，漏测的可能性越高，线上出问题的风险就越大。

而且时间长了，这个类会越来越臃肿，今天加个活动加个if，明天加个优惠券再来个else，用不了半年，这个类的代码能堆几千行，谁看谁头疼，下次再改，没人敢轻易下手，就怕改出问题。

那第二种遵循开闭原则的做法呢？加新功能只需要写新的优惠实现类，原来写好的代码，不管是核心计算类还是原来的满减类，都不用动。原来的逻辑已经验证过没问题，不需要重新测试，只要测新写的这个打折类就行，风险小很多。

哪怕再过半年要加新的拼团优惠、会员折扣，还是一样，加新的实现类就完事，代码结构一直很清晰，每个类只干自己的一件事，接手的人一眼就能看明白，维护起来成本低很多。

看到这你应该明白了，开闭原则的核心好处其实就是控制风险，降低维护成本。项目是迭代着往上做的，不可能一开始就把所有需求想全，后续加功能是必然的。如果每次加功能都要动原来的代码，时间越长，代码里藏的bug越多，整个项目会越来越僵，最后只能推倒重写。

那是不是说，任何情况下都不能改原来的代码？当然不是。如果原来的代码本身就有bug，那肯定要改啊。开闭原则说的“对修改关闭”，主要是说加新功能的时候，尽量不要去改已经稳定运行的核心代码，不是说一点都不能改。

实际开发里，我们也做得到完全一点不改，主要是提前留好扩展的空间。比如刚才说的优惠的例子，一开始你就按照接口或者抽象类的思路来设计，把变化的部分和不变的部分分开，变化的部分留出来让后续扩展，不变的核心部分稳定下来不去动它。

很多新手会觉得，遵循开闭原则要多写好多代码，一开始设计还要花更多时间，不如直接改来的快。那是因为你没做过大项目，不知道后期维护的痛苦。我见过不少项目，前期图快，每次加功能就往原来的类里塞，改来改去，最后代码变成了“面条”，谁都不敢改，改一处动全身，每天都在修之前改出来的bug，开发新功能的速度慢到离谱，最后整个项目拖垮。

你要是一开始就记住开闭原则的思路，每次加功能优先想怎么扩展，而不是直接改原来的代码，长期下来，你的代码结构会一直保持清晰，出问题的概率小很多，维护起来也省心。

说白了，开闭原则不是什么高高在上的理论，就是程序员们踩了无数坑总结出来的经验。它就是教你怎么给项目留余地，别把路走死了。今天你给扩展留够了空间，明天加新功能的时候，就能少改点旧代码，少冒点风险，少加点不必要的班。

很多人说优秀的代码是改出来的，但改也要改对地方，改新代码，别轻易碰已经稳定的旧代码，这就是开闭原则最直白的道理。

开闭原则,开闭原则定义,扩展开放修改关闭,代码可维护性,面向对象设计,软件设计原则,代码维护,代码扩展,开闭原则作用,代码设计

[Q]：什么是开闭原则？
[A]：开闭原则的核心定义是，软件实体（比如类、模块、函数）要对扩展开放，对修改关闭，也就是加新功能时尽量写新代码，不要修改已经稳定运行的原有代码。
[Q]：开闭原则里的“扩展开放、修改关闭”是什么意思？
[A]：对扩展开放指的是允许我们通过添加新代码来扩展原有功能，满足新的需求；对修改关闭指的是尽量不要修改已经测试上线、稳定运行的原有旧代码，避免引入风险。
[Q]：为什么开闭原则能提升代码可维护性？
[A]：遵循开闭原则时，新增功能只需要写新代码，不会影响原有已经验证过的功能，既能降低改旧代码引入bug的风险，也能避免原有代码变得越来越臃肿，让代码结构一直保持清晰，自然提升可维护性。
[Q]：遵循开闭原则后，任何情况都不能修改原有代码吗？
[A]：不是的，如果原有代码本身存在bug，肯定是要修改的。开闭原则的“对修改关闭”主要针对新增功能的场景，要求新增功能时尽量不动已经稳定的核心代码，不是完全禁止修改代码。
[Q]：不遵循开闭原则会有什么问题？
[A]：每次加新功能都修改原有旧代码，不仅容易不小心破坏原有稳定功能，引入线上bug，还会让原有代码越来越臃肿，后期越来越难读懂、难修改，最后整个项目维护成本会急剧升高，甚至只能推倒重写。
[Q]：实际开发中怎么应用开闭原则？
[A]：核心是把变化的部分和不变的部分拆分，提前给变化的部分预留扩展空间，比如用接口、抽象类抽离变化点，新增功能时只需要新增对应实现类，不需要修改原有核心代码。
[Q]：开闭原则只适用于面向对象编程吗？
[A]：开闭原则最开始是作为面向对象的设计原则提出的，但它的核心思路（新增功能优先扩展而非修改原有代码）在其他编程范式的开发中也同样适用，能帮我们控制代码维护风险。
[Q]：遵循开闭原则会多写代码，为什么还要用它？
[A]：前期确实会多一些设计和写代码的工作量，但它能避免项目后期代码臃肿、bug频发的问题，长期来看能大幅降低维护成本，减少不必要的线上风险和加班，整体收益远大于前期多付出的工作量。