方法的长度

“重构之美”第 3 部分

在一次演讲中，我曾经问过听众这样一个问题：“一个方法的理想行数最多多少行？”如果你问一千个人，可能有一千个答案。

这是一个见仁见智的问题。在《软件开发的沉思》一书中，该公司的技术负责人 Jeff Bay 认为：“一个共同的原则是将方法的行数限制在 5 行……”很多人对此感到不可思议。我虚心地认为，关键不是方法的最大行数，而是对方法的粒度如何让我们受益的合理理解？

Jeff Bay 提倡“利用 IDE 提供的‘提取方法’特性，不断提取方法中的行为方法，直到只有一级缩进。如果方法太长，不可能做到这么清晰可读性。” C.强调：“方法的第一条规则是短。第二条规则是更短。”

短方法更容易理解和重用。毫无疑问。但是，短方法导致方法数量急剧增加，这会干扰阅读吗？另一个担心是，当我们阅读方法时，短方法不可避免地会导致我们在方法之间跳转。

这两个问题，归根结底就是方法命名的问题。只要方法名清楚地表达了它的意图，并且您可以阅读名称，就无需将方法的内部实现追溯到它的底部。钱钟书先生在拒绝仰慕者的时候，委婉地说：“你吃了一个鸡蛋，心情很好，为什么要认识下蛋的母鸡？”如果您已经从方法名称中知道了它的名称，那么阅读代码遵循相同的原则。用心与责任，何苦剖析法体内部？这就是封装的全部意义所在。唯一的例外是当您想学习和深入了解实现的内部机制时。

关于方法间的跳转，目前很多IDE工具都提供了方便跳转的功能。因此，不必担心。

好的代码应该像一篇好的散文，清晰自然。写一篇文章需要专注于一件事，而不是让其他不相关的内容干扰它。如果事情比较困难，你可以仔细考虑一些功能，分而治之。编写可读代码尤其需要注意构成代码的基本元素：方法。虽然在面向对象的设计中，我们应该从对象的角度来思考，但是对于方法，我们仍然可以借鉴面向过程的设计，并且需要明确方法履行职责的过程。就像在脑海中画出方法的流程图，分解过程，用每个方法表示每一步，就可以像散文一样写代码了。

一个常见的做法是，在实现一个main方法的时候，不是先实现具体的代码，而是写一些小方法的名字，也就是先完成main方法的模板框架，然后分别实现组合。小方法为主要方法。这可能看起来很困难，但实际上，如果使用得当，它将使编码变得更容易。它让我们从具体的方法实现中解脱出来，先确定实现功能的过程，再考虑每一步的具体实现。

比如我要实现这样一个方法，就需要通过传入的对象来获取一些信息。执行步骤如下：

1）先获取对象；

2）根据对象收集必要的参数；

3）通过对象和收集到的参数构造一个对象；

4）然后方法，设置到对象；

5）最后将对象存入。

我在写这个方法的时候，并没有实现每个步骤的具体细节，而是将这些步骤具体体现在各种小方法中，最后利用提供的函数快速生成这些方法并实现。

无效（）{

= ();

地图 = s();

= (, );

(,);

}

main方法的代码不超过五行，每一行代码都通过方法名表达了清晰的功能职责。在阅读这样的代码时，如果你不需要知道每个步骤的具体细节，你可以通过阅读 main 方法的实现来了解它的意图，甚至不需要添加额外的注释。

这不是重构，但它与重构的脉络相同。

这种分解方法的另一个好处是它可以帮助我们更清楚地识别职责。当你发现分解后的方法所执行的职责与其所属的类不一致，或者需要暴露给其他类调用时，是重新分配职责的好时机。