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

前端之家收集整理的这篇文章主要介绍了[OOD] 为什么单一职责原则(SRP)是最难运用的前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
单一职责原则(SRP)已经几乎是每一个程序员都知道的设计原则。最早由Robert C. Martin在<<敏捷软件开发 — 原则、模式与实践>>中正式提出。书中作者在结论中提到:
SRP是所有设计原则最简单的,但也是最难运用的。中文翻译有之一,略去了)

现实工作中,关于一个类是否符合SRP,或者是否有必要符合SRP的讨论是经常发生的。争论的关键在于职责的定义,但我理解SRP真正的核心是关注于变化。这并不是我的新见解,全是来自Martin大叔的解释:
  1. 首先职责的定义是: 引起变化的原因,不是由分类所决定的。如果存在相对的变化,才要考虑分离。
  2. 其次,关于引起变化的因素,不要空想。一定确信有变化的可能,才会加以考虑。

他的提醒是非常中肯的。实践中正是常常基于功能分类来定义职责的。


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


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

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


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

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


请再体会一下,关于保育员职责的讨论。如果两个职责/角色不是同时变化的,才考虑分离。如果确定同时变化,就没有必要分离。除非有一天,某个劳动部门到该寄宿学校检查,认为他们这样不符合某个法律规定,强制规定老师可以选择是否担当保育员。如此一来,两个职责就又变成独立变化的了,就可以考虑分离职责。

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

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


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

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

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

原文链接:https://www.f2er.com/javaschema/284834.html

猜你在找的设计模式相关文章