六大设计原则------单一职责原则

单一职责原则

单一职责原则 Single Responsibility Principle 简称SRP

什么是类的单一职责原则:

There should never be more than one reason for a class to change

(应该有且仅有一个原因引起类的变更)

例子:

通常企业级项目都会设计到权限控制模块，而权限控制模块又会涉及到用户、权限、角色这三个部分。

而针对这三个部分，基本上使用的是RBAC模型(Role-Based Access Control)，也就是基于角色的访问控制。

通过分配和取消角色来控制用户的权限，使用户和权限分离。

那么针对用户模块，我们需要对用户进行管理、修改用户信息、增加角色、修改角色等操作，那么我们先来看把上述这些操作都写在同一个接口(类)中，是什么情况。

用户信息维护类图:

上述类图设计不合理的地方:

用户的属性和用户的行为没有分开。

理由:

用户的属性和行为都能够改变User类，违背了单一职责原则。

改进方案:

把用户的信息抽取成一个BO(Business Object,业务对象),把用户的行为抽取成一个Biz(Business Logic,业务逻辑)。

职责划分后的类图:

示例代码:

User user = new UserImpl();
UserBo userBo = (UserBo)user;
//赋值
userBo.setPassword(“abc”);
//行为
UserBiz userBiz = (UserBiz)new UserBiz();
userBiz.deleteUser();

在实际运用上，我们更倾向于使用两个不同的类和接口:

项目中经常采用的SRP类图

第二个例子:

模拟电话通话的业务:

电话通话的时候有4个动作发生: 拨号、通话、回应、挂机

那么根据这些动作，我们写一个电话接口:

Public interface Phone {

//拨通电话
public void dial(String phoneNumber);

//通话
public void chat(Object o);

//通话完毕，挂电话
public void hangup();

}

通常情况下，我们都会这么设计接口，但是这个接口有缺陷:

这个接口负责了两个职责:

1、协议管理(拨通电话、挂电话)
2、数据传送(通话)

所以，会有两个原因导致这个接口或实现类影响变化，一个是协议管理的变化，一个是数据传送的变化(因为上网也会传送数据)，所以这个接口违背了单一职责原则。

处理:拆分成两个接口

上述这个类图，完全满足了单一职责原则的要求，每个接口职责分明，结构清晰.

但是也有缺陷:

一个手机类(Phone)要把ConnectionManager和DataTransfer组合在一块才能使用。而组合是一种强耦合关系，你和我有共同的生命周期，这样的强耦合关系还不如使用接口实现的方式，而且还增加了类的复杂性，多了两个类。

再次修改类图:

分析一下这个类图:

1、一个类实现了两个接口，把两个职责融合在一个类中。这样做虽然Phone有两个原因引起变化，但是我们是面向接口编程，我们对外公布的是接口而不是实现类。

---

总结:

单一职责原则的好处:

1、类的复杂性降低，实现什么职责都有清晰明确的定义

2、可读性提高，复杂性降低

3、可维护性提高，可读性提高

4、变更引起的风险降低

---

单一职责适用于接口、类，同时也适用于方法，也就是说，一个方法尽可能做一件事情。

---

但是单一职责原则很难在项目中得到体现，因为在项目中需要考虑环境，考虑工作量，考虑人员的技术水平，考虑硬件的资源情况，等等。最终的结果往往违背单一职责原则。所以，在项目中，我们要尽量做到单一职责原则。