Refactoring之——代码的坏味道过长参数列

Posted 雪山上的蒲公英

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Refactoring之——代码的坏味道过长参数列相关的知识,希望对你有一定的参考价值。

1.1.4 Long Parameter List(过长参数列)

特征:一个方法有超过三四个的参数。

                                   

问题原因:

过长参数列可能是将多个算法并到一个函数中时发生的。函数中的入参可以用来控制最终选用哪个算法去执行。

过长参数列也可能是解耦类之间依赖关系时的副产品。例如,用于创建函数中所需的特定对象的代码已从函数移动到调用函数的代码处,但创建的对象是作为参数传递到函数中。因此,原始类不再知道对象之间的关系,并且依赖性也已经减少。但是如果创建的这些对象,每一个都将需要它自己的参数,这意味着过长参数列。

太长的参数列难以理解,太多参数会造成前后不一致、不易使用,而且一旦需要更多数据,就不得不修改它。

解决方法:

  • 检查什么值被传入参数,如果向已有的对象发出一条请求就可以取代一个参数,那么你应该使用 以函数取代参数(Replace Parameter with Methods) 。在这里,“已有的对象”可能是函数所属类里的一个字段,也可能是另一个参数。
  • 你还可以运用 保持对象完整(Preserve Whole Object) 将来自同一对象的一堆数据收集起来,并以该对象替换它们。
  • 如果某些数据缺乏合理的对象归属,可使用 引入参数对象(Introduce Parameter Object) 为它们制造出一个“参数对象”。

                              

收获:

  • 更易读,更简短的代码。
  • 重构可能会暴露出之前未注意到的重复代码。

何时忽略:

  • 这里有一个重要的例外:有时候你明显不想造成"被调用对象"与"较大对象"间的某种依赖关系。这时候将数据从对象中拆解出来单独作为参数,也很合情理。但是请注意其所引发的代价。如果参数列太长或变化太频繁,就需要重新考虑自己的依赖结构了。

以上是关于Refactoring之——代码的坏味道过长参数列的主要内容,如果未能解决你的问题,请参考以下文章

我的重构识别代码的坏味道

代码的坏味道与重构技术

21种代码的坏“味道”

重构—改善既有代码的设计3——代码的坏味道

如何写优雅的代码

代码的坏味道