这篇文章更加像是一个讨论。

参数

关于参数，首先要说的是参数个数。一般以一两个为佳，超过三个就不太好了。但是很多时候我们都未能完全避免写含有多个参数的方法。解决这种问题的一个技巧是，将这些参数封装成一个对象。不过，若是这个封装的对象没有明显的实际含义，那么还不如继续保持原有的悠长的参数列表，但是最多不要超过七个。
要避免输出参数。输出参数，最为典型的应用应该是Java的servlet。它们大概长这个样子：

    public void service(Request request, Response response){
        ...
    }

response就是一个明显的输出参数。真的要使用输出参数实际上也不会造成多大的问题，它只会造成一些阅读障碍（如果你在使用一个使用输出参数的接口的时候，就要小心一点了，因为你无法知道它究竟会怎样使用你的传入的参数，尤其是在多线程的环境下）。按照Java语言设计的初衷来说，返回值才真正代表输出。
如果你无法确保这个方法只有你自己会使用，或者你也不能确保将来自己使用这个方法的时候会传入正确的参数，那么对方法的参数进行校验。对此我们要秉持这样一种信念，就是使用这个方法的人是一个神经病，谁也不知道他会怎么使用，会使用什么参数。对于参数的校验，有两种常见的校验形式：

    public boolean validated(Parameter p){
        return p==null;
    }

    public void validated(Parameter p){
        if (p==null) {
            throw new IllegalArgumentException();
        }
    }

第二种大概要少见一点，它违背了一般的思维习惯，并且丧失了某种灵活性。而第一种还允许在参数检测不过关之后，做一些补救措施，比如使用默认值。但是，第二种有一种独特的优势，这种优势就是，如果你的确真的想在校验不通过之后抛出异常，那么使用第二种校验方式，你可以少些一点代码。推荐使用第一种而不使用第二种。
这里补充一点，除了参数需要校验以外，任何不受你控制的输入都需要经过校验。比如说读取文件，那么应该对文件内容进行校验。
总结成一句话就是，不要相信任何人，即便你自己也不能相信。

抽象

这里我要先讲一个笑话，将大象装进冰箱分成几步？三步，打开冰箱门，把大象塞进去，关门。这个笑话应该是对于抽象的最准确解释了。
抽象要求一个方法只做一件事。这似乎是一个很容易满足的要求，实则不然。比如说，异常处理究竟算不算是一件事？若是异常处理算是一件事，那么代码应该写成这样：

    public void doSomething(){
        try{

            realDoSomething();

        } catch (ExceptionType1 e){

        } catch (ExceptionType2 e){

        }//...
    }

这样看上去有点愚蠢，但是在异常情况很复杂而且对异常的处理很重要的情况下，会有比较好的效果。
除了这种情况外，还有一些情况也会让人疑惑。比如说，方法的分支。如果一个方法包括几个分支，那么这些分支应该单独出来算是一件事，还是它们组成一件事？这种判断依赖于上下文和调用者，在大多数情况下，应该考虑将分支单独出一个方法，而后如果还却是需要一个综合了分支的方法，那也应该用分支方法来组成。
这就造成了一个问题，该如何判断一个方法是否只做了一件事？
有一种说法是，判断一个方法是否只做了一件事，只需要看方法的名字是否概括了方法的全部效果。这种说法不失为一种合适的判断方法。
更加形式化的说法是，判断一个方法是否只做了一件事只需要看方法的语句是否都处在同一个抽象层级。就如同，打开冰箱，把大象塞进去，关上冰箱门，这三个是处在同一个抽象层级上，而打开冰箱，把大象头塞进去，把大象身体塞进去，关上冰箱门，它们就不是同一个层级。
这样说起来不太容易把握。那么可以考虑一种“反证”思维。这是我在尝试实践TDD的时候领悟的，它有点像是数学上的反证法。它的一般形式可以表达为：

• 如果我要做到某事，我得先做到A，然后做到B...
• 如果我要做到A，我要做A1，然后做A2...
• 如果我要做到B，我要做B1，然后做B2...

这个在代码里面大概是这样的：

    public void doSomething(){
        doA();
        doB();
        doC();
        ...
    }

    private void doA(){
        doA1();
        doA2();
        ...
    }

    private void doB(){
        doB1();
        doB2();
        ...
    }
    ...

这种写代码的方式可以很好的与桩模块的思想结合起来，使细节被延迟到真正需要考虑的地方再实现。比如说，我们在实现doSomething的时候，可以假定doA, doB, doC...已经实现了。这样就屏蔽了很多细节，使我们真正关注在doSomething本身的逻辑上。在完成了doSomething之后，我们会继续往下写doA，而这个时候我们可以假定doA1, doA2已经实现了；写完doA之后，应该继续往下写doA1，而不是写doB，因为，显然从逻辑上doA1和doA在逻辑上联系要紧密。
这样一来，最终一个方法会被扩展成一棵树一般的结构。这就引发了我写方法的另外一个原则：只在叶子节点里面写简单操作。这个原则的极端情况就是，即便是拼接字符串，或者做个简单计算（可能仅仅是a+b*c)，我也会把它写成一个方法。我推荐这种写法，尤其是在这种简单操作有明显的业务含义或者实际意义的时候，一个方法名字要比一堆的算式好理解。

异常

一个方法很重要的部分是异常处理。这里讨论的主要是在何时处理异常。
第一个原则是，公开的接口，或者暴露的方法，只抛出你已经声明了的，或者在javadoc里面指定了的异常。其余的异常应该在内部被处理掉了。这里所讲的处理，可能是将异常重新包装成声明的异常抛出，而要是在获得了足够的信息的情况下，也可以真正的处理掉；
第二个原则是，只有在知道异常该如何处理，那么就处理掉异常。这句话反过来就是说，如果不能有足够的信息处理异常，那么就继续抛出异常。这里面的关键点是，如何判断是否收集够了足够信息。通常来说，调用者肯定知道被调用方法的异常该如何处理，但是如果继续往上抛出异常，那么调用者的调用者就不得不关注更加多的细节了；私有方法异常会保留到公开调用者进行处理，因为公开调用者会有更加多的决策信息用以决定这个异常是否需要被处理掉。这两种建议是会冲突的，在这种情况下，应该按照词典顺序使用建议。这里还有一种比较常见的情况，即多个子方法抛出同一种异常，并且这些异常原因各不相同，业务又需要区别这些异常。这种情况下，是建议在子方法将异常处理掉的，否则，每一个子方法调用语句都被try...catch包起来显得真的太丑了；
第三个原则是，如果一个方法需要返回一个特殊值标记失败，那么就不要用这种返回值，而是改成直接抛出异常。这种返回一个标记失败的值，是延续了C里面的风格，那里并没有异常这种东西，但是Java自身提供了这种机制，一个异常在语义上要比任何值更加能够说清楚失败的含义。
第四个原则是，使用断言而不是异常来表达绝不会出现的情况。当然，如果断言失败了，那么还是会抛出异常……但是在语义上抛出异常代表的是你知道此处可能会出现失败，而断言抛出的异常则说明发生了你绝对没有意料到的情况。断言用在说明前置条件和后置条件下会比较有效果。

总结

写出一个好的方法是一件困难的事情。很多的时候下，要写出一个好的方法，只能依赖于不断的重构才能完成。程序员应该像一个艺术家一样，对于自己的代码精心打磨。