代码的坏味道之三——译自《重构》

散弹式修改(Shotgun Surgery)

　　　　散弹式修改和发散式变化类似，但却相反。每当你做一种修改你却必须对很多不同的类做很多小的变化，你面临的就是散弹式修改。当变化到处都是时，有的变化就不好找到了，这样很容易漏掉重要的更改。

　　　　这种情况下你要使用移动方法（Move Method）和移动字段（Move Field）来把所有的变化放到一个类里。如果没有现成的类合适，就创建一个类。通常你会用到内联化类（Inline Class）把一系列行为放到一起。你会有一点发散式变化的问题，但你可以轻松处理它。

　　　　发散式变化是一个类经受多种种类的修改，散弹式修改是一处修改改变了很多类。两种情况你都希望重新组织，这样理想状态下一个普通变化和类有一对一的链接关系。

 

依恋情节（Feature Envy）

　　　　对象的意义就是他们在技术上是数据和处理数据的操作的打包。常见的问题是一个方法对其他类比对自己所在的类更有兴趣。最普遍的嫉妒的焦点就是数据。我们数不清多少次我们看到一个方法为了计算一个值调用了6，7个另一个对象的get方法。幸运的是解决之道是很显而易见的，这个方法显然应该归于别处，所以你用移动方法（Move Method）来达到目的。有时方法中只有一部分有依恋情节，这种情况下用提取方法处理有依恋的部分，用移动方法来给他一个理想的归宿。

　　　　当然不是所有的情况都可以一刀切。通常一个方法使用若干类的特性，那么我们应该把他归于哪一个类呢？我们用的启示是取决于哪一个类中有大多数的数据，那么就把方法放在数据一起。如果已经使用提取方法来把方法分解成若干分离的部分，这一步可以做的轻松一些。

　　　　当然有一些精妙的模式会打破这一规矩。来自“四人帮”（Gang of Four）策略和访问者马上就浮现在脑海。Kent Beck的自委托是另一个例子。你用这些模式模式来处理发散式修改。最基本的规则是把一起修改的东西放在一起。数据和引用数据的行为经常一起修改，但也有例外。当例外出现时，我们把行为移动使变化保持在一个地方。策略和访问者模式允许你更容易的改变行为，因为他们以进一步的重定向为代价，隔离了一小部分需要倍覆盖的行为。

 

数据泥团（Data Clumps）

　　　　数据对象像小孩一样，他们喜欢聚在一群到处游荡。你常常会看到同样的三，四个数据对象一起出现在很多地方：一些类中的字段，一些方法签名里的参数。一簇到处都是的数据真的需要被放在他们自己的对象里。第一步是寻找在哪这些数据表现为字段。对这些字段用提取类把一簇转变为一个对象。然后把你的注意力转移到方法的签名上，用引入参数对象后者保全整个对象来缩减他们。马上带来的好处是你缩减了很多参数列表简化了方法的调用。不用为数据团只用了新对象的部分字段担心。只要你用两个或更多的字段替换为新的对象，你会进步的。

　　　　一个好的测试是考虑删除一个数据的值：如果你这样做其它数据是否还有意义？如果没有，这就是一个明确的信号告诉你要新建一个对象了。

　　　　减小字段列表和参数列表很明显会移除一些坏味道，但一旦当你有了这些对象时，你就拥有制造好味道的机会了。现在你可以寻找依恋情节的例子，那意味着行为可以被加入你的新类里。不久这些类就会成为社群中的高效成员。

 

转载于:https://www.cnblogs.com/browncrane/p/refactoring_3.html