- 单一职责原则:类的职责单一 【封装性】
- 开放封闭原则:修改封闭,扩展放开
- 里氏替换原则:子类完全可以替换父类
- 依赖倒置原则:具体实现依赖抽象接口
- 接口分离原则:(接口隔离)接口与接口的分离【横向】 接口应该尽量单一
- 迪米特原则 :最少知道原则,【不和陌生人说话】
单一职责原则 (SRP)[Single Responsibility Principle]
“业务”—— 职责
, 从业务的角度考虑。
业务的模块化
。
定义:就一个类而言,·
应该仅有一个引起它变化的原因
。
Note: 单一职责中的“职责”, 如何去衡量,是不可以度量的,由个人决定。
优点
- 职责清晰明确。
- 复杂度降低、可读性高、可维护性高、风险降低、扩展性好
开放封闭原则
定义:
软件实体(类、模块、函数等等)应该可以扩展,但是不可修改
修改关闭、扩展开放
应该是从一个类的角度去看这个问题。
现实:
无论模块是多磨封闭,都会存在一些无法对之封闭的变化。 既然不可能完全封闭,设计人员必须对于他设计的模块应该对那种变化封闭做出选择。 他必须先猜测出最有可能发生的变化种类,然后构造抽象来隔离那些变化。
PS: 主要是界定好变与不变的分割
里氏替换原则
定义:
子类必须能够替换掉它们的父类型
常规描述: 一个软件实体,如果使用的是一个父类的话,那么一定适用于其子类,而且它察觉不出父类对象和子类对象的区别。也就是说,在软件里面,把父类都替换成它的子类,程序行为没有变化。
PS: 使用的时候,就是子类化
只有当子类可以替换掉父类,软件单位的功能不受影响时,父类才能真正被复用,而子类也能够在父类的基础上增加新的行为。
正是因为 : 子类型的可替换才使得使用父类类型的模块在无需修改的情况下就可以扩展。
依赖倒置原则
定义:
A: 高层模块不应该依赖底层模块。 两个都应该依赖抽象
B: 抽象不应该依赖细节。 细节应该依赖抽象。
即为: 针对接口变成,不要对实现编程。
QR : 什么叫做倒置呢?
AN : 面向过程的开发时,为了使得常用代码可以复用,一般都会吧这些常用代码写成许许多多函数的程序库,这样我们在做新项目时,去调用这些低层的函数就可以了。 eg: 我们场做的项目大多要访问数据库,所以,我们就吧数据库的代码写成了函数,每次做新新项目时候就去调用这些函数。 —— 搞成模块依赖底层模块。
也就是实现依赖抽象 —— 倒置
eg: 这儿有一个“AutoSystem”类,它包含一个“ICar”接口。这个“AutoSystem”类根本不依赖于“FordCar”和“HondaCar”。所以,依赖关系被“倒置”了:“AutoSystem”模块依赖于抽象,那些具体的汽车操作也依赖于相同的抽象。
接口分离原则 (接口之间隔离) [SIP](Interface Segregation Principle)
主要解决:
胖接口[fat interface]
的问题。 建立单一接口,不要建立臃肿庞大的接口。
定义:
采用多个与特定客户类有关的接口比采用一个通用的接口要好。
接口分离原则是什么
- 客户端不应该依赖它不需要的接口
- 类间的依赖关系应该建立在最小的接口上。
也就是说:一个类对另一个类的依赖应该建立在最小的接口上,通俗的讲就是需要什么就提供什么,不需要的就不要提供。
迪米特原则
最少知识原则
:其实就是知道最少原则,也就是调用涉及的依赖尽可能的小。不要和陌生人说话的原则
定义:如果两个类不必彼此直接通信,那么两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某个方法的话,可以通过第三方转发这个调用。
接口分离原则# 和 #单一职责原则# 区分
-
单一职责
:主要是对职责这个概念的划分, 如果按照一个类作为一个职责,那么久体现在类的封装上面, 尽可能的只有一个因素影响到类。 -
接口分离
: 主要是针对依赖的关系,对一个flat interface的拆分,让依赖者更加后使用。