软件设计最大的难题就是应对需求的变化，但是纷繁复杂的需求变化又是不可预料的，我们要为不可预料的变化做好准备，这本身是一件非常痛苦的事情，但好在有大师们已经给我们提出了非常好的六大设计原则和 23 种设计模式来“封装”未来的变化。
在软件设计上有一些经典的设计原则，其中包括，SOLID、KISS、YAGNI、DRY、LOD 等。这些设计原则，从字面上理解，都不难。你一看就感觉懂了，一看就感觉掌握了，但是用在项目中的时候就会发现，“看懂”和“会用”是两回事，而“用好”更是难上加难。我有时会对这些原则理解的不够透彻，导致在使用时过于教条注意，拿原则当真理，生搬硬套，适得其反。
下面我对这些原则做一些梳理和整理，确保自己理解的是正确的。
SOLID 原则并非单纯的 1 个原则，而是由 5 个设计原则组成的，它们分别是：
- 单一职责原则
- 开闭原则
- 里氏替换原则
- 接口隔离原则
- 依赖反转原则
分别对应 SOLID 的 S、O、L、I、D 这 5 个英文字母。
原则描述
开闭原则的英文全称是 Open Closed Principle，简写为 OCP。描述是：
1 |
|
个人觉得，开闭原则是 SOLID 中最难理解、最难掌握、同时也是最有用的一条原则。
之所以说这条原则难理解，那是因为：
- 怎样的代码改动才被定义为违反‘开闭原则’？
- 怎样的代码改动才被定义为”修改“？
- 怎样才算满足或违反”开闭原则“？
- 修改代码就一定意味着违反”开闭原则“吗
之所以说这条原则最重要，那是因为，扩展性是代码质量最重要的衡量标准之一。在 23 种设计模式中，大部分设计模式都是为了解决代码的扩展性问题而存在的，主要遵从的设计原则就是开闭原则。
在理解扩展和修改时，我们需要认识到，添加一个新功能，不可能任何模块、类、方法的代码都不修改，这个是做不到的。我们要做的是尽量让修改操作更集中、更少、更上层，尽量让最核心、最复杂的那部分逻辑代码满足开闭原则。
如何做到“对扩展开发、修改关闭”？
实际上，开闭原则讲的就是代码的扩展性问题，是判断一段代码是否易扩展的“金标准”。
如果某段代码在应对未来需求变化的时候，能够做到“对扩展开放、对修改关闭”，那就说明这段代码的扩展性比较好。所以，问如何才能做到“对扩展开放、对修改关闭”，也就粗略地等同于在问，如何才能写出扩展性好的代码。
我们在写代码的时候，要多花点时间往前多思考一下，这段代码未来可能有哪写需求变更、如何设计代码结构，事先留好扩展点，以便在未来需求变更的时候，不需要改动代码整体结构、做到最小代码改动的情况下，新的代码能够很灵活地插入到扩展点上，做到”对扩展开放、对修改关闭“。
还有，在识别出代码可变部分和不可变部分之后，我们要将可变部分封装起来，隔离变化，提供抽象化的不可变接口，给上层系统使用。当具体的实现发生变化的时候，我们只需要基于相同的抽象接口，扩展一个新的实现，替换掉老的实现即可，上游系统的代码几乎不需要修改。
1 | 我们要时刻具备扩展意识、抽象意识、封装意识。 |
如何在项目中灵活应用开闭原则
写出支持“对扩展开放、对修改关闭”的代码的关键是预留扩展点。那问题是如何才能识别出所有可能的扩展点呢？
这时候就要判断你目前所开发的系统是业务导向的还是一些跟业务无关的、通用的、偏底层的系统了。
如果你开发的是一个业务导向的系统，比如金融系统、电商系统、物流系统等，要想识别出尽可能多的扩展点，就要对业务有足够的了解，能够知道当下以及未来可能要支持的业务需求。
如果你开发的是跟业务无关的、通用的、偏底层的系统，比如，框架、组件、类库，你需要了解“它们会被如何使用？今后你打算添加哪些功能？使用者未来会有哪些更多的功能需求？”等问题。
即便我们对业务、对系统有足够的了解，那也不可能识别出所有的扩展点，即便你能识别出所有的扩展点，为这些地方都预留扩展点，这样做的成本也是不可接受的。我们没必要为一些遥远的、不一定发生的需求去提前买单，做过度设计。
最合理的做法是，对于一些比较确定的、短期内可能就会扩展，或者需求改动对代码结构影响比较大的情况，或者实现成本不高的扩展点，在编写代码的时候之后，我们就可以事先做些扩展性设计。但对于一些不确定未来是否要支持的需求，或者实现起来比较复杂的扩展点，我们可以等到有需求驱动的时候，再通过重构代码的方式来支持扩展的需求。