.NET Core TDD 前传: 编写易于测试的代码 -- 单一职责

第1篇: 讲述了如何创造"缝".  "缝"(seam)是须要知道的概念.

第2篇, 避免在构建对象时写出不易测试的代码.

第3篇, 依赖项和迪米特法则.

第4篇, 全局状态引发的问题.

本文是第5篇, 也是最后一篇, 介绍的是单一职责

 

类作了太多的工做

例子, 某软件公司, 原有项目开发, 测试, 售前, 售后, 财务等员工. 后来因为公司没钱, 裁掉了测试, 让开发兼职; 过了段时间, 又裁掉了需求和售后, 仍是由你这个开发来兼职; 再过了段时间, 又裁掉了财务和售前, 仍是由你来兼职.

某天上班以后, 你刚想写代码, 就接到了客户来电, 说键盘很差用, 让你去给调试一下. 花了1个小时从客户那里调试回来又刚想写点代码, 某客户说发票没给, 你又去快递发票. 回来以后又想写代码, 又有客户来电话咨询你公司的XXX管理系统, 通过半个小时的讲解, 客户没兴趣. 这时已经到了中午, 你却发现你的本职工做一点都作.

在现实世界中, 给某个员工赋与不少冲突的角色或职责是很不明智的.

在软件开发里也是这样的, 在为一个类赋予太多的职责会引出不少维护和测试的问题.

单一职责

单一职责是面向对象软件设计的准则之一, 它说的是: "一个类只能由于一个缘由去改变".

这就是说咱们应该增长 由于相同缘由而作出改变的东西 的内聚性, 而下降 因为不一样缘由而作出改变的东西 的耦合性.

这句话一般被描述为: "一个类或一个方法只应该作一件事情, 而且要把它作好".

 

若是一个类有了太多的职责, 那么职责间的交互就会埋藏于类里, 这样作就很难一次修改一个职责. 对于测试来讲, 这些交互之间也没有明显的"缝隙".

依赖项的构建工做并非目标类自己的职责, 这项工做应该和类自己的职责分开. 因此咱们会使用依赖注入配置好的对象. 咱们应该对类进行抽取, 让其成为单一职责的类.

 

引发的问题

若是一个类有多个职责, 那么在测试上它会有如下问题:

• 若是一个类/方法有太多的功能, 那么针对它的测试就会特别多, 很容易让人难于理解也很难维护.
• 测试的设置也会更加的麻烦. 
• 因为有多个缘由去修改该类, 那么它的测试类/方法就会修改的更加频繁.

 

危险信号

什么样的类/方法会违反单一职责呢?

• 若是你在描述该类功能的时候用到了"和", "或", "还", "而且"等词.
• 类或者方法的代码不少.
• 注入了太多的依赖项.
• 一个类改变的太频繁了也可能意味着这个类的职责可能不止一个.

 

解决方案

若是一个类有不少职责, 那么能够这样作:

• 识别出类里面各个独立的职责.
• 给每一个职责贴上标签.
• 解耦, 把其它功能抽取到单独的类, 最后保证每一个类都是单一职责.

 

例子

举一个很简单的典型例子:

 

这个类, 有4个依赖项, 不算特别多, 可是也很多. 它的名字在这里就是它的描述, 里面包含了"或"的意思. 在它的方法参数里, 有一个标识, 像这样会改变方法的高级行为的标识, 一般就意味着该方法会有不止一个职责. 而方法体里面, 咱们能够看到它确实有两个职责, 分别是发送邮件和打电话给客户.

 

优化后

通过识别, 抽取后, 该类应该分红下面两个类:

EmailCommand:

 

 

CallCommand:

 

这个系列的帖子就到这了.

下面开始介绍TDD.