6大原则

6大原则

Single Responsibility Principle

定义

There should never be more than one reason for a class to change.

含义

一个接口或抽象类只定义该接口或抽象类所需要形式的职责。

在领域模型中，如果这件事可以拆分为两个人做，那么这件事就不是单一职责的。

好处

类的复杂性降低，实现的职责都有清晰明确的定义。

可读性提高，复杂性降低。

可维护性提高。

变更引起的风险降低。

注意

单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计的是否优良，但是“职责”或“变化原因”都是不可量度的，因项目而异，因环境而异。

接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

Open Closed Principle

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

一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。

降低单元测试复杂性；

提高复用性；

提高可维护性；

拥抱变化。

开闭原则对扩展开放，对修改关闭，并不意味着不做任何修改，低层模块的变更，必然要有高层模块进行耦合，开闭原则是指对其他模块做尽量少的修改。

Liskov Substitution Principle

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

子类必须完全实现父类的方法。

子类可以有自己的个性。

覆盖或实现父类的方法时输入参数可以被放大。

覆写或实现父类的方法时输出结果可以被缩小。

增强程序的健壮性，版本升级时也可以保持非常好的兼容性。

在类中调用其它类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经为被了LSP原则。

如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，建议断开父子继承关系，采用依赖、聚合、组合等关系代替继承。

子类中方法的前置条件必须与超类中被覆写的方法的前置条件相同或者更宽松。

父类可以存在的地方子类一定可以存在，反之却不一定。

Law of Demeter

一个对象应该对其他对象有最少的了解。

只和朋友类交流；

朋友之间也是有距离的；

如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放在本类中。

谨慎使用Serializable

类间解耦。

出现在成员变量，方法的输入输出参数中的类成为成员朋友类，而出现在方法体内部的类不属于朋友类。

类与类之间的关系是建立在类间的，而不是方法间，因此一个方法尽量不引入一个类中不存在的对象。当然，JDK API 除外。

尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private、package-private、protected等访问权限。

Interface Segregation Principle

客户端不应该依赖它不需要的接口。

类间的依赖关系应该建立在最小的接口上。

建立单一接口，不要建立臃肿庞大的接口。（提供给几个模块就应该有几个接口）

提高系统的灵活性和可维护性。

单一职责要求的是类和接口职责单一，而接口隔离原则要求接口的方法尽量少。

不能无限地考虑未来的变更情况。

根据接口隔离原则拆分接口时，首先必须满足单一职责原则。

保证接口的纯洁性。

Dependence Inversion Principle

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

抽象不应该依赖细节；

细节应该依赖抽象。

模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。

接口或抽象类不依赖与实现类。

实现类依赖接口或抽象类。

模块间松耦合。

减少需求变化引起的工作量剧增的情况。

使用

每个类尽量有接口或抽象类，或者抽象类和接口两者都具备；

变量的表面类型尽量是接口或者是抽象类；

任何类都不应该从具体类派生；

尽量不要覆写基类的方法；

结合里氏替换原则使用。

面向接口编程

单一职责原则描述单个类或抽象应该如何定义;里氏替换原则描述父子类之间应该如何定义;依赖倒置原则描述类之间应该依赖自己的抽象;接口隔离原则描述如何定义接口;接口隔离可以看作是接口的单一职责，所以按照接口隔离原则拆分接口的时候应该首先满足单一职责原则。迪米特法则描述类与模块之间的距离;以上五大原则都是开闭原则的具体实现。所有设计原则都是为了增强系统的稳定性、健壮性、提高代码的可读性、可维护性，降低维护成本，更好的拥抱变化。