代码诊所的第二次诊断

变量的声明应尽量与使用放在一起

本规则与代码的可读性有关，倘若方法还没有保持短小，这个问题就更要命。或许这是C语言开发者容易犯的毛病。当然也有许多Java程序员从前辈程序员处继承了这一陋习。我曾经在一个遗留项目中看到过一个长达几千行的Java方法，在方法头部堆砌了数十个变量定义，让人目不暇给！

除了影响代码的可读性之外，还可能导致隐藏的缺陷。很多程序员之所以习惯在一开始就声明变量，就是将这种局部变量当做了存储中间状态的容器，在方法内部反复使用该变量，这种中间结果的变迁未必符合开发者意图，又或者后来的代码维护者没有理清这种变化，从而做出变量值的误判。

对常量和枚举的使用

本规则本不足道，写在这里，为了进一步惊醒一下团队成员。在咨询过程中，我看到有这段代码：

Integer.parseInt(freeFlash, 16);

这个16，究竟是什么鬼？Magic Number，很多时候会让人感到困惑。

在JDK没有提供枚举之前，很多Java程序员喜欢使用接口类型来包装一大堆常量。如果常量存在内聚的分类意义，还是使用枚举为佳。

进行合理封装，避免方法调用顺序错误

封装是非常有必要的。有时候，暴露太多的细节会让调用者感到无可适从。

对于TelnetService类，我们需要依序调用connect()、login()、enterUShell()，然后在执行命令后，必须依序执行exitUShell()，disconnect()。这让我想起事务处理，FTP访问等与资源有关的逻辑，都需要在执行逻辑前后包裹一些基础设施的处理逻辑。为了避免在执行命令前后忘记连接或断开telnet，最好能将此过程封装。

这是从调用安全性来考虑。

如果从调用的简洁性考虑，封装亦有必要。当我们需要通过TelnetService发送telnet命令时，为何还需要了解内部的执行逻辑呢？

那么，该如何封装才能两全其美，既满足对执行逻辑顺序的重用，又满足对命令逻辑的扩展？

通常做法是将真正的执行逻辑提取为接口，如Java中Runnable的方式。这其实可以看作Command模式的运用。当然，我更愿意看做是对函数的封装，例如Guva中的tranform()、filter()之类的方法，接受更具有函数气质的Function或者Predicate接口（ 当时，Java 8还未问世呢 ）。

因此，我的做法如下：

public