《重构2》第十一章-重构API

api是程序前端和后端联动的节点，无序或看似有效的api，会给后来的开发者以及协作人员带来不必要的麻烦！相信有一部分人是认为POST方法万岁，输出的api全是POST请求，且格式统一，在某种意义上，会被认为，只有一种请求，对接起来更为方便。其实并不然，api后续逻辑的增删改查数据，统一放到post请求中，时间一长，你讲不理解每个api淂作用，有人说，我进行语义化api不就可以了，迄今为止，我也依然认为，在开发过程中，给函数起名是个大难题，且占用了我大部分时间！

同时，全是post的请求，但凡api中注释写的不清晰，后续的协同人员将会浪费更多的时间去寻找你的api，甚至，急燥的程序员会自己重新写一个api，而且，这个api跟你之前写的几乎一致。

有些人是为了快速开发，但是，当你的代码出现问题，而其他人找不到你的代码时，你的加班，将更为浪费时间！

以上，是我同意重构api的原因！

1将查询函数和修改函数分离

任何有返回值的函数，都不应该看得到副作用！

将无论怎么查询，返回值都是一样的结果存储在某个缓存中，这样可以为后续的查询大大减少时间；

如果是一个既有返回值又有副作用的函数，可以试着将查询从修改中分离出来，变成可复用的查询；

2.函数参数化

其实本质就是提取类似逻辑的函数，并将其中不同的取值作为参数提取出来，当然，这个修改涉及的函数，需要在修改之后均测试一边，避免考虑不周引起的变量缺失。这个方法使用的时候，建议小步修改，不用一次提取大量函数，导致业务逻辑增多而增加测试难度！

3.移除标记类型

一些标记类型的函数取值，让人不得不去扒拉代码，尤其是，你的函数参数中有一个布尔值时，你讲不知道这个true/false是想执行什么逻辑，那么此时，我们就可以将其需要执行的函数拆分为两个函数，并在函数调用时，将拆分函数作为参数写入源函数中，这样，你就明确的知道，这个值时做什么的！

4.保持对象完整

对于这个优化，我的认识是，为了让代码看起来更加简单，便于理解，从而做出的优化，优化方案有两种，一是将整个对象作为参数，传入函数中；二是进行做我引用，即将几个需要用到的字段赋值到this中，方便当前类的所有函数进行调用。

5.以查询取代参数

此优化方案，有利有弊。

利为：简化了调用方的操作，调用方用了更少的操作、更少的参数完成了功能；

弊为：可能会给函数造成不必要的依赖关系，增加开发者维护成本，此弊端，其实可以用小颗粒度的功能函数来弥补，同时查询函数的结果要具备确定性，即：无论什么时候，我传入固定的值，返回值是相同的。

6.以参数取代查询

与上述方法为反向操作；

作用就是，解除函数依赖，传入参数更加清晰，将责任转移至调用方，迫使，调用方传入的数据必须是合法的，这是降低代码耦合度的代价。好处还有一个，不必担心类中有其他函数会修改你的参数值，因为在此函数中，你的使用时独一无二的，无可动摇的。

7.移除设置函数

这个方法简单的十分理解，就是给你的类创建一个参数，在每次new一个新的对象时，传入该参数，用于动态修改；

8.以工厂函数取代构造函数

简而言之，此方法就是，创建一个工厂函数，用于操作new类动作，用来简化逻辑理解。

9.以命令取代函数

此方法用于拆分复杂的函数逻辑，主要是为了修改对象属性/结果，因此，可以对命令函数以参数传入的方式进行重构，同时，尽可能将所有的局部变量修改为字段，这样便于提炼函数和数据逻辑处理；

10.以函数取代命令

与上述方法为反向操作；

主要是为了优化简单的函数，如果一个函数逻辑可能不超过10行代码或者没有什么可复用性，那么没必要单独写一个类，或者拆分的极细小，过度的追求函数简短，有时会让读写成本增加。