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

1.1.4 Long Parameter List(过长参数列)

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

问题原因:

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

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

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

解决方法:

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

收获:

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

何时忽略:

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

Refactoring之——代码的坏味道(四)过长参数列的相关文章

Refactoring之——代码的坏味道(二)过大的类 &(三)基本类型偏执

1.1.2 Large Class(过大的类) 特征:一个类包含过多的字段.方法.代码行. 问题原因: 类通常一开始很小,但是随着程序的增长而逐渐膨胀. 类似于过长方法,程序员通常觉得在一个现存类中添加新特性比创建一个新的类要容易. 解决方法: 设计模式中有一条重要原则:职责单一原则.一个类应该只赋予它一个职责.如果它所承担的职责太多,就该考虑为它减减负. 如果过大类中的部分行为可以提炼到一个独立的组件中,可以使用 提炼类(Extract Class). 如果过大类中的部分行为可以用不同方式实现

关于重构(四)--代码的坏味道

代码的坏味道主要有: Duplicated Code---(重复的代码):如果你在两个以上的地点看到相同的程序结构,那可以:设法将它们合二为一,程序会变得更好. Long Method ------(过长函数): 1 private void bindSaleInfo(string swhere) 2 { 3 ArrayList proList = getProductInfo(swhere); 4 string colorStr = ""; 5 StringBuilder rowHt

22种代码的坏味道,一句话概括

22种代码的坏味道,一句话概括: 假设一段代码是不稳定或者有一些潜在问题的,那么代码往往会包括一些明显的痕迹. 正如食物要腐坏之前,常常会发出一些异味一样. 我们管这些痕迹叫做"代码异味". 參考资料: http://blog.csdn.net/sulliy/article/details/6635596 http://sourcemaking.com/refactoring/bad-smells-in-code Code smells Duplicated Code --------

重构笔记——代码的坏味道(上)

在重构入门篇中,简单地介绍了重构的定义.为何重构.何时重构等.我想对于重构是如何运作的,你已经有了较好的理解了.但是对于代码中的坏味道,你可能 知道的并不多.坏味道可能是无形中产生的,也可能是开发人员偷懒造成的,还可能是其它某些因素导致的.不管怎么样,代码中的坏味道对程序没有半点好处,它 会促使程序腐烂,甚至变质.对于开发人员,真的是很有必要对这些坏味道进行了解和熟悉,理解它们产生的场景.针对当前程序,发现坏味道,对代码进行重构, 以消除坏味道,提高代码质量,提高自己水平. 下面让我们一起来熟悉

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

巨型类 当一个类尝试做的太多,它常常展示出过多的实例变量.当一个类有太多实例变量,重复代码的出现就不远了. 你可以提取类来打包一部分变量.选择在部件中有意义的变量放在一起.例如,“存款总量”和“存款货币”很可能在同一部件中.更宽泛的说,在一个类中变量的某个子集共同的前缀和后缀预示着组成同一个部件的机会.如果这个部件有成为子类的意义,你会发现提取子类往往更容易. 有时一个类不会一直使用它全部的实例变量.如果如此,你可能可以提取类或者提取子类若干次. 相比于一个类有太多实例变量,一个类有太多代码是重

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

散弹式修改(Shotgun Surgery) 散弹式修改和发散式变化类似,但却相反.每当你做一种修改你却必须对很多不同的类做很多小的变化,你面临的就是散弹式修改.当变化到处都是时,有的变化就不好找到了,这样很容易漏掉重要的更改. 这种情况下你要使用移动方法(Move Method)和移动字段(Move Field)来把所有的变化放到一个类里.如果没有现成的类合适,就创建一个类.通常你会用到内联化类(Inline Class)把一系列行为放到一起.你会有一点发散式变化的问题,但你可以轻松处理它.

代码的坏味道【4】

返回总目录 十四.Temporary Field(令人迷惑的暂时字段) 1.某个实例变量仅为某种特定的情况而设 2.某些实例字段仅为某个函数的复杂算法少传参数而设 将这些变量和相关函数提炼到一个独立的类中. 十五.Message Chains(过度耦合的消息链) 如果你看到用户向一个对象请求另一个对象,然后再向后者请求另一个对象,然后在请求另一个对象……这就是消息链. 实际代码就是一长串的getThis()或者一长串临时变量. 使用隐藏“委托关系”(这个后面会讲)来进行重构.当然了,可以在消息链

代码的坏味道

代码的坏味道Duplicated Code 重复代码Long Method 过长函数Large Class 过大的类Long Parameter List 过长参数列:类或者结构Divergent Change 发散式变化:一个类受多种变化的影响Shotgun Surgery 霰弹式修改:一种变化引发多个类相应修改.Feature Envy 依恋情结:一个类里的方法对另一个类的数据需求很大,需要移动方法的位置.Data Clumps 数据泥团:总是绑在一起出现的数据真应该拥有它们自己的对象.Pr

重构摘要3_代码的坏味道

如果尿布臭了,就换掉它. 1.Duplicated Code 重复代码 Extract Method Pull Up Method Form Template Method --> Template Method 模式 Substitute Algorithm --> 函数算法替代 2.Long Method 过长的函数 "间接层"所带来的全部利益--解释能力.共享能力.选择能力--都是有小函数支持的. 真正关键在于一个好名字. 每当感觉需要以注释来说明点什么的时候,我们就