.NET Core TDD 前传: 编写易于测试的代码 -- 单一职责
第1篇: 讲述了如何创造"缝".? "缝"(seam)是需要知道的概念. 第2篇,?避免在构建对象时写出不易测试的代码. 第3篇,?依赖项和迪米特法则. 第4篇,全局状态引起的问题. 本文是第5篇,也是最后一篇,介绍的是单一职责 ? 类做了太多的工作例子,某软件公司,原有项目开发,测试,售前,售后,财务等员工. 后来由于公司没钱,裁掉了测试,让开发兼职; 过了段时间,又裁掉了需求和售后,还是由你这个开发来兼职; 再过了段时间,又裁掉了财务和售前,还是由你来兼职. 某天上班之后,你刚想写代码,就接到了客户来电,说键盘不好用,让你去给调试一下. 花了1个小时从客户那里调试回来又刚想写点代码,某客户说发票没给,你又去快递发票. 回来之后又想写代码,又有客户来电话咨询你公司的XXX管理系统,经过半个小时的讲解,客户没兴趣. 这时已经到了中午,你却发现你的本职工作一点都做. 在现实世界中,给某个员工赋与很多冲突的角色或职责是很不明智的. 在软件开发里也是这样的,在为一个类赋予太多的职责会引出很多维护和测试的问题. 单一职责单一职责是面向对象软件设计的准则之一,它说的是: "一个类只能因为一个原因去改变". 这就是说我们应该增加 因为相同原因而做出改变的东西 的内聚性,而降低 由于不同原因而做出改变的东西 的耦合性. 这句话通常被描述为: "一个类或一个方法只应该做一件事情,并且要把它做好". ? 如果一个类有了太多的职责,那么职责间的交互就会埋藏于类里,这样做就很难一次修改一个职责. 对于测试来说,这些交互之间也没有明显的"缝隙". 依赖项的构建工作并不是目标类本身的职责,这项工作应该和类本身的职责分开. 所以我们会使用依赖注入配置好的对象. 我们应该对类进行抽取,让其成为单一职责的类. ? 引起的问题如果一个类有多个职责,那么在测试上它会有以下问题:
? 危险信号什么样的类/方法会违反单一职责呢?
? 解决方案如果一个类有很多职责,那么可以这样做:
? 例子举一个很简单的典型例子: ? 这个类,有4个依赖项,不算特别多,但是也不少. 它的名字在这里就是它的描述,里面包含了"或"的意思. 在它的方法参数里,有一个标识,像这样会改变方法的高级行为的标识,通常就意味着该方法会有不止一个职责. 而方法体里面,我们可以看到它确实有两个职责,分别是发送邮件和打电话给客户. ? 优化后经过识别,抽取后,该类应该分成下面两个类: EmailCommand: ? ? CallCommand: ? 这个系列的帖子就到这了. 下面开始介绍TDD. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |