概念

software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification。

对扩展开放，对修改关闭。

添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。

  1. 开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发。只要它没有破坏原有的代码的正常运行，没有破坏原有的单元测试，我们就可以说，这是一个合格的代码改动。我们要做的是尽量让修改操作更集中、更少、更上层，尽量让最核心、最复杂的那部分逻辑代码满足开闭原则。
  2. 同样的代码改动，在粗代码粒度下，可能被认定为“修改”；在细代码粒度下，可能又被认定为“扩展”。如改动过程中修改了一个类中的成员变量，从方法的角度看是扩展，从类的角度看是修改。

如何做

在写代码的时候，要事先留好扩展点。这需要对业务、对系统有足够的了解。

扩展性

扩展性是代码质量最重要的衡量标准之一。很多设计原则、设计思想、设计模式，都是以提高代码的扩展性为最终目的的。特别是 23 种经典设计模式，大部分都是为了解决代码的扩展性问题而总结出来的，都是以开闭原则为指导原则的。

在众多的设计原则、思想、模式中，最常用来提高代码扩展性的方法有：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态等）。

注意在有些情况下，扩展性会与可读性冲突，需要根据场景在二者之间权衡。