重读《重构 2》- 改变函数声明

6.5 改变函数声明(Change Function Declaration)

函数是我们将程序拆分成小块的主要方式。函数声明则展现了如何将这些小块组合在一起工作 ——可以说，它们就是软件系统的关节。// 和我们说的函数是软件的骨架一个意思。

对于这些关节而言，最重要的元素当属函数的名字。一个好名字能让我一眼看出函数的用途，而不必查看其实现代码。// 代码要能表达意图。

如何选择正确的参数，没有简单的规则可循。所以我发现掌握改变函数声明重构手法至关重要，这样当我想好代码中应该有哪些关节时，才能使代码随着我的理解而演进。// 参数对于函数要收敛，让函数封装保持最小。

里面提到的“迁移式做法”值得多练习，重构代码的标准做法。

参数的增加和减少，按照业务需求和分解情况来调整；

但类似把参数改为属性，参数在和属性的交换中，有一些最佳实践；

比较有名的一条就是：数组/集合如果要当作属性，则该类有且只能有这一个集合属性。

这样的好处显而易见：

直接操作数组的代码是命令式的，是实现，需要封装成意图；

数组粒度足够大，够成为一个独立类；

该类只封装数组，避免引入过多依赖。

参数中有数组，也可以参考“把参数改为属性”，然后封装成数组类；

这样，函数内的代码无需操作数组细节，代码变得简洁。

另外，参数的调整，如果只是基本类型，或自定义的复合类型，多训练下直觉，靠本能就能搞定；

但这种只做逻辑终端/调用树的叶子节点上有效；

要想发挥更大作用，为骨架/系统的关节动刀，就需要高阶函数/函数参数/函数返回值，同时也需要改变自己的思维模型，以应用这种方法。

参数调整成函数的典型例子就是反应式编程，rx 里的 operators 就都是关节，只不过是技术需求部分的；功能需求部分也可以抽象出业务的关节，这 2 种关节应该是同构的，可以相互参考。

反应式的编程模型/思维模型的依据，我斗胆猜测一下，因为世界的本质是事件，事件的最强耦合就是因果关系，因果关系最适合的表达就是反应式。

还有就是，反应式的表达方式复杂度是小于线性增加的，而其他的表达方式很容易超线性增加。

当然，因为反应式这种表达，说白了就是逻辑清晰；

但要求人人都做到逻辑清晰，也是件很难的事情；

所以，现在各种语言都在发展更简单的表达方式，按照人的直观思维，复杂度增长是常数的。

如各种语言的 async/await。

这有点类似于：

11.5 以查询取代参数(Replace Parameter with Query)

曾用名:以函数取代参数(Replace Parameter with Method)

但功能更强大。