设计模式之禅--六大原则之单一职责原则

设计模式之单一职责原则

（本书例子来自设计模式之禅，内容多为作者对书的总结，加理解）

设计模式六大原则之一：单一职责原则

英文名：Single Responsibility Principle 简称SRP

定义：应该有且仅有一个原因引起类的变更

首先来看一个用户管理类的接口：



ok,我相信，即使是一个初级的程序员也可以看出这个接口设计的有问题。（PS：书中原话，我当时看了好几遍，觉得设计得很好，汗···）问题在于用户的属性和用户的行为没有分开，这是一个严重的错误。我们应该吧用户的信息抽取成一个BO（Bussiness Object，业务对象），把用户的信息抽取成一个Biz(Business Logic, 业务逻辑），如下图所示



使用时，要获得用户信息的，就当是IUserBO的实现类，要是希望维护用户信息，就把它当成IUserBiz的实现类，代码如下：

public static void main(String[] args) {
IUserBiz userInfo = new UserInfo();

//我要复制了，我就认为它是一个纯粹的BO
IUserBO userBO = (IUserBO)userInfo;
userBO.setPassword("abc");

//我要执行动作了，我就认为是一个业务逻辑类
IUserBiz userBiz = (IUserBiz)userInfo;
userBiz.deleteUser();

}

其实，在实际使用中，我们更倾向于使用两个不同的类或接口：一个是IUserBO，一个是IUserBO，类图如下：



现在我想大多数人都能明白单一职责原则是怎么一回事了，来看一下它的应用。理解为什么要用单一职责原则

电话通话时会有四个过程：拨号、通话、回应、挂机，那我们写一个接口，类图如下：



OK、我们现在可以很容易的根据单一职责原则说它设计的有问题：这个接口拥有两个职责：一个是协议管理（dial（）和hangup（），分别实现拨号和挂机），一个是数据传送（模拟信号的传递），那我们将其根据单一职责原则重新设计，又这两种职责的变化不互相影响，则：



我觉得单一职责原则的好处如果不在项目中实际应用中得到理解并不好体会，这里是书中总结的优点：

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

代码的可读性提高

可维护性提高

变更引起的风险降低，变更时必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的拓展性、维护性都有极大的帮助。

单一职责不仅适用于接口、类，同时也适用于方法。即一个方法尽可能的做一个事情，像下面的这个方法就不可取：



应该是这个样子：



（是的，类的单一职责原则确实受非常多因素的制约，纯理论地来讲，这个原则是非常优秀的，但是现实有现实的难处…）

(对于单一职责原则，我的建议是接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。）（PS：作者原话）