设计模式之六大设计原则

设计模式之六大设计原则，出师于《设计模式之禅》一书

单一职责原则

Single Responsibility Principle，简称 SRP .
英文原文:There should never be more than one reason for class to change.有且仅有一个原因引起类的变更。
但是，This is sometimes hard to see. 很多情况下，类的设计很难严格遵循单一职责原则，因为对职责的划分难以限定，盲目的追崇单一原则会让类变得更多，导致过多的继承引起强耦合关系，使得程序的设计更加复杂。所以，在程序设计中，单一职责的划分是有限度的。当然对于类中的接口、方法，应当尽可能按照单一职责原则进行设计，一个接口只做一件事情，对于阅读与维护是非常大的帮助。
仁者见仁，智者见智
对于类的设计，应当尽量遵循单一职责原则，而对于类的接口方法而言，应当趋近于单一职责原则，在接口设计中，并不推荐使用多参数的函数设计，因为这些接口设计往往让人疲于理解。

里氏替换原则

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T. 如果对每一个类型为S的对象o1，都有类型为 T 的对象 o2，使得以 T 定义的所有程序 P 在所有对象 o1 被替换成 o2 时，程序的行为没有发生变化，那么类型 S 是类型 T 的子类型。
再简单点：父类所能出现的地方，子类皆能出现，而且替换为子类时，不会产生任何错误与异常。
面向对象的语言基层是一个非常优秀的机制，具有以下特点：

• 可以减少创建类的工作量，每个子类拥有父类的方法与属性。
• 提高代码重用性、可扩展性。
• 子类可以形似父类，却又异于父类，可以“青出于蓝而胜于蓝”。
• 增强了耦合性，父类若发生变化，需要考虑子类的修改，有时候这些修改是非常耗时繁杂的。

依赖倒置原则

Dependence Inversion Principle (DIP)
High level modules should not be depend upon low level modules,Both should depend upon abstraction.Abstractions should not depend upon details, Details should depend upon abstractions.
高层模块不依赖于底层模块，两者皆应依赖于其抽象。抽象不依赖于细节，但细节依赖于抽象。再进一步的说辞：模块间的依赖通过抽象产生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。接口或抽象类不依赖于实现类，但是实现类需依赖于接口或抽象类，即面向对象设计的精髓之一面向接口编程。
依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

接口隔离原则

Clients should not be forced to depend upon interfaces that they don’t use.
客户端不应该依赖它不需要的接口。
The dependency of ine class to another one should depend on the smallest possible interface.
类间的依赖关系应该建立在最小的接口上。
根据接口隔离原则拆分接口时，首先必须满足单一职责原则。接口的设计要适度，但度无可度，经验与常识或可为之。

迪米特法则

迪米特法则（Law of Demeter,LoD）亦称最少知识原则（Least Knowledge Principle,LKP）
一个对象应该对其他对象有最少的了解。用另一句话说：一个类应该对自己需要耦合或调用的类（不管该类设计的如何复杂，只管Public中的方法）知道的最少。反过来，对于被调用的类，要求 Public 属性的方法越少越好。
如果一个方法放在本类中，既不增加类间关系，也不对本类产生负面影响，那就放置在本类中。

开闭原则

Software entities like classes,modules and functions should be open for extension but closed for modifications.
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
软件实体：项目或软件产品中按照一定的逻辑规则划分的模块、抽象和类、类中的方法等皆可称之为软件实体。
开闭原则告诉我们尽量通过扩展软件实体的行为来实现变换，而不是通过修改已有的代码来完成变化，它是为软件实体的未来时间而制定的对现行开发设计进行约束的一个原则。
开闭原则可以提高代码的复用性与可维护性。