种代码的怀味道.docxVIP

22种代码的怀味道 2021-12-17 一、反复代码 1、一个类中：提炼成一个函数 2、兄弟类中：提炼成一个函数，并且提取到父类中 3、两个不相关的类：提炼成一个函数，放到两个类中的一个类中或者一个单独的类中 二、过长函数 拆分成多个函数，将相关联的代码放在一个函数内，尽量保证每个函数只做一件事，且函数名见名之意 三、过大的类 保证每个类只做一件事，拆分成多个类 四、方法中过长的参数列 用对象做参数来削减参数个数 五、发散式变化 一个类做太多的事情了，万能类，经常由于不同的缘由在不同的方向上发生变化，将会产生发散式变化， 将变化隔离，封装变化，把变化的和不变的部分分开，拆分成多个类 六、散弹式变化 一个变化引发多个类的修改，把需要修改的部分抽取出来，放到一个单独的类中 七、依恋情节 （红杏出墙的函数）使用了大量其他类的成员 函数对其他类的函数的调用比所处类还多，函数调用其他类的函数一般是需要其他类的数据，将该函数移动到它使用数据的类中，将数据和对数据的操作行为包装在一起， 具体是：假如该方法只调用了一个类的多个方法。将该方法移到调用类里。 假如该方法调用了多个类的多个方法。将该方法拆解。然后分别到调用类里 八、数据泥团 总是成堆消灭在一起的数据，应当封装在一个单独的类中，比如你经常可以在很多地方看到相同的三四项数据：两个类中相同的字段、很多函数签名中相同的参数。这些总是绑在一起消灭的数据真应当拥有属于它们本人的对象 九、基本类型偏执 用对象代替基本类型，并不是代替单个的基本类型，而是几个基本类型放在一起更有意义时应当使用对象，比如“电话号码”由基本号码，区号，地区等一起来描述时，就组装成对象，比每次都用基本类型字段描述更好。 十、switch 语句 大多数时候，一看到switch语句，你就应当考虑以多态来替换它。问题是多态该消灭在哪儿？switch语句经常依据类型码进行选择，你要的是“与该类型码相关的函数或类”，所 以应当使用Extract Method将switch语句提炼到一个独立函数中，再以Move Method将它搬移到需要多态性的那个类里 假如一个 switch 操作只是执行简约的行为，就没有重构的必要了 十一、平行承继体系 每当为某个类添加一个子类，必需也为另一个类添加一个子类。衰退这种反复性的一般策略是：让一个承继体系的实例引用另一个承继体系的实例。 十二、冗赘类 假如他不干活了，炒掉他吧。把这些不再重要的类里面的规律，合并到相关类，删掉旧的 十三、夸夸奇谈谈将来 我们经常会说：“我想总有一天需要做这事”，并因而企图以各样的钩子和特殊情况来处理一些非必要的事情。假如用不到，就不值得。删掉 比如某个笼统类其实没有太大作用，可以将超类和子类合为一体。将不必要的托付转移到另一个类中，并衰退原先的类。假如函数的某些参数未被用上，那么就将参数移走。假如函数名称带有多余的笼统意味，就应当对它重命名，让它现实一些。简而言之就是删掉 十四、令人迷惑的临时字段 有时候你会发觉：类中的某个实例变量仅为某种特定情况而设。这样的代码让人难以理解，由于你通常认为对象在全部时候都需要它的全部变量。 将这些临时变量集中到一个新类中管理 十五、过度耦合的消息链 有些时候我们在调用某个函数的时候往往会构成A-B-C-D.test(),这个时候假如你在A端，你就产生了Message Chains的坏味道。这种形态使的你客户代码在A中变成getB()-getC()-getD()-test(),这会使得客户代码在以后这些类关系发生变化的时候变得极易修改与相当不稳定。 可以使用隐蔽“托付关系”，并在服务类上建立客户所需要的全部函数来打破这消息链，理论上你可以重构消息链上的任一对象。但这样做往往会让这些小对象都变成Middle Man(两头人)，通常更好的做法是：查看消息链最终对象是用来干什么的，看看能否能用Extract Method把他提炼到一个独立的函数中去，再运用Move Method把这个函数推入消息链， 十六、两头人 大部分都交给中介来处理了。用承继替代托付。 十七、狎昵关系 两个类彼此使用对方的私有的东西。 可以通过“移动方法”和“移动字段”帮它们划清界限，从而削减狎昵行径。假如两个类实在是情投意合，可以把两者共同点提炼到一个平安地点，让它们坦荡地使用这个新类，从而转变从双向依靠A-B,B-A变成A-C,B-C。或者通过隐蔽“托付关系”让另一个类来为它们传递相思情， 十八、异曲同工的类 相像的类，有不同接口? 那么你需要使用Rename Method将这些接口统一到一个名字，然后通过Move Method将某些行为移动到适合的类当中去，重构之后你会发觉他们好像更适合成为兄弟类，以便利你把这个共同函数推到父类当中去，这个时候你可