Java编程指南(建议).docVIP

Java 编 程 指 南 ——摘自《Thinking in Java 3rd Edition》 设计 优雅终将得到回报。从短期利益来看，要想对问题提出优雅的解决方案，似乎需要投入更多的时间，不过一旦它能够工作，就能够很容易地适应新的环境，而不是要花上数以时计，甚至以天计或以月计的辛苦代价时，这时你将得到回报（尽管没人能够准确衡量这些回报）。你得到的程序不仅易于编写和调试，而且还易于理解和维护，这就是其价值所在。明白这一点需要经验，因为你在精心设计程序的时候生产率不会很高。要抵抗住浮躁心态的诱惑；欲速则不达。 先能运行，再求快速。即使你确信某段代码非常重要，它将成为整个系统的瓶颈，也必须遵守这一点。别着急。先尽可能简化设计，让系统运转起来。如果性能不够理想，再求助于性能分析工具。你几乎总会发现，你“以为的”那些瓶颈，其实都不是真正的问题所在。要把时间用在刀刃上。 谨记“分而治之”原则。如果待解决的问题过于复杂，先设想一下程序的基本操作，并且假定已经有一小段“神奇代码”能够处理最困难的部分。这段“神奇代码”可以看成一个对象，你可以编写程序使用它，然后再回过头来研究这个对象，把它最困难的部分包装成其它对象，依此类推。 区分类的编写者和使用者（客户端程序员）。作为“客户”，类的使用者不需要也不希望知道类的底层工作方式。类的编写者必须是程序设计方面的专家，这样编写出来的类有才可能在新手使用的情况下，仍然能够稳定运行。请把类想象成对其它类的“服务提供者”。程序库只有在内部实现对用户来说是透明的情况下，才会易于使用。 编写类的时候，类的名称要非常清晰，使得注释成为多此一举。你的目标应该是提供给客户端程序员简单明了的接口。为此，在恰当的时候可以考虑方法重载，以得到直观且易于使用的接口。 你的分析和设计所产生的系统中的类、它们的公共接口，以及类之间（尤其是与基类之间）的联系，必须达到最少。如果你在设计中产生了过多的类，请回顾一下，这些代码在程序的整个生命周期中能产生效益吗？如果并非如此，你就要付出维护的代价。对于不能提高生产率的任何东西，开发团队的成员不会自觉地进行维护；这也是许多设计方法无能为力的地方。 尽量让所有东西自动化。首先编写测试代码（在你编写类之前），并把它和要测试的类放在一起。你可以使用某种构建工具，来自动运行测试。你也许会用到Ant，它是Java构建工具的事实标准。这样，只要执行测试程序，所有改动就可以自动获得验证，有了错误也可以立刻发现。因为你信赖测试框架所具有的安全性，所以当你发现新的需求时，会大胆地进行全面修改。请记住，程序语言最大的改进，来自类型检查、异常处理等机制所赋予的内置测试行为。但这些功能只能协助你到达某种程度，其它工作还需要你自己完成。要开发一个健壮的系统，你得自己编写测试用例来验证类或程序的性质。 在编写类之前先编写测试代码，以验证这个类是否设计完备。如果你写不出测试代码，就说明其实你还不清楚类的功能。此外，在编写测试代码的过程中，通常还能够发现类需要具有的额外特性或限制。而这些特性和限制并不总是能够通过分析和设计得到。测试代码也可作为使用类的范例。 所有软件设计中的问题，都可以通过“从概念上引入额外的概念上的间接层次”得到简化。这是软件工程领域的基本原则1，也是抽象的依据。而抽象正是面向对象程序设计的主要性质。在面向对象编程中，我们也可以这么说：“如果代码过于复杂，那么就引入更多的对象。” 引入的间接层次要有意义（与准则 9 相应）。这里所指的意义可以像“将常用代码放入一个方法内”这么简单。如果你加入了无意义的间接层次（通过抽象或封装等等），那就会和没有引入间接层一样糟糕。 尽可能使类原子化。每个类要具有简单明了的用途，用它来向别的类提供服务。如果类或系统设计得过于复杂，请将它分割成几个较简单的类。一个最明显的判断依据就是类的大小：如果类很大，那它很可能负担太重，就应该被分割。 建议重新设计类的线索有： 1) 复杂的 switch 语句：请考虑使用多态。 2) 有许多方法，各自处理类型极为不同的操作：请考虑划分成不同的类。 3） 有许多成员变量，用来表示类型极为不同的属性：请考虑划分成不同的类。 4） 其它建议请参考《Refactoring: Improving the Design of Existing Code》，Martin Fowler著，(Addison-Wesley 1999)。 当心冗长的参数列表。参数列表过长将使得方法调用变得难以编写、阅读和维护。你应该试着将方法放到更合适的类中，并/或使用对象作为参数。 不要一再重复。如果某段代码不断出现于许多派生类方法中，应将该段代码置于基类的某个方法中，然后在派生类方法中进行调用。这样不仅可以减少代码数量，也易于修改。有时候，找出这种通用