管理代码里的“方法链”和嵌套调用

代码越写越多，其实好多东西都会是一个积累和反思的过程，在较早前看过一篇文章，是描述有关某第三方包的一些代码特性的问题，就想起来了这个问题，“方法链”（Method Chain），先不说别的，看看下面一段代码：

java 代码

1. public void method(){   
2.     SomeComponent component = new SomeComponent();   
3.     component.setProp1().setProp2().setProp3();   
4. }  

上面的代码演示了一段典型的方法链的支持，某个组件SomeComponent的setProp的方法族都有方法链的特性，我们通常的set方法会定义为：public void setProp(Prop prop); 但是在方法链的支持中，则采用了：public OwnerType setProp(Prop prop);的方式，即set方法族会返回自身的引用，这样就对一组连续的set方法提供了相当的便利，我们不用再一行行地使用对象引用来点出我们的set方法。

从写程序的角度来说，在有代码自动填充支持的IDE环境下，这样的设计将大大提高打字效率，并且这样的方法链将标志处在这个阶段，我们在连续地操作同一个对象。不过，冗长的set方法链，有时候看起来也是个非常头大的东西。比如我们可能对某些set方法有一些必要的注释，这个时候，采用方法链就需要仔细考虑了。

其实，由方法链的调用，衍生想到另外一个问题，就是方法的嵌套调用，还是代码先：

java 代码

1. public void method0(){   
2.     Object o1 = getO1();   
3.     Object o2 = getO2(o1);   
4.     Object o3 = getO3(o2);   
5. }   
6.   
7. public void method1(){   
8.    Object o3 = getO3(getO2(getO1)));   
9. }  

嵌套调用是种很难形容的方式，他会让你的代码行数和本地变量数有极大的削减，但是又会让你的程序的可读性和可调式性变得越来越差。临时变量会申请出额外的存储空间，而方法的嵌套则会导致方法栈的累积，好像从空间效率上都没法做很好的对比。

每个人写代码的风格不同，有些人在方法的命名习惯用一些缩写甚至是无意义的字符，这就让方法本身从名称上感觉难以理解，如果这个时候再大量使用嵌套调用和方法链，那么这段程序将完全不可阅读，同时，我们在调试程序的时候，也只能够把断点设置在嵌套调用的最外层或者方法链的起始端，如果这个时候方法链很长，或者嵌套很深，对调试程序将是一个极大的挑战。

所以说，在一定程度上（方法有良好的命名、嵌套深度不大（3-5层）、方法链长度不长（5-7）），这些简略的代码编写手法都还是可以推荐使用的，不过，过犹不及。