<<重构>>里介绍的坏味道, 都是直接去嗅代码. 不过既然我们采用TDD, 那么代码的一切坏味道, 都会反应在测试上, 比如一个函数的测试用例组合太多, 可能意味着函数职责过多. 这在物理上称为对偶性, 即不同的表达方式, 反应的是同一件事. 两个非常不同的理论精确的描述了同样的现象. 分别让一对夫妻给你讲他们的故事，他们的说法会不同，但每个重要事件都能相互得到印证。和他们谈话多了，你就能指出两人说的故事有什么不同和联系。例如，丈夫觉得妻子过于自信，这正好印证了妻子抱怨丈夫太懦弱。我们可以说，两个人的话是互为对偶的。换句话讲, 我们可以通过观察测试而不是直接去看代码, 来发现代码的坏味道.
以上是题外话, 现在进入正题
今天在面向对象训练营的培训中, 发现了一种新的坏味道. 事情是这样的: 学员在完成按空位绝对数量多少停车的时候, 使用了继承, SmartBoy继承自Boy. 停车是不同的, override; 而取车是一样的, 代码都在基类里. 而在写测试的时候, 我发现他们分成了两派. 一派没有对SmartBoy的取车进行测试, 而另一派做了测试. 组织他们讨论, 两派的理由都有道理: 前者说取车代码只有一份, 前面Boy的测试已经测过了, 因此SmartBoy可以不测; 而后者说从功能上SmartBoy和Boy完全是独立的, 测试用例应该从功能分解下来, 因此应该测. 而你只是内部实现使用了继承, 要是我现在不测, 哪一天你不用继承了, 岂不是有破坏现有功能的风险?
我认为两者都有道理. 且不说可否从单元测试和功能测试的角度来解释(况且前面我们已经说了Unit Level Fucntional Test),单是这种争论的存在我们就可以思考: 是什么让我们陷入了可测可不测, 进退两难的境地?
几秒钟之后我想清楚了, 这是一种坏味道, 原因是这里有重复. 这里虽然没有重复的代码, 但是有重复的概念. SmartBoy根本就不是一个独立的概念. 同样的Boy加不同的选车位的策略才是更基本的概念. 重构到策略模式至少是一种可以消除争论的一种方案, 因为此时取车只有一份了, 无论从代码上还是概念上. 因此前面Boy的测试已经测过了, 我们根本不需要再写一遍
推而广之, 我们可以重新发现一种已知的坏味道: 实现继承. 而可有可无的测试和实现继承在坏味道方面是对偶的.