代码的坏味道（7）-Feature Envy（依恋情结）

代码的坏味道（7）-Feature Envy（依恋情结）

无数次经验里，我们看到某个函数为了计算某值，从另一个对象那儿调用几乎半打的取值函数（getting method）。疗法显而易见：把这个函数移至另一个地点。你应该使用 Move Method（142）把它移到它该去的地方。有时侯函数中只有一部分受这种依恋之苦，这时候你应该使用 Extract Method（110）把这一部分提炼到独立函数中，再使用 Move Method（142）带它去它的梦中家园。

当然，并非所有情况都这么简单。一个函数往往会用上数个classes特性，那么它究竟该被置于何处呢？我们的原则是：判断哪个class拥有最多[被此函数使用]的数据，然后就把这个函数和那些数据摆在一起。如果先以 Extract Method（110）将这个函数分解为数个较小函数并分别置放于不同地点，上述步骤也就比较容易完成了。

有数个复杂精巧的模式（patterns）破坏了这个规则。说起这个话题，[四巨头][Gang of Four]的 Strategy和 Visitor立刻跳入我的脑海，Kent Beck的 Self Delegation[Beck]也在此列。使用这些模式是为了对抗坏味道 Divergent Change。最根本的原则是：将总是一起变化的东西放在一块儿。[数据]和[引用这些数据]的行为总是一起变化的，但也有例外。如果例外出现，我们就搬移那些行为，保持[变化只在一地发生]。 Strategy和 Visitor使你得以轻松修改函数行为，因为它们将少量需被覆写（overridden）的行为隔离开来-当然也付出了[多一层间接性]的代价。