代码重构之道（二）

过长参数列

太长的参数列难以理解，太多的参数会造成前后不一致、不容易使用，而且一旦你需要更多数据，就不得不修改它。如果将对象传递给函数，大多数修改都将没有必要。

发散式变化

如果某个类经常因为不同的原因在不同的方向上发生变化，那么此时也许将这个对象分成两个会更好，这么一来每个对象就可以只因为一种变化而需要修改。

散弹式修改

如果没遇到某种变化，你都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是散弹式修改。如果需要修改的代码散布四处，你不但很难找到它们，也很容易忘记某个重要的修改。

把所有需要修改的代码放进同一个类中，如果眼下没有合适的类可以安置这些代码就创造一个。

依恋情结

对象技术的要点在于：将数据和对数据的操作行为包装在一起（充血模型的思想）

有一种经典的气味是：函数对某个类的兴趣高过对自己所处类的兴趣。某个函数为了计算某个值，从另一个对象那调用几乎半打的取值函数。

一个函数往往会用到几个类的功能，那么它该置于何处？我们的原则是：判断哪个类拥有最大被此函数使用的数据，然后就把这个函数和那些数据放在一起。

数据泥团

很多地方看到相同的三四项数据一起出现。这些总是绑在一起出现的数据应该拥有属于他们自己的对象。

首先找到这些数据以字段形式出现的地方，将它们提炼到一个独立的对象中。这么做的直接好处是可以将很多参数列缩短简化函数调用。

比如：商品名称，商品价格，商品种类，商品重量…总是一起出现，于是我包装了一个商品类

但是实际开发中，可能看起来并没关系的几个属性，也总是一起出现，那也可以包一个类。

但是实际并不建议这样做，因为目前主流的设计思想是领域驱动设计，它认为，客观现实所存在的东西，才能抽象成数据模型。

基本类型偏执

对象的一个极大价值在于：它们模糊了横旦与基本数据和体积较大的类之间的界限

对象技术的新手通常不愿意在小任务上运用小对象——结合数值和比重的money类、有一个起始值和一个结束值组成的range类。将原本单独存在的数值替换成对象，从而走出传统的洞窟，进入炙手可热的对象世界。

switch惊悚现身

面向对象的一个最明显的特征是：少用switch语句

一看到switch语句，就应该考虑以多态来替换它。

如果只是在单一函数中有些选择实例，且并不想改动它们，那么多态就有点杀鸡用牛刀了。

平行集成体系

每当你为某个类增加一个子类，必须也为另一个类相应增加一个子类。

消除这种重复性的一般策略是：让一个继承体系的实例引用另一个继承体系的实例。

冗余类

某个类原本对得起自己的身价，但重构使它身形缩水，不再做那么多工作，这个时候请让这个类庄严赴义吧。