代码重构之道（二）
作者：互联网
过长参数列
太长的参数列难以理解，太多的参数会造成前后不一致、不容易使用，而且一旦你需要更多数据，就不得不修改它。如果将对象传递给函数，大多数修改都将没有必要。
发散式变化
如果某个类经常因为不同的原因在不同的方向上发生变化，那么此时也许将这个对象分成两个会更好，这么一来每个对象就可以只因为一种变化而需要修改。
散弹式修改
如果没遇到某种变化，你都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是散弹式修改。如果需要修改的代码散布四处，你不但很难找到它们，也很容易忘记某个重要的修改。
把所有需要修改的代码放进同一个类中，如果眼下没有合适的类可以安置这些代码就创造一个。
依恋情结
对象技术的要点在于：将数据和对数据的操作行为包装在一起（充血模型的思想）
有一种经典的气味是：函数对某个类的兴趣高过对自己所处类的兴趣。某个函数为了计算某个值，从另一个对象那调用几乎半打的取值函数。
一个函数往往会用到几个类的功能，那么它该置于何处？我们的原则是：判断哪个类拥有最大被此函数使用的数据，然后就把这个函数和那些数据放在一起。
数据泥团
很多地方看到相同的三四项数据一起出现。这些总是绑在一起出现的数据应该拥有属于他们自己的对象。
首先找到这些数据以字段形式出现的地方，将它们提炼到一个独立的对象中。这么做的直接好处是可以将很多参数列缩短简化函数调用。
比如：商品名称，商品价格，商品种类，商品重量…总是一起出现，于是我包装了一个商品类
但是实际开发中，可能看起来并没关系的几个属性，也总是一起出现，那也可以包一个类。
但是实际并不建议这样做，因为目前主流的设计思想是领域驱动设计，它认为，客观现实所存在的东西，才能抽象成数据模型。
基本类型偏执
对象的一个极大价值在于：它们模糊了横旦与基本数据和体积较大的类之间的界限
对象技术的新手通常不愿意在小任务上运用小对象——结合数值和比重的money类、有一个起始值和一个结束值组成的range类。将原本单独存在的数值替换成对象，从而走出传统的洞窟，进入炙手可热的对象世界。
switch惊悚现身
面向对象的一个最明显的特征是：少用switch语句
一看到switch语句，就应该考虑以多态来替换它。
如果只是在单一函数中有些选择实例，且并不想改动它们，那么多态就有点杀鸡用牛刀了。
平行集成体系
每当你为某个类增加一个子类，必须也为另一个类相应增加一个子类。
消除这种重复性的一般策略是：让一个继承体系的实例引用另一个继承体系的实例。
冗余类
某个类原本对得起自己的身价，但重构使它身形缩水，不再做那么多工作，这个时候请让这个类庄严赴义吧。
标签：重构,函数,对象,代码,之道,修改,一个,某个,数据 来源： https://blog.csdn.net/GBS20200720/article/details/122767134