重构坏味道:过长的参数列

过长的参数列

症状

一个函数拥有大于3个甚至更多的参数,而且调用链上的每个函数可能都需要你传递不同的参数,或者某几个参数看起来就是成对出现,并且拥有不可分开的强耦合关系


过长的参数列

病因

刚开始学习编程的时候,我们总是把函数需要的东西全部以参数的形式传递进去,因为除此之外就只能选择全局数据,而全局数据是个邪恶的东西。
还有一种情况你可能在重构代码的时候,把好几个函数合并成了一个函数,这样就会导致,原来每个函数的参数都会作为你这个新函数的参数存在。

导致的健康问题

虽然参数的独立可以隔离对象之间的依赖,但如果太长的参数列不仅难以理解,太多的参数还会造成前后不一致,不易使用, 一旦你需要更多的数据,就不得不修改它,而且每一层调用都会相应的修改。

治疗

使用对象技术可以改变了这一情况:如果你的函数没有你所需的参数,总可以叫另一个对象给你,有了对象,你就不必把函数需要的所有东西都以参数传递给它了,只需要传给它足够的,让函数能从对象中获得自己需要的东西就就行了。


重构手法
  • 如果向已有的对象发出一条请求,就可以取代一个参数
    尝试运用 Replace Parameter with Method在这里"已有对象"可能是函数所属类内的一个字段 也可能是另一个参数。
    B站实战视频
    尝试运用 Preserve Whole Object 将来自同一个对象的一堆数据收集起来,并以该对象替换它们
    B站实战视频
  • 如果已有对象是单例的,或者无状态的,且某些数据缺乏合理的对象归属
    尝试运用 Introduce Parameter Object 为它们制造出一个参数对象
    B站实战视频

康复

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

重构后

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成,浏览时请结合常识与多方信息审慎甄别。
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

友情链接更多精彩内容