设计模式之六大设计原则

1、单一职责原则（Single Responsibitity Principle）

​ 2、开放封闭原则（Open Close Principle）

​ 3、里氏替换原则（Liskov Substitution Principle）

​ 4、接口分离原则（Interface Segregation Principle）

​ 5、依赖倒置原则（Dependence Inversion Principle）

​ 6、迪米特法则（Law Of Demter） 根据首字母的缩写得SOLID，寓意稳定的。

在《架构整洁之道》书中说：A class or module should have a single responsibility（一个类或者模块只负责完成一个职责或者功能）。从中我们可以得知就是在类的设计过程之中不要说我要设计一个功能大而全的类，反而是要设计功能单一，粒度小的类。但是具体的设计要根据实际的业务进行划分。

代码如下（示例）：

从上面的代码例子中有学生的种种信息，但是要是只是用来做一个展示，那么这样的设计也行，但是要是专门有设计登录管理等模块就是需要将登录用户名和密码专门设计一个类。 PS：不同的应用场景，不同的需求阶段之下，对于同一个类的职责是否单一的判断是不一样的。所以我们可以在实际的开发中，先写一个粗粒度的类。随着业务的发展，如果该类的代码量越来越庞大，这是就可以把该类拆分成更加细粒度的类，这便是持续重构。

可以从以下的几个角度来进行判断 1.类中的代码行数、函数、属性是否过多 2.类所依赖的其他类是否过多 3.类的私有方法是否过多（私有方法过多,说明在类的设计上不够严谨,没有在抽象层面将每个类的职责描述清楚） 4.类中的大量方法都有集中操作类中的几个属性

规定软件中的对象、类、模块和函数对扩展应该是开放的，对于修改应该是封闭的。用抽象定义结构，用具体实现扩展细节。 ps：开闭原则是所有设计模式最核心的目标 优点： 1.新老逻辑解耦，当需求发生改变不会影响老的业务逻辑。 2.改动成本小，只需要追加新的逻辑，不需要修改老的业务逻辑。 3.提供代码的稳定性和可扩展性。 比如在Spring中，就说IOC容器实例化的过程，需要找配置、实例化Bean、初始化等工作，这个整个过程非常的复杂。Spring把整个流程进行了抽象，对如何找配置，怎样依赖注入，初始化方法等功能，通过各种处理器插件化方式进行增强，接口类型进行自动的接入，非常契合开闭原则。

含义：如果S是T的子类型，对于S类型的任意对象，如果将他们看作是T类型的对象，则对象的行为也理应与期望的行为一致。 替换的理解：替换的特性是面向对象语言所支持的多态的特性，同一个行为具有多种不同的表现形式和形态的能力。 PS：以JDK的集合框架为例，List接口的定义为有序集合，List接口有多个派生类，比如大家耳熟能详的ArrayList, LinkedList。那当某个方法参数或变量是List接口类型时，既可以是ArrayList的实现, 也可以是LinkedList的实现，这就是替换。 与期望行为一致的替换 应用场景：使用里氏替换要求我们在编码时，使用基类或者接口去定义对象变量。可以使用具体对象进行赋值，实现代码的多样性，实现代码对修改的封闭，扩展的开放。 里氏代换原则与多态的区别 ? 多态是面向对象变成的一大特性，是面向对象编程语言的一种语法，他是一种代码的实现思路。 里氏替换则是一种设计原则，用来指导继承关系中子类如何设计，子类在设计的时候，要保证原有的在替换父类的时候，不改变原有的逻辑和不破坏原有程序的正确性。

作者罗伯特 C·马丁 为 “接口隔离原则” 的定义是：客户端不应该被迫依赖于它不使用的方法（Clients should not be forced to depend on methods they do not use） 换言之就是一个类对另一个类的依赖应该建立在最小的接口之上。 PS：接口隔离原则与接口原则都体现了封装的思想。提高了类的内聚性，降低了耦合度。 但是单一职责原则注重的是职责，接口隔离原则注重的是对接口依赖的隔离。 将某些方法单独隔离出来，进行单独封装接口处理，实现隔离

设计代码架构，高层模块不应该依赖于底层模块，二者都应该依赖于抽象（接口或者抽象类等）。抽象不应该依赖于细节，细节应该依赖于抽象。 依赖倒置原则的好处:

PS：依赖倒置、依赖注入、控制反转三者的异同 依赖倒置原则作为一种软件设计原则，指导框架层面的设计（高层不依赖于底层，抽象不依赖于实现细节，都依赖于抽象） 依赖注入是实现控制反转的一个手段，作为一种编码技巧 控制反转也是一种框架设计的常用模式，但并不是一种具体方法。

迪米特法则又叫最少知识原则，是指一个类/模块对其他的类/模块有越少的了解越好，只跟你最亲密的朋友交谈，不跟陌生人说话。 不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。