设计模式中的solid原则

好的代码不只为了完成现有功能，也会考虑后续扩展。

在结构设计上松耦合易读易扩展，在领域实现上高内聚不对外暴露实现细节不被外部干扰。

在众多项目的锤炼和对程序设计的不断追求，多年编程历程提炼出来的心得体会才能真正hold住设计模式。

• 在没有众多项目的情况下，我们也只能学习设计模式规则，理解其中含义。
• 在设计小型架构时，多思考可能出现的场景和需扩展的模块，选择合适的模式。
• 在编写类和方法时，符合solid原则（单一职责、开闭原则..）。
• 不追求快，设计好架构对以后模块的维护会起到事半功倍的作用

1、单一职责原则

概念：一个类或者模块只负责一个职责。

目标：①实现代码的高内聚和低耦合；②提高代码的可维护性。

注意事项：①不同的应用场景、不同阶段的需求背景下，对同一个类或模块的职责是否单一的判定，可能都是不一样的。②不要设计大而全的类或模块，避免将不相关的功能耦合在一起。

实践方式：①在现实场景中，先写一个粗粒度的类，满足业务需求。②随着业务的发展，如果粗粒度的类越来越庞大，代码越来越多，就将这个粗粒度的类，拆分成几个更细粒度的类。

2、开闭原则

概念：对扩展开放，对修改关闭：在添加新功能时，应尽量在已有代码基础上扩展代码（新增模块、类、方法），而非修改已有代码。

目标：①提升代码的可扩展性，以最小的修改代码的代价来完成新功能的开发。②在应对变化的基础上，保证已有代码的稳定性。

注意事项：①修改代码并不意味着违背开闭原则，同样一个代码改动，在粗代码粒度下，被认定为“修改”，在细代码粒度下，又可以被认定为“扩展”。②添加一个新功能时，不可能任何模块、类、方法的代码都不“修改”，要尽量让修改操作更集中、更少、更上层，尽量让最核心、最复杂的那部分逻辑代码满足开闭原则。③时刻具备扩展意识、抽象意识和封装意识。写代码时多花点时间思考未来可能出现哪些需求变更，事先留好扩展点，以便在未来以最小的代码改动来完成新功能。④在考虑扩展点时也要注意，对于一些比较确定的、短期内可能就会扩展，或者需求改动对代码结构影响比较大的情况，或者实现成本不高的扩展点，可以事先做一些扩展性设计，但是不要过度设计。

实践方式：①多态。②依赖注入。③基于抽象而非实现编程。

3、里氏替换原则

概念：子类对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变和原有程序的正确性。

目标：指导子类的设计，让子类在继承了父类设计初衷的前提下，进行扩展。

注意事项：①父类定义了函数的“约定”（协议），子类可以改变函数内部的实现逻辑，但是不能改变函数原有的“约定”，包括输入、输出、异常处理等等内容。②理解里式替换原则，最核心的就是理解“Design By Contract”，按照协议来设计。

4、接口隔离原则

概念：调用者或实现者不应该被强迫依赖其不需要的接口。

目标：①保证接口层面的访问控制。②保证接口职责的单一。③提升代码的可扩展性和可复用性。

注意事项：①接口可以理解为面向对象中的接口（协议）、一组API接口集合、单个API接口或函数。②与“单一职责”原则的侧重点不同，“接口隔离”原则更关注接口的设计，从调用者或实现者的角度来评判接口的职责是否单一。

5、依赖反转/依赖倒置

概念：①高层模块不依赖低层模块，它们共同依赖同一个抽象。②抽象不依赖具体实现细节，具体实现细节依赖抽象。

目标：①指导框架层面的设计。②提升代码的可扩展性。

控制反转：指导性的思想，用于指导如何设计出松耦合的程序，主要针对依赖对象之间的解耦。

依赖注入：具体的编程技巧，不通过 new 的方式在类内部创建依赖类的对象，而是将依赖类的对象在外部创建好之后，通过构造函数、函数参数等方式传递（注入）给当前类来使用。

6、迪米特原则

降低耦合

任何人都能写出机器能看懂的代码，但只有优秀的程序员才能写出人能看懂的代码。

有两种写程序的方式：一种是把代码写的非常复杂，以至于“看不出明显的错误”；另一种是把代码写的非常简单，以至于“明显看不出错误”。

“把正确的代码改快速”比“把快速的代码改正确”要容易很多。