设计模式7大原则

1.设计模式常用7大原则

1）单一职责原则

降低类的复杂度，一个类只负责一项职责，提高类的可读性，可维护性，降低类变更引起的风险，通常情况下，我们应当遵守单一职责原则，只有类逻辑足够简单，可以违反单一职责原则，若类的方法数量比较少，可以在方法级别保持单一原则。

2）接口隔离原则

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

3）依赖倒转原则(Dependence Inversion Principle, DIP)

• 高层模块不应该依赖低层模块，两者都应该依赖其抽象

• 抽象不应该依赖细节

• 细节应该依赖抽象

• 每一个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块(一般是接口，抽象类)，原子逻辑的组装就是高层模块。在Java语言中，抽象就是指接口和或抽象类，两者都不能被直接实例化。细节就是实现类，实现接口或继承抽象类而产生的类就是细节，可以被直接实例化。下面是依赖倒置原则在Java语言中的表现：

  模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的 接口或抽象类不依赖于实现类 实现类依赖于接口或抽象类 更为精简的定义：面向接口编程(Object-Oriented Design, OOD)

  DIP的好处： 采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

  依赖传递：

  接口传递

  

   

   

  构造方法传递

• 

setter()传递

 

 

4）里氏替换原则

如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2 时，程序P的行为没有发生变化，那么类型 S 是类型 T 的子类型。

所有引用基类的地方必须能透明地使用其子类的对象。

第二个定义是最清晰明确的，通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会 产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。

在使用继承时，尽量不要重写父类方法。

5）开闭原则(ocp)

一个软件实体如类，模块和函数应该对扩展开放，对修改关闭。

软件实现应该对扩展开放，对修改关闭，其含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化的

6）迪米特法则

也被称为最少知识原则（Least knowledge Principle，LKP） 也可以表述为 一个对象应该对其他对象有最少的了解，即一个类应该对自己需要耦合或调用的类知道的最少

1、只和朋友交流（Only talk to your immediate friends） 在类之间，什么样的类算作朋友呢？ 出现在成员变量、方法的输入输出参数中的类称为成员朋友类。而出现在方法体内部的类不属于朋友类。 2、朋友之间也是有距离的 不能暴露太多，否则二次修改的时候，会让影响的范围增大。 这也要求类间public方法不能肆无忌惮的暴露 3、是自己的就是自己的 如果一个方法在类间关系中，放在自身类中既不增加类间关系，也对本类不产生负面影响就放置在自身类中。 4、谨慎进行序列化操作 针对RMI（Remote Method Invocation）

最佳实践： 迪米特法则的核心在于类间的解耦，只有弱耦合之后类的复用率才会提高。其要求的结果就是产生大量的中转或跳转类。

7）合成复用原则

合成/聚合复用原则是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。

简述为：要尽量使用合成/聚合，尽量不要使用继承。