67 lines
4.5 KiB
Markdown
67 lines
4.5 KiB
Markdown
## 设计模式的六大原则
|
||
### 1、单一职责原理
|
||
不要存在多余一个类变更的原因。通俗的说，集一个类只负责一项职责。总结一句话：不能代码量少，把牛头马嘴一起往一个类塞。基本和unix的编程思想一致。
|
||
优点:
|
||
- 减低系统复杂度,结构清晰.
|
||
- 提高代码的可读性
|
||
- 提高系统的可维护性
|
||
|
||
### 2、里氏替换原则
|
||
定义：所有引用基类（父类）的地方必须能透明地使用其子类的对象。
|
||
|
||
简单来讲就是,在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使
|
||
用的是一个子类对象的话，那么它不一定能够使用基类对象。
|
||
|
||
* 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
|
||
* 子类中可以增加自己特有的方法。
|
||
* 当子类的方法重载父类方法时，方法的前置条件()即方法的行参)要比父类方法输入的参数更加宽松。
|
||
* 当子类的方法实现父类的抽象方法时，方法的后置条件()即方法的返回值)要比父类更严格。
|
||
|
||
采用里氏替换原则的目的就是增强程序的健壮性，版本升级时也可以保持非常好的兼容性。即使增加子类，原有的子类还可以继续运行。
|
||
在实际项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑，非常完美。
|
||
|
||
尽量不要重写父类已经实现了的方法，可以用接口等其他方法绕过。
|
||
|
||
### 3、依赖倒置原则
|
||
定义：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。
|
||
|
||
依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合。在项目中使
|
||
用，我们只要遵循以下几个规则就可以.
|
||
|
||
- 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备。
|
||
- 变量的表名类型尽量是接口或者抽象类。
|
||
- 任何类都不应该从具体类派生。
|
||
- 尽量不要覆写基类的方法。
|
||
- 结合里氏替换原则使用
|
||
|
||
高层模块不应该依赖底层模块，二者应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
|
||
总结：读用抽象的接口来描述相同的动作，降低实现这个动作的人和物之间的耦合度。
|
||
|
||
### 4、接口隔离原则
|
||
客户端不应该依赖他不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
|
||
根据接口隔离原则，当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即
|
||
可。每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干。
|
||
看到这里好像接口隔离原则与单一职责原则是相同的。其实接口隔离原则与单一职责原则的审视角度是不相同的，单一职责原则要
|
||
求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少。
|
||
接口隔离原则是对接口进行规范约束，其包含的以下4层含义：
|
||
|
||
- 接口要尽量少。
|
||
- 接口要高内聚。
|
||
- 定制服务。
|
||
- 接口设计师有限度的。
|
||
|
||
在使用接口隔离原则时，我们需要注意控制接口的粒度，接口不能太小，如果太小会导致系统中接口泛滥，不利于维护；接口也不
|
||
能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。一般而言，接口中仅包含为某一类用户定制的方法即
|
||
可，不应该强迫客户依赖于那些它们不用的方法。
|
||
|
||
接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽量使用原子接口或原子类来组装。但是，这个原子该怎么划分是
|
||
设计模式中的一大难题，在实践中可以根据以下几个规则来衡量.
|
||
|
||
### 5、迪米特法则
|
||
迪米特法则又叫最小知道原则。通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，
|
||
都尽量将>逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。
|
||
总结：
|
||
|
||
### 6、开闭原则
|
||
尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
|