查看“设计模式之禅单一职责原则”的源代码

===我是“牛”类，我可以担任多职吗===
:单一职责原则的英文名称是 Single Responsibility Principle，简称是 SRP。
这个设计原则备受争议，只要你想和别人争执、怄气或者是吵架，这个原则是屡试不爽的。如果你是老大，看到一个接口或类是这样或那样设计的，你就问一句：“你设计的类符合 SRP 原则吗？”保准对方立马“萎缩”掉，而且还一脸崇拜地看着你，心想：“老大确实英明”。这个原则存在争议之处在哪里呢？就是对职责的定义，什么是类的职责，以及怎么划分类的职责。我们先举个例子来说明什么是单一职责原则。

:只要做过项目，肯定要接触到用户、机构、角色管理这些模块，

基本上使用的都是 RBAC 模型（Role-Based Access Control，基于角色的访问控制，通过分配和取消角色来完成用户权限的授予和取消，使动作主体（用户）与资源的行为（权限）分离），确实是一个很好的解决办法。我们这里要讲的是用户管理、修改用户的信息、增加机构（一个人属于多个机构）、增加角色等，用户有这么多的信息和行为要维护，我们就把这些写到一个接口中，都是用户管理类嘛，我们先来看它的类图，如图所示：
[[文件:用户信息维护类图.png|居中|缩略图|493x493像素]]
:太 Easy 的类图了，我相信，即使是一个初级的程序员也可以看出这个接口设计得有问题，用户的属性和用户的行为没有分开，这是一个严重的错误！
这个接口确实设计得一团糟，应该把用户的信息抽取成一个 BO（Business Object，业务对象），把行为抽取成一个 Biz（Business Logic，业务逻辑），按照这个思路对类图进行修正，如图所示：
[[文件:职责划分后的类图.png|居中|缩略图|815x815像素]]