开-闭原则就是软件实体应当对扩展开放，对修改关闭。（Software entities should be open for extension,but closed for modification.）
正如牛顿三大定律在经典力学中的位置一样，开闭原则是面向对象的可复用设计（Object Oriented Design或OOD）的基石，是最基础的设计原则，其它的设计原则都是开闭原则的具体形态，也就是说其它的设计原则是指导设计的工具和方法，而开闭原则才是其精神领袖。依照编程语言的称谓，开闭原则是抽象类，而其它的原则是具体的实现类。
通俗一点说就是软件系统中包含的各种组件，例如模块（Modules）、类（Classes）以及功能（Functions）等等，应该在不修改现有代码的基础上，引入新功能。
开闭原则是面向对象设计中最基础的设计原则，它指导如何建立稳定灵活的系统。开闭原则可能是设计模式六项原则中定义最模糊的一个了，它只说对扩展开放，对修改关闭，可是到底如何才能做到对扩展开放，对修改关闭，并没有明确的说明。以前，如果有人说“你进行设计的时候一定要遵守开闭原则”，会觉的他什么都没说，但貌似又什么都说了。因为开闭原则真的太虚了。
仔细思考以及仔细阅读很多设计模式的文章后，对开闭原则有了一点认识。其实遵循其它的设计原则，以及使用23种设计模式的目的就是遵循开闭原则。也就是说，只要对其它的设计原则遵守的好了，设计出的软件自然是符合开闭原则的，这个开闭原则更像是其它的设计原则遵守程度的“平均得分”，其它的设计原则遵守的好，平均分自然就高，说明软件设计开闭原则遵守的好；如果其它的设计原则遵守的不好，则说明开闭原则遵守的不好。
开闭原则的核心是“可复用”，它具有两大特征：①对于拓展是开放的；②对于修改是关闭的。举个例子，比如说HashMap是实现了Map接口的，那么如果需要拓展功能，那么就修改HashMap而不用去修改Map接口，同时Map是禁止修改的（因为修改接口，会强制要求所有实现要做相应修改，牵一发而动全身）。那么前者就是开放的，后者就是关闭的。再延伸一点，其实抽象是非常灵活的，而具体的实现是非常丰富的，在设计的时候，尽量不去修改抽象，而是要去修改具体实现。
开闭原则无非就是想表达这样一层意思：用抽象构建框架，用实现扩展细节。因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节，用从抽象派生的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了。当然前提是抽象要合理，要对需求的变更有前瞻性和预见性才行。
其它的设计原则，恰恰是说明用抽象构建框架，用实现扩展细节的注意事项而已：单一职责原则实现类要职责单一；里氏替换原则不要破坏继承体系；依赖倒置原则要面向接口编程；接口隔离原则在设计接口的时候要精简单一；迪米特法则要降低耦合。而开闭原则是总纲，要对扩展开放，对修改关闭。
最后说明一下如何去遵守这六个原则。对这六个原则的遵守并不是是和否的问题，而是多和少的问题，也就是说，一般不会说有没有遵守，而是说遵守程度的多少。任何事都是过犹不及，设计模式的六个设计原则也是一样，制定这六个原则的目的并不是要刻板的遵守他们，而需要根据实际情况灵活运用。对他们的遵守程度只要在一个合理的范围内，就算是良好的设计。用一幅图来说明一下。
图中的每一条维度各代表一项原则，依据对这项原则的遵守程度在维度上画一个点，则如果对这项原则遵守的合理的话，这个点应该落在红色的同心圆内部；如果遵守的差，点将会在小圆内部；如果过度遵守，点将会落在大圆外部。一个良好的设计体现在图中，应该是六个顶点都在同心圆中的六边形。
在上图中，设计1、设计2属于良好的设计，他们对六项原则的遵守程度都在合理的范围内；设计3、设计4设计虽然有些不足，但也基本可以接受；设计5则严重不足，对各项原则都没有很好的遵守；而设计6则遵守过渡了，设计5和设计6都是迫切需要重构的设计。因此也不要墨守成规，设计模式六大原则，如果每一步都严格遵循会产生很多问题（比如说迪米特原则，那么它会产生很多友元类）。所以在设计过程中，如何掌握原则的度量需要对实际情况进行分析。比较两者代价与开销，选择更恰当的实现方式，不然过犹不及会让你有一种无力感。
最后分享对设计模式原则遵循程度和项目优雅性画的一张图（借鉴别人的图）：
