《重构-改善既有代码的设计》重构手法(重构API)

文章内容和思路来自《重构-改善既有代码的设计》

1> 将查询函数和修改函数分离：如果某个函数只是提供一个值，没有任何看得到的副作用，那么这是一个很有价值的东西。我可以任意调用这个函数，也可以把调用动作搬到调用函数的其他地方；这种函数的测试也更容易；简而言之，需要操心的事情少多了；任何有返回值的函数都不应该有副作用

      

2> 函数参数化：如果我发现两个函数逻辑非常相似，只有一些字面量值不同，可以将其合并成一个函数，以参数的形式传入不同的值，从而消除重复

      

3> 移除标记参数：标记参数是这样的一种参数：调用者用它来指示被调函数应该执行哪一部分逻辑

      

4> 保持对象完整：如果我看见代码从一个记录结构中导出几个值，然后又把这几个值一起传递给一个函数，我会更愿意把整个记录传给这个函数，在函数体内部导出所需的值

      

5> 以查询取代参数：函数的参数列表应该总结该函数的可变性，标示出函数可能体现出行为差异的主要方式；和任何代码中的语言一样，参数列表应该尽量避免重复，并且参数列表越短越容易理解

      

6> 在浏览函数实现时，我有时会发现一些令人不快的引用关系，例如，引用一个全局变量，或者引用另一个我想要移除的元素；为了解决这些令人不快的引用，我需要将其替换为函数参数，从而将处理引用关系的责任转交给函数的调用者；需要使用本重构的情况大多源于我想要改变代码的依赖关系(为了让目标函数不再依赖于某个元素，我把这个元素的值以参数形式传递给该函数)这里需要注意权衡：如果所有的依赖关系都变成参数会导致参数列表过长，如果作用域之间的共享太多，又会导致函数间依赖过度

      

7> 移除设值函数：如果不希望在对象创建之后此字段还有机会被改变，那就不要为它提供设值函数

      

8> 以工厂函数取代构造函数：构造函数有一些丑陋的局限性，例如，JAVA的构造函数只能返回当前所调用类的实例，也就是说，我无法根据环境或参数信息返回子类实例或代理对象；构造函数的名字是固定的，因此无法使用比默认名字更清晰的函数名；构造函数需要通过特殊的操作符来调用(在很多语言中是new关键字)，所以在要求普通函数的场合就难以使用；工厂函数就不受这些限制

      

9> 以命令取代函数：函数，不管是独立函数，还是以方法形式附着在对象上的函数，是程序设计的基本构造块。不过，将函数封装成自己的对象，有时也是一种有用的方法。这样的对象我称之为“命令对象”，或者简称“命令”。这种对象大多只服务于单一函数，获得对该函数的请求，执行该函数，就是这种对象存在的意义；与普通的函数相比，命令对象提供了更大的控制灵活性和更强的表达能力。除了函数调用本身，命令对象还可以支持附加的操作，例如撤销操作，我可以通过命令对象提供的方法来设置命令的参数值，从而支持更丰富的生命周期管理能力

      

10> 以函数取代命令：命令对象为处理复杂计算提供了强大的机制，借助命令对象，可以轻松地将原本复杂的函数拆解为多个方法，彼此之间通过字段共享状态；拆解后的方法可以分别调用；开始调用之前的数据状态也可以逐步构建。但这种强大是有代价的，大多数时候，我只是想调用一个函数，让它完成自己的工作就好；如果这个函数不是很复杂，那么命令对象就显得没有必要