背景
这是之前参加的一个工程师交流会上别人分享的一个小议题,做了一些笔记,后面整理资料的时候又从网上搜集了一些做补充,今天分享一下
代码的可测性
测试性不好的代码特征
缺陷1: 构造函数做了实际工作
- 构造函数或域声明中出现new字眼
- 构造函数或域声明中调用静态方法
- 构造函数做了分配域字段之外的事情
- 构造函数中,对象初始化工作没有完成彻底(小心初始化方法)
- 构造函数中,出现了控制流(基于条件或循环的逻辑)
- 在构造函数内构造复杂的对象图,而不是使用工厂(factory)模式或构造器(builder)模式
- 增加或使用初始化块
缺陷2: 滥用协作类
- 引入了对象,却不直接使用(而是用于通往其它对象)
- 不遵守迪米特法则:对象图中,方法引用链包含了多个下标点(.)
- 可疑命名:如context,environment,principal,container或manager
缺陷3: 脆弱的全局变量&单例(Singleton)
- 增加或使用单例
- 增加或使用静态域字段或静态方法
- 增加或使用静态初始化块
- 增加或使用寄存器
- 增加或使用服务定位器
缺陷4: 类做事太多
- 总结该类的作用时,得使用以及之类的描述语
- 团队新成员很难读懂和快速接手该类
- 该类的某些域字段只用到部分方法中
- 该类的某些静态方法仅针对参数操作
构造函数
一个常见的测试性不好的地方就是在构造函数中做了实际工作,在构造函数中执行功能相当于让对象实例化难上加难,或者说给对象模拟增加困难
例1: 构造函数或域声明中出现了new字眼