[OOD] 为什么单一职责原则(SRP)是最难运用的

标签：软件开发   设计模式   

1. 首先职责的定义是: 引起变化的原因，不是由分类所决定的。如果存在相对的变化，才要考虑分离。
2. 其次，关于引起变化的因素，不要空想。一定确信有变化的可能，也会加以考虑。

举个例子。假如我们要开发一个学样的教职员工管理系统。需要定义一个教师员工的类(炒菜的师傅先就考虑了)，考虑到老师和班主任两个角色，通常会认为他有两类职责:
  . 教师 (班主任很可能会带课)
  . 班级的管理 (组织班委，整治一下早恋之类的)


这时你拿着设计到了一个寄宿学校，校长可能会告诉你，他们这里的教师会轮流值班，兼做保育员，照看住校的学生。又是一个新的职责，怎么办?

如果遵守单一职责的原则，我们应该增加一个接口:

果真要如此吗? 注意，如果是在一般的学校，保育员不是老师的本职工作，可在这所寄宿学校里，却是教师的本职工作，是和老师一起变化的。校长的反馈是: 

 “我们学校的教师必须担任保育工作，我并不认为这会是什么新职责。作为教师，要么接受，要么离开。至于班主任工作，确实还是其特殊的地方，不然也不会给担任班主任的老师多一点津贴了。”。

再进一步，如果是针对一个只有一个教师支教的小学，极为偏僻。这里的校长会告诉你:

   ”这个学校里的每一个教师，唯一的一个，既是校长，也是老师。我不认为还需要明确班主任做什么，教师做什么，在这里，只要学生需要的都要做。并且这里很穷，五年内都不见得再有新老师来。”。

这么感人的故事告诉我们，在这所学校里， 他不在了，这所学校也就不在了，完全没有什么相对的变化，也没有什么可以确认的变化。所以在这里的管理系统里，教职员工只有一个实例类,:

(向朱敏才孙丽娜夫妇致敬!)

聊到这里，不知道我说清楚了没有！设计要跟着需求走，不能生硬的套理论。欢迎拍砖!

[OOD] 为什么单一职责原则(SRP)是最难运用的

标签：软件开发   设计模式   

原文地址：http://blog.csdn.net/horkychen/article/details/45119393