设计模式六大原则

一、单一职责原则

定义：一个类只负责一个功能领域中的相应职责。

在开发中，一个类愈是集成多的功能，凝聚多的职责，这个类的复用性，可扩展性就愈弱。因此，我们在开发某个软件的各个功能模块时，尽量使一个类就负责履行具体某一类的职责，实现其应有的功能。

单一职责原则是软件开发中高内聚，低耦合的指导方针。开发过程应紧紧围绕这一方针进行，这有利于软件的后期维护。

二、开闭原则

定义：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。

在开发中，一个模块的修改若引发另一模块代码需要被修改，甚至引发多个模块代码需要被修改，从某种程度上来说，这样的代码是很失败的。我们在开发功能模块的过程中，能够不修改代码，就尽量不修改代码。当然，扩展功能从某种程度上来说只是添加代码，为软件添加新的特性、功能，这是没问题的。符合开闭原则的代码应是这样的：扩展功能模块的同时，几乎不需要修改其他模块的源代码。

实现方式：抽象化是遵循开闭原则的关键。将公共的部分抽象（抽象类，接口），对具体的部分扩展。

三、里氏替换原则

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

狗一定是动物，动物就一定是狗吗？显然，动物 ≠ 狗。

里氏代换原则是遵循开闭原则的重要方式之一

在软件开发中，尽量使用父类（接口）声明子类对象（实现类对象）

四、依赖倒置原则

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

依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增加的新方法。

五、接口隔离法则

定义：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

假设接口中若定义了非常非常多的抽象方法，一个类若企图实现这个接口，使得编译通过，就必须实现接口中的所有方法！这是多么糟糕的事情！在使用接口隔离原则时，我们需要注意控制接口的粒度，接口不能太小，如果太小会导致系统中接口泛滥，不利于维护；接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。因此，接口应该专业化，在接口方法数量与接口数量中做一个合适的平衡，在接口方法与接口数量之间做妥协。

定义一个接口之前，要把定义接口想成最极端的事，即接口定义了后就不能再去修改（虽然的确可以修改，但建议不要去修改，遵循开闭原则）。

六、迪米特法则

定义：一个软件实体应当尽可能少地与其他实体发生相互作用。

迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系。迪米特法则还有几种定义形式，包括：不要和“陌生人”说话、只与你的直接朋友通信等，在迪米特法则中，对于一个对象，其朋友包括以下几类：

1）当前对象本身（this）；

2）以参数形式传入到当前对象方法中的对象；

3）当前对象的成员对象（成员内部类）；

4）当前对象的成员对象是一个集合；

5）当前对象所创建的对象。