构建

还是用上文里汽车的例子.

通常情况下, 我们是先去建造汽车, 组装好汽车后, 我们再去驾驶它.

软件开发也类似, 我们应该把对象构造完毕之后, 再去用它. 但是有时候, 开发者会在构造过程中添加一些程序逻辑. 这就相当于车还没造完, 我们就驾驶它去兜风了. 这样做是不太好的.

构造函数是类用来创建其实例对象的方法, 这里的代码是用来准备该对象的. 但有时开发者会在构造函数里做一些其它的工作, 例如构建依赖项, 执行初始化逻辑等等.

在构造函数(或者更大一点, 指构建的过程)里, 做这些额外的工作会让测试变得异常困难. 这是因为像初始化依赖项, 调用服务, 设置状态的逻辑等这些工作会把用于测试的"缝"弄丢. 导致无法进行mock.

总之在构造的过程中做太多的工作会妨碍测试.

危险信号

在构造函数/字段声明里出现new关键字
- 如果构造函数里需要创建依赖, 那么这就会为该类与依赖项之间创造了紧耦合. 这个之前提过, 所以需要注入依赖. 但是简单的值类型, 例如字符串, List, Dictionary等还是可以的.
在构造函数/字段声明里调用静态方法
- 静态方法不可以被mock, 也不能被注入.
构造函数出现流程控制逻辑代码
- 这样就很难对逻辑直接进行测试了. 我们只能分别使用不同的方式构造该对象, 测试并确认对象的状态. 而这个状态通常对直接测试是隐藏的. 实际上只要不是赋值代码, 就有可能是问题代码.
构造函数里出现非赋值代码
存在另外一个初始化函数 (也就是说构造函数走了完, 但是对象并没有被完全初始化)

不要在构造函数里创建依赖项, 应该注入它们. 然后在构造函数里把它们赋值给类的私有变量.
当需要构建对象图(一组有引用关系的对象), 也包括对象需要一些构建的参数等情况, 应该使用工厂, 建造者模式, 或者IoC容器的依赖注入等, 目的是把这些对象的构建工作分离出去.
避免在构造函数里写逻辑代码, 例如条件, 循环, 计算等等. 也不能把逻辑代码放在别的方法, 然后调用该方法...

总之就是要避免对象的构建和对象的行为混合到一起, 因为它们在一起就会很难进行测试.

最后还有一点, 首先你需要知道, 根据angular的创始人Misko Hevery所说:

对象的构造分两类, 一种是可注入的, 一种是可new的.

可注入的对象可以由其它的一堆可注入对象组成. 它们可以为可new的对象工作. 可注入的对象通常是实现了接口的service, 像什么IUnitOfWork, IRepository, IxxxService等等.

可new的对象就是对象图里的终点, 例如实体或者值对象(Value Object)等.

为了易于测试, 针对这两类构造, 有下列规则:

可注入的对象可以在构造函数请求(注入)其它的可以注入对象, 但是不能在构造函数请求可new的对象.

反过来, 可new的对象可以在构造函数请求其它的可new对象, 但是不能在构造函数请求可注入的对象.