这是本人阅读秦小波老师的《设计模式之禅》第二版抄写的，有很多省略，不适合直接阅读，需要阅读请出门左转淘宝，右转京东，支持秦老师（侵权请联系删除）
第一章 单一职责原则
1.1我是“牛”类，我可以担任多职吗
单一职责原则的英文名称是Single Responsibility Principle，简称SRP。这个设计原则备受争议，只要你想和别人职责、怄气或者吵架，这个原则是屡试不爽的。如果你是老大，看到一个接口或者类是这样或那样设计的，你就问一句：“你设计的类符合SRP原则吗？”保准对方立马会“萎缩掉”，而且还一脸崇拜地看着你，心想：“老大确实英明”。这个原则存在的争议之处在哪里呢？就是对职责的定义，什么是类的职责，以及怎样划分类的职责。我们先举个例子来说明什么是单一职责原则。
只要做过项目，肯定要接触到用户、机构、角色管理这些模块，基本上使用的都是RBAC模型（Role-Based Access Control，基于角色的访问控制，通过分配和取消角色来完成用户权限的授予和取消，使动作主体（用户）与资源的行为（权限）分离），确实是一个很好的解决办法，我们这里要讲的是用户管理、修改用户信息、增加机构（一个人属于多个机构）、增加角色等，用户有个这么多的信息和行为要维护我们就把这些写到一个接口中，都是用户管理类嘛，我们先来看看它的类图
太easy的类图了，我相信，即使是一个初级程序员也可以看出这个借口设计的有问题，用户的属性和用户的行为没有分开，这是一个非常严重的错误！这个借口确实设计的一团糟，应该把用户的信息抽取成一个BO（Business Object，业务对象），把行为抽取成一个Biz(Business Logic,业务逻辑)，按照这个思路对类图进行修正
重新拆分这两个接口，IUserBO负责用户的属性，简单地说，IUserBO的职责就是收集和反馈用户的属性信息；IUserBiz负责用户的行为，完成用户信息的维护和变更。各位可能要说了，这个与我实际工作中用到的User 类还是有差别的呀！别着急，我们先看一看拆成两个接口怎么使用。OK,我们现在是面向接口编程所以长生了这个UserInfo对象之后，当然可以把它当IUserBO接口使用。也可以当成IUserBiz接口使用，这要看你在什么地方使用了。要获得用户信息，就当是IUserBO的实现类；要是希望维护用户的信息，就把它当做IUserBiz的实现类就成了，如下面代码
//new是在内存中创建了一个UserInfo对象，使用时应用为一个其他
IUserBiz userInfo = new UserInfo();
//我要赋值了，我就认为它是一个纯粹的BO
IUserBO userBO = (IUserBO)userInfo;
userBO.setPassword("abc");
//我要执行动作了，我就认为是一个业务逻辑类
IUserBiz userBiz= (IUserBiz)userInfo;
userBiz.deleteUser();
确实可以如此，问题也解决了，但是我们来分析一下刚才的动作，为什么把一个接口拆分成两个呢？其实，在实际的使用中，我们更倾向于使用两个不同的类或接口：一个IUserBO，一个事IUserBiz，类图
以上我们把一个接口拆分成两个接口的动作，就是依赖了单一职责原则，那什么是单一职责原则呢？单一职责原则的定义时：应该有且仅有一个原因引起累的变更。
1.2绝杀技，打破你的传统思维
解释到这里，估计你已经不屑了，“切！这么简单的东西还要讲？！”好我们讲点复杂的。SRP的原话解释是：
There should never be more than one reason for aclass to change.
这句话初中生都能看懂，不多说，但是看懂是一码事，实施就是另外一码事了。上面的例子很好理解，在实际项目中大家已经这么做了，那我们再来看看下面这个例子是否好理解。电话这玩意儿，是现代人都离不开，电话通话的时候有4个过程发生：拨号、通话、回应、挂机，那我们写一个接口，其类图
来我们看一下这个过程的代码