<读书笔记>编写整洁代码3: Function

1. 方法的体积应该小(行数少), 推荐 15 行以内. 抽象层级越高的方法的体积应该越小.
2. 一个具有良好构造的方法应该是: 只做一件事, 做好这一件事, 不影响到其他无关内容.
   这里一件事的定义是什么呢? 可以使用 "TO" 来进行界定. 比如 To render a page with page data. 使用页面数据来渲染该页面, 就是一个只做一件事的例子.
   要考虑这个方法内部对于外部事物的影响, 最好的方法应该是不影响到除了参数以外的事物的, 且有明确的输入和输出.
   另外, 这里"一件事"的意思也可以理解为: 在同一个抽象层级上的某一件事情. 比如一个发动机启动方法, 你不能在里面即指挥齿轮转动, 又指挥发动机输出动力, 因为这两件事情完全就不是在同一个抽象层级上的.
   在实践中, 如果我们不能再对方法进行展开, 则意味着该方法做的事情就是一件事情了.
3. 保证方法内部是在同一个抽象层级. 具体的做法就是:
   保证读方法代码的时候从开始到结束就是一个线性的过程. 而非在不同的抽象层级间跳转.
4. 对于 switch 语句的处理: 因为它本身的缘故, 它的本质就是在 N 件事情中选做若干件. 而处理这样的 switch 的最佳方式就是多态替换或者是字典对照法. 字典对照仅适用于对照的结果为某种值的情况, 更多时候需要的是多态替换的办法. 多态替换的办法是指将 switch 语句隐藏在一个抽象工厂中, 让这个抽象工厂来生产相应的产品从而执行所需的不同功能.
5. 当方法更小, 更简单, 且更专一的时候, 对其命名也会更加容易, 在命名时选择更加具有描述性的词汇. 命名时应先保证名字的意义表达清晰易懂, 再保证不至于过长的命名.
6. 命名时应保证名称的前后一致性, 不论在方法, 函数, 类名或者属性名上, 同一个概念的名称应该一致.
7. 方法参数个数保证在 3 个以内. 保证尽量少的方法参数. 相比无参, 一个参数更好理解. 并且慎用 inout 类型参数. 如果一个方法的参数在 3 个以上, 试想要测试所有的情况, 参数取值情况的组合应该有多少种!
8. 尽量不要传递布尔类型的参数. 因为有布尔参数的存在, 就肯定让这个方法做的事情不止一件.
9. 当参数个数很多时, 最好是组合成一个参数对象进行处理. 因为参数对象的具体状态就是和这些参数的取值相关的, 而测试时实际就是在模拟这些状态.
10. 保证在方法中不要引入副作用(即只做一件事, 除了这件事之外, 不要引起其他改变). 还可以这样理解: 除了这个方法要做的事情能够引起的改变之外, 不要改变其他任何东西.
11. 方法有两大类型的, 一类是 do something, 一类是 answer something(有返回值), 但决不能是身兼两种类型.
12. 对于错误和异常的选择, 当然是选择异常. 因为定义了一个错误的 enum, 则许多的模块都需要依赖这个 enum, 要扩展的话, 修改这个 enum, 就要对所有这些依赖的模块进行重新编译部署, 所以最好的办法是使用异常, 通过异常的继承来添加异常, 这样就避免了要重复编译部署的问题.
13. 绝对不要重复代码, 重复代码都需要抽取出来. 而有时无法对抽取进行命名的时候, 可以添加一个 include, 表示包含什么样的功能.
14. 对于规定: "只有一个输入和一个输出", 在保证较小的方法体的前提下是没有太多实际意义的. 这条规定最好的用处是在大型函数中.

每一个系统都是用一种领域相关的语言进行描述的. 而方法就相当于语言中的动词. 而 class 就是里面的名词. 而实际编程是在描述一个系统, 而非仅仅是"编写程序". 如何简洁地, 正确地描述这个系统的设计, 才是编程的本质.