六大设计原则(一)SRP单一职责原则

单一职责原则SRP(Single reponsibility principle)

BO(Business Object):业务对象
Biz(Business Logic):业务逻辑

SRP最简单的例子:用户信息维护类

六大设计原则(一)SRP单一职责原则
六大设计原则(一)SRP单一职责原则

单一职责原则SRP定义

应该有且仅有一个原因引起类的变更。(一个接口只有一个职责

SRP例子:电话通话过程

电话通话的过程:拨号、通话、回应、挂断。
六大设计原则(一)SRP单一职责原则
如果按照一定职责进行划分:可以分为协议管理数据传送
协议管理:拨号和挂机。
数据传送:通话.
这个类中包含两个职责,但是拨号和挂机与通话互不影响相互独立(即拨号就是拨号,挂机就是挂机,他们两个在执行完后,进行通话,并不会再产生影响。)。此时该类可以进一步优化为两个职责即划分为两个接口。六大设计原则(一)SRP单一职责原则

组合关系:虚线箭头,整体与部分的关系,菱形指向整体部分,部分不能离开整体。(电话由协议部分和数据传送两部分构成,任何一个单独存在都不能使用)
实现关系:虚线空心箭头,类实现接口。
依赖关系:菱形箭头,使用关系:类的实现需要另一个类的协助。(数据传输的过程需要进行拨号和挂断)

组合关系是一种强耦合关系,由此划分会多出两个类,增加类的复杂性,因此可以才用面向接口编程重新设计此类图。
六大设计原则(一)SRP单一职责原则

SRP优点

  • 类的复杂性降低,实现的职责有了清晰的定义。
  • 可读性提高。
  • 可维护性提高。
  • 变更引起的风险降低。

    SRP存在的问题

  • SRP标准不同导致,职责可以有多种划分方法。单一职责划分提出了编写程序的标准,用职责和变化原因衡量,接口设计的优良,但是由于不同项目而导致的度量标准也是不同的。
  • SRP不能过分细分,否则会导致类的剧增,增加维护成本。

    SRP应用范围

    接口、类、方法。
    SRP应用到方法中,每个方法的职责明确清晰。
    如图,此方法根据参数类型进行绑定到userBo进行相关操作。即一个方法承担了多个职责。
    六大设计原则(一)SRP单一职责原则
    改进后:一个方法承担一个职责
    六大设计原则(一)SRP单一职责原则

    SRP总体要求

    接口一定要做到单一职责,类的的设计尽量做到单一职责

上一篇:zigbee学习之路(五):定时器1(查询方式)


下一篇:sqlmap 使用总结