单一职责原则SRP(Single reponsibility principle)
BO(Business Object):业务对象
Biz(Business Logic):业务逻辑
SRP最简单的例子:用户信息维护类
单一职责原则SRP定义
应该有且仅有一个原因引起类的变更。(一个接口只有一个职责)
SRP例子:电话通话过程
电话通话的过程:拨号、通话、回应、挂断。
如果按照一定职责进行划分:可以分为协议管理和数据传送。
协议管理:拨号和挂机。
数据传送:通话.
这个类中包含两个职责,但是拨号和挂机与通话互不影响相互独立(即拨号就是拨号,挂机就是挂机,他们两个在执行完后,进行通话,并不会再产生影响。)。此时该类可以进一步优化为两个职责即划分为两个接口。
组合关系:虚线箭头,整体与部分的关系,菱形指向整体部分,部分不能离开整体。(电话由协议部分和数据传送两部分构成,任何一个单独存在都不能使用)
实现关系:虚线空心箭头,类实现接口。
依赖关系:菱形箭头,使用关系:类的实现需要另一个类的协助。(数据传输的过程需要进行拨号和挂断)
组合关系是一种强耦合关系,由此划分会多出两个类,增加类的复杂性,因此可以才用面向接口编程重新设计此类图。
SRP优点
- 类的复杂性降低,实现的职责有了清晰的定义。
- 可读性提高。
- 可维护性提高。
- 变更引起的风险降低。
SRP存在的问题
- SRP标准不同导致,职责可以有多种划分方法。单一职责划分提出了编写程序的标准,用职责和变化原因衡量,接口设计的优良,但是由于不同项目而导致的度量标准也是不同的。
- SRP不能过分细分,否则会导致类的剧增,增加维护成本。
SRP应用范围
接口、类、方法。
SRP应用到方法中,每个方法的职责明确清晰。
如图,此方法根据参数类型进行绑定到userBo进行相关操作。即一个方法承担了多个职责。
改进后:一个方法承担一个职责
SRP总体要求
接口一定要做到单一职责,类的的设计尽量做到单一职责