设计原则 — O 开放封闭原则

含义

简单描述是对扩展开放，对修改关闭。

具体指当添加新功能时，应在已有基础上扩展代码，而不是在已有基础上修改代码。对的对象是已有基础的代码。

那什么是扩展呢？新功能以添加新代码的方式来实现，比如新增模块、类、方法等。

什么是修改呢？新功能以改变原有类、方法的方式来实现，比如原方法中间插入代码、方法变更参数等。

简单来说：上述的扩展推荐，修改不推荐。

优点

对应标准提高的是可维护性、可扩展性。

可能有人会和我一样有个困惑，标准里的可扩展性和当前原则里的扩展，词是一样的，可它怎么一会是个标准，一会又是个原则？

其实就是同一个词表达了存在关联的两种含义而已，在原则里是个动词，有具体的动作；在标准里是个形容词，可以作为衡量的性质。即扩展原则可帮助实现高扩展性，在不同场景联系到具体的含义来理解，词只是更精简的描述而已。所以也不必太纠结于这点。

回到原话题提到的所提高的标准：可维护性、可扩展性。

可维护性指的是新增或者修改代码简单；那都不让改了，原代码都不变化了，又怎么会影响原有的功能呢？自然也就稳定了，自然可保证已有代码的稳定。对于新功能的实现者只需要扩展就能实现新功能，压力也小了，也体现了增强可维护性。

可扩展性指的是应对需求变化的能力强；要求新增类、方法等来实现新功能了，自然是能方便的应对需求变化了。

总结来说：对扩展开放可应对需求变化，对修改关闭可保证已有代码的稳定性。

如何做

到实践时，我们会发现原则提到的都是理想情况，不可能做到绝对的修改关闭。只能说尽可能做到。

那在无法做到的情况下，最重要考虑的是不破坏原有代码的运行。

大概原则说的严苛一些也是为了便于记忆，就像新闻的噱头容易让人记住吧。

那如何尽可能做到呢？

需要我们在面对需求时，多思考一下，找出可变部分和不可变部分，将变化(可变部分)作为扩展点，预留好这些扩展点。

针对变化，考虑是否可应用设计模式来实现，毕竟大部分设计模式也是为解决代码的扩展性而提出的。

这也取决于我们有无这样的认知——把变化识别出来。

我目前对这个原则的理解也并不深刻，留待后续多写点代码看能否有更深刻的体会。

《设计模式之美》—— 王争(极客时间)