1 开闭原则(Open Close Principle)
1.1 定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。
1.2 当软件需要变化时,尽量通过扩展软件实体的行为来实现变化, 而不是通过修改已有的代码来实现变化。
1.3 开闭原则是总纲,他告诉我们要对扩展开放,对修改关闭。
2 迪米特法则(Law Of Demeter)
2.1 迪米特法则又叫最少知道原则
2.2 定义:一个对象应该对其他对象保持最少的了解
2.3 软件编程的总的原则:低耦合,高内聚
2.4 迪米特法则还有一个更简单的定义:只与直接的朋友通信。
2.5 我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友
3 接口隔离原则(Interface Segregation Principle)
3.1 定义:客户端不应该依赖它不需要的接口; 一个类对另一个类的依赖应该建立在最小的接口上。
3.2 接口是设计时对外部设定的“契约”,通过分散定义多个接口, 可以预防外来变更的扩散,提高系统的灵活性和可维护性。
4 依赖倒置原则(Dependence Inversion Principle)
4.1 定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象; 抽象不应该依赖细节;细节应该依赖抽象。
4.2 依赖倒置原则基于这样一个事实:相对于细节的多变性,抽象的东西要稳定的多。 以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。
4.3 依赖倒置原则的中心思想是面向接口编程
5 里氏替换原则(Liskov Substitution Principle)
5.1 定义2:所有引用基类的地方必须能透明地使用其子类的对象
5.2 里氏替换原则通俗的来讲就是:子类可以扩展父类的功能,但不能改变父类原有的功能。
5.3 子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法。
5.4 子类中可以增加自己特有的方法。
5.5 当子类的方法重载父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。
5.6 当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。
6 单一职责原则(Single Responsibility Principle)
6.1 定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。
6.2 职责扩散
6.2.1 所谓职责扩散,就是因为某种原因,职责P被分化为粒度更细的职责P1和P2。
6.2.2 原则是:只有逻辑足够简单,才可以在代码级别上违反单一职责原则; 只有类中方法数量足够少,才可以在方法级别上违反单一职责原则;
1.1 定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。
1.2 当软件需要变化时,尽量通过扩展软件实体的行为来实现变化, 而不是通过修改已有的代码来实现变化。
1.3 开闭原则是总纲,他告诉我们要对扩展开放,对修改关闭。
2 迪米特法则(Law Of Demeter)
2.1 迪米特法则又叫最少知道原则
2.2 定义:一个对象应该对其他对象保持最少的了解
2.3 软件编程的总的原则:低耦合,高内聚
2.4 迪米特法则还有一个更简单的定义:只与直接的朋友通信。
2.5 我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友
3 接口隔离原则(Interface Segregation Principle)
3.1 定义:客户端不应该依赖它不需要的接口; 一个类对另一个类的依赖应该建立在最小的接口上。
3.2 接口是设计时对外部设定的“契约”,通过分散定义多个接口, 可以预防外来变更的扩散,提高系统的灵活性和可维护性。
4 依赖倒置原则(Dependence Inversion Principle)
4.1 定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象; 抽象不应该依赖细节;细节应该依赖抽象。
4.2 依赖倒置原则基于这样一个事实:相对于细节的多变性,抽象的东西要稳定的多。 以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。
4.3 依赖倒置原则的中心思想是面向接口编程
5 里氏替换原则(Liskov Substitution Principle)
5.1 定义2:所有引用基类的地方必须能透明地使用其子类的对象
5.2 里氏替换原则通俗的来讲就是:子类可以扩展父类的功能,但不能改变父类原有的功能。
5.3 子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法。
5.4 子类中可以增加自己特有的方法。
5.5 当子类的方法重载父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。
5.6 当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。
6 单一职责原则(Single Responsibility Principle)
6.1 定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。
6.2 职责扩散
6.2.1 所谓职责扩散,就是因为某种原因,职责P被分化为粒度更细的职责P1和P2。
6.2.2 原则是:只有逻辑足够简单,才可以在代码级别上违反单一职责原则; 只有类中方法数量足够少,才可以在方法级别上违反单一职责原则;