六大设计原则（一）SRP单一职责原则

单一职责原则SRP（Single reponsibility principle）

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

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

单一职责原则SRP定义

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

SRP例子：电话通话过程

电话通话的过程：拨号、通话、回应、挂断。

如果按照一定职责进行划分：可以分为协议管理和数据传送。
协议管理：拨号和挂机。
数据传送：通话.
这个类中包含两个职责，但是拨号和挂机与通话互不影响相互独立(即拨号就是拨号，挂机就是挂机，他们两个在执行完后，进行通话，并不会再产生影响。)。此时该类可以进一步优化为两个职责即划分为两个接口。

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

组合关系是一种强耦合关系，由此划分会多出两个类，增加类的复杂性，因此可以才用面向接口编程重新设计此类图。

SRP优点

• 类的复杂性降低，实现的职责有了清晰的定义。
• 可读性提高。
• 可维护性提高。

• 变更引起的风险降低。

  SRP存在的问题

• SRP标准不同导致，职责可以有多种划分方法。单一职责划分提出了编写程序的标准，用职责和变化原因衡量，接口设计的优良，但是由于不同项目而导致的度量标准也是不同的。

• SRP不能过分细分，否则会导致类的剧增，增加维护成本。

  SRP应用范围

  接口、类、方法。
  SRP应用到方法中，每个方法的职责明确清晰。
  如图，此方法根据参数类型进行绑定到userBo进行相关操作。即一个方法承担了多个职责。
  
  改进后：一个方法承担一个职责
  

  SRP总体要求

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