designPattern/principle

设计模式的六大原则

1、单一职责原理

不要存在多余一个类变更的原因。通俗的说，集一个类只负责一项职责。总结一句话：不能代码量少，把牛头马嘴一起往一个类塞。基本和unix的编程思想一致。 优点:

• 减低系统复杂度,结构清晰.
• 提高代码的可读性
• 提高系统的可维护性

2、里氏替换原则

定义：所有引用基类（父类）的地方必须能透明地使用其子类的对象。

简单来讲就是,在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使 用的是一个子类对象的话，那么它不一定能够使用基类对象。

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
• 子类中可以增加自己特有的方法。
• 当子类的方法重载父类方法时，方法的前置条件()即方法的行参)要比父类方法输入的参数更加宽松。
• 当子类的方法实现父类的抽象方法时，方法的后置条件()即方法的返回值)要比父类更严格。

采用里氏替换原则的目的就是增强程序的健壮性，版本升级时也可以保持非常好的兼容性。即使增加子类，原有的子类还可以继续运行。 在实际项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑，非常完美。

尽量不要重写父类已经实现了的方法，可以用接口等其他方法绕过。

3、依赖倒置原则

定义：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。

依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合。在项目中使 用，我们只要遵循以下几个规则就可以.

• 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备。
• 变量的表名类型尽量是接口或者抽象类。
• 任何类都不应该从具体类派生。
• 尽量不要覆写基类的方法。
• 结合里氏替换原则使用

高层模块不应该依赖底层模块，二者应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。 总结：读用抽象的接口来描述相同的动作，降低实现这个动作的人和物之间的耦合度。

4、接口隔离原则

客户端不应该依赖他不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。 根据接口隔离原则，当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即 可。每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干。 看到这里好像接口隔离原则与单一职责原则是相同的。其实接口隔离原则与单一职责原则的审视角度是不相同的，单一职责原则要 求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少。 接口隔离原则是对接口进行规范约束，其包含的以下4层含义：

• 接口要尽量少。
• 接口要高内聚。
• 定制服务。
• 接口设计师有限度的。

在使用接口隔离原则时，我们需要注意控制接口的粒度，接口不能太小，如果太小会导致系统中接口泛滥，不利于维护；接口也不 能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。一般而言，接口中仅包含为某一类用户定制的方法即 可，不应该强迫客户依赖于那些它们不用的方法。

接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽量使用原子接口或原子类来组装。但是，这个原子该怎么划分是 设计模式中的一大难题，在实践中可以根据以下几个规则来衡量.

5、迪米特法则

迪米特法则又叫最小知道原则。通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂， 都尽量将>逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。 总结：

6、开闭原则

尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。