单一职责原则(SRP)已经几乎是每一个程序员都知道的设计原则。最早由Robert C. Martin在<<敏捷软件开发 — 原则、模式与实践>>中正式提出。书中作者在结论中提到:
SRP是所有设计原则最简单的，但也是最难运用的。（中文翻译有之一，略去了)
现实工作中，关于一个类是否符合SRP，或者是否有必要符合SRP的讨论是经常发生的。争论的关键在于职责的定义，但我理解SRP真正的核心是关注于变化。这并不是我的新见解，全是来自Martin大叔的解释：
- 首先职责的定义是: 引起变化的原因，不是由分类所决定的。如果存在相对的变化，才要考虑分离。
- 其次，关于引起变化的因素，不要空想。一定确信有变化的可能，也会加以考虑。
他的提醒是非常中肯的。实践中正是常常基于功能的分类来定义职责的。
举个例子。假如我们要开发一个学样的教职员工管理系统。需要定义一个教师员工的类(炒菜的师傅先就考虑了)，考虑到老师和班主任两个角色，通常会认为他有两类职责:
. 教师 (班主任很可能会带课)
. 班级的管理 (组织班委，整治一下早恋之类的)
这时你拿着设计到了一个寄宿学校，校长可能会告诉你，他们这里的教师会轮流值班，兼做保育员，照看住校的学生。又是一个新的职责，怎么办?
如果遵守单一职责的原则，我们应该增加一个接口:
果真要如此吗? 注意，如果是在一般的学校，保育员不是老师的本职工作，可在这所寄宿学校里，却是教师的本职工作，是和老师一起变化的。校长的反馈是:
“我们学校的教师必须担任保育工作，我并不认为这会是什么新职责。作为教师，要么接受，要么离开。至于班主任工作，确实还是其特殊的地方，不然也不会给担任班主任的老师多一点津贴了。”。
请再体会一下，关于保育员职责的讨论。如果两个职责/角色不是同时变化的，才考虑分离。如果确定同时变化，就没有必要分离。除非有一天，某个劳动部门到该寄宿学校检查，认为他们这样不符合某个法律规定，强制规定老师可以选择是否担当保育员。如此一来，两个职责就又变成独立变化的了，就可以考虑分离职责。
再进一步，如果是针对一个只有一个教师支教的小学，极为偏僻。这里的校长会告诉你:
”这个学校里的每一个教师，唯一的一个，既是校长，也是老师。我不认为还需要明确班主任做什么，教师做什么，在这里，只要学生需要的都要做。并且这里很穷，五年内都不见得再有新老师来。”。
这么感人的故事告诉我们，在这所学校里， 他不在了，这所学校也就不在了，完全没有什么相对的变化，也没有什么可以确认的变化。所以在这里的管理系统里，教职员工只有一个实例类,:
(向朱敏才孙丽娜夫妇致敬!)
聊到这里，不知道我说清楚了没有！设计要跟着需求走，不能生硬的套理论。欢迎拍砖!