设计模式六大原则（总结）

2020-06-26 本文已影响0人沉江小鱼

此篇只是对六大原则做了下总结，具体可看👇链接：
1. 设计模式之单一职责原则
 2. 设计模式之里式替换原则
 3. 设计模式之依赖倒置原则
 4. 设计模式之接口隔离原则
 5. 设计模式之迪米特法则
 6. 设计模式之开闭原则

一个类只负责一项职责，不要存在 1 个以上导致类发生变更的原因。

优点：
a. 降低类的复杂度，一个类只负责一项职责，逻辑简单清晰；
b. 类的可读性，系统的可维护性更高；
c. 因需求变更引起的风险更低，降低对其它功能的影响。
总结：
只有逻辑足够简单，才可以在代码级别上违反单一职责原则；
只有类中方法数量足够少，才可以在方法级别上违反单一职责原则；
模块化的程序设计以及在员工工作安排上面，都适用单一职责原则。

子类可以扩展父类的功能，不能改变父类原有的功能，子类可以替换父类，方法或者行为也没有改变

注意：
a. 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法；
b. 子类中可以增加自己特有的方法；
c. 当子类的方法重载父类的方法时，方法的前置条件（形参）要比父类方法更宽松；
d. 当子类的方法实现父类的抽象方法时，方法的后置条件（返回值）要比父类更严格。

高层模块不应该依赖低层模块，二者都应该依赖其抽象
抽象不应该依赖细节，细节应该依赖抽象

理解：
a. 相对于细节的多变性，抽象的东西要稳定的多，以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。这里，抽象指的是接口或者抽象类，细节就是具体的实现类，使用抽象类或者接口的目的是，制定好规范和契约，不去涉及任何具体的操作，把展现细节的任务交给实现类来完成；

b. 依赖倒置原则的核心思想是面向接口编程，达到解耦的过程。
注意：
a. 底层模块尽量都要有抽象类或者接口；
b. 变量的声明类型尽量是抽象类或接口；
c. 使用继承时遵循里式替换原则。

客户端不应该依赖它不需要的接口
一个类对另一个类的依赖应该建立在最小的接口上面

理解：
a. 建立单一接口，尽量细化接口，接口中的方法尽量少；
b. 为单个类建立专用的接口，不要包含太多；
c. 依赖几个专用的接口要比依赖一个综合的接口更灵活，提高系统的灵活性和可维护性。
注意：
a. 接口尽量小，但是要有限度，过小则导致接口数量过多，设计复杂化；
b. 为依赖接口的类定制服务，只暴露给调用类需要的方法，建立最小的依赖关系；
c. 提高内聚，减少对外交互，用最少的方法去完成最多的事情。
和单一职责原则的对比：
a. 单一职责原则注重的是职责，而接口隔离原则注重对接口依赖的隔离；
b. 单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口，针对抽象和程序整体框架的构建。

迪米特法则在于降低类之间的耦合，每个类尽量减少对其他类的依赖，尽量减少对外暴露的方法，使得功能模块独立，低耦合

软件中的对象（类、模块、函数等）应该对于扩展是开放的，对于修改是封闭的

理解：
a. 当需求发生变化时，尽量扩展实体的行为来变化，而不是通过修改已有的代码来实现变化；
b. 低层模块的变化，必然有高层模块进行耦合，它并不意味着不做任何修改；
c. 这个原则比较虚，可以通过具体的设计模式的设计思维去加深理解。