java编程指南(建议)

《java编程指南(建议)》由会员分享，可在线阅读，更多相关《java编程指南(建议)（10页珍藏版）》请在金锄头文库上搜索。

1、Java 编程指南1/10JavaJava 编编 程程 指指 南南摘自摘自Thinking in Java 3rd Edition设计设计1.1. 优雅终将得到回报。优雅终将得到回报。从短期利益来看，要想对问题提出优雅的解决方案，似乎需要投入更多的时间，不过一旦它能够工作，就能够很容易地适应新的环境，而不是要花上数以时计，甚至以天计或以月计的辛苦代价时，这时你将得到回报（尽管没人能够准确衡量这些回报） 。你得到的程序不仅易于编写和调试，而且还易于理解和维护，这就是其价值所在。明白这一点需要经验，因为你在精心设计程序的时候生产率不会很高。要抵抗住浮躁心态的诱惑；欲速则不达。2.2. 先能运行，再

2、求快速。先能运行，再求快速。即使你确信某段代码非常重要，它将成为整个系统的瓶颈，也必须遵守这一点。别着急。先尽可能简化设计，让系统运转起来。如果性能不够理想，再求助于性能分析工具。你几乎总会发现，你“以为的”那些瓶颈，其实都不是真正的问题所在。要把时间用在刀刃上。3.3. 谨记谨记“分而治之分而治之”原则。原则。如果待解决的问题过于复杂，先设想一下程序的基本操作，并且假定已经有一小段“神奇代码”能够处理最困难的部分。这段“神奇代码”可以看成一个对象，你可以编写程序使用它，然后再回过头来研究这个对象，把它最困难的部分包装成其它对象，依此类推。4.4. 区分类的编写者和使用者（客户端程序员）区分类

3、的编写者和使用者（客户端程序员） 。作为“客户” ，类的使用者不需要也不希望知道类的底层工作方式。类的编写者必须是程序设计方面的专家，这样编写出来的类有才可能在新手使用的情况下，仍然能够稳定运行。请把类想象成对其它类的“服务提供者” 。程序库只有在内部实现对用户来说是透明的情况下，才会易于使用。5.5. 编写类的时候，类的名称要非常清晰，使得注释成为多此一举。编写类的时候，类的名称要非常清晰，使得注释成为多此一举。你的目标应该是提供给客户端程序员简单明了的接口。为此，在恰当的时候可以考虑方法重载，以得到直观且易于使用的接口。6.6. 你的分析和设计所产生的系统中的类、它们的公共接口，以及类之间

4、（尤其是与基你的分析和设计所产生的系统中的类、它们的公共接口，以及类之间（尤其是与基Java 编程指南2/10类之间）的联系，必须达到最少。类之间）的联系，必须达到最少。如果你在设计中产生了过多的类，请回顾一下，这些代码在程序的整个生命周期中能产生效益吗？如果并非如此，你就要付出维护的代价。对于不能提高生产率的任何东西，开发团队的成员不会自觉地进行维护；这也是许多设计方法无能为力的地方。7.7. 尽量让所有东西自动化。尽量让所有东西自动化。首先编写测试代码（在你编写类之前） ，并把它和要测试的类放在一起。你可以使用某种构建工具，来自动运行测试。你也许会用到 Ant，它是 Java 构建工具的事

5、实标准。这样，只要执行测试程序，所有改动就可以自动获得验证，有了错误也可以立刻发现。因为你信赖测试框架所具有的安全性，所以当你发现新的需求时，会大胆地进行全面修改。请记住，程序语言最大的改进，来自类型检查、异常处理等机制所赋予的内置测试行为。但这些功能只能协助你到达某种程度，其它工作还需要你自己完成。要开发一个健壮的系统，你得自己编写测试用例来验证类或程序的性质。8.8. 在编写类之前先编写测试代码，以验证这个类是否设计完备。在编写类之前先编写测试代码，以验证这个类是否设计完备。如果你写不出测试代码，就说明其实你还不清楚类的功能。此外，在编写测试代码的过程中，通常还能够发现类需要具有的额外特性

6、或限制。而这些特性和限制并不总是能够通过分析和设计得到。测试代码也可作为使用类的范例。9.9. 所有软件设计中的问题，都可以通过所有软件设计中的问题，都可以通过“从概念上引入额外的概念上的间接层次从概念上引入额外的概念上的间接层次”得得到简化。到简化。这是软件工程领域的基本原则 1，也是抽象的依据。而抽象正是面向对象程序设计的主要性质。在面向对象编程中，我们也可以这么说：“如果代码过于复杂，那么就引入更多的对象。 ”10.10.引入的间接层次要有意义（与准则引入的间接层次要有意义（与准则 9 相应）相应） 。这里所指的意义可以像“将常用代码放入一个方法内”这么简单。如果你加入了无意义的间接层次

7、（通过抽象或封装等等） ，那就会和没有引入间接层一样糟糕。11.11.尽可能使类原子化。尽可能使类原子化。每个类要具有简单明了的用途，用它来向别的类提供服务。如果类或系统设计得过于复杂，请将它分割成几个较简单的类。一个最明显的判断依据就是类的大小：如果类很大，那它很可能负担太重，就应该被分割。 建议重新设计类的线索有： 1) 复杂的 switch 语句：请考虑使用多态。 2) 有许多方法，各自处理类型极为不同的操作：请考虑划分成不同的类。3） 有许多成员变量，用来表示类型极为不同的属性：请考虑划分成不同的类。4） 其它建议请参考Refactoring: Improving the Design

8、 of Existing Code ，Martin Fowler 著，(Addison-Wesley 1999)。Java 编程指南3/1012.12.当心冗长的参数列表。当心冗长的参数列表。参数列表过长将使得方法调用变得难以编写、阅读和维护。你应该试着将方法放到更合适的类中，并/或使用对象作为参数。13.13.不要一再重复。不要一再重复。如果某段代码不断出现于许多派生类方法中，应将该段代码置于基类的某个方法中，然后在派生类方法中进行调用。这样不仅可以减少代码数量，也易于修改。有时候，找出这种通用代码还可以为接口增加实用的功能。在不牵涉继承的情况下，也可能会遇到这种情况：如果类中的几个方法使用

9、了重复的代码，请把这些代码移到某个方法里，然后在别的方法中进行调用。14.14.小心小心 switch 语句或嵌套的语句或嵌套的 if-else 语句。语句。这通常预示着“以编程方式判断类型”的代码，也就是说究竟会执行哪一段程序代码，将依据某种类型信息来判断（开始的时候，可能不清楚确切的类型） 。通常可以使用继承和多态机制来替代此类代码；多态方法在调用时会自动进行类型检查，这样更可靠，扩展起来也更容易。15.15.从设计观点来看，要找出变动的因素，并使它和不变的因素分离。从设计观点来看，要找出变动的因素，并使它和不变的因素分离。也就是说，找出系统中可能会改变的元素，将它们封装于类中，这样就不会

10、被迫重新设计系统。你可以在Thinking in Patterns（with Java） （从 www.BruceE 下载）学习到大量的此类技术。16.16.不要依靠子类化来扩展基础功能。不要依靠子类化来扩展基础功能。如果类接口中的某个元素非常重要，那么它应该被放进基类，而不是在继承时添加。如果你依靠派生来添加方法，也许你应该重新考虑整个设计。17.17.更少意味着更多。更少意味着更多。从类的最小接口开始，尽量在能够解决问题的前提下让它保持简单明了。先别急着考虑类被使用的所有方式。一旦它被实际使用，你自然会明白该如何扩展接口。不过，一旦类被使用后，你就不能在不影响用户代码的情况下缩减接口。不过

11、加入更多方法倒没什么问题，这不会对用户代码造成影响，它们只需重新编译即可。即使用新方法取代了旧方法的功能，也请你保留原有接口（如果你愿意的话，可以在底层实现中将功能进行合并） 。如果你要通过“加入更多参数”来扩充原有接口，可以用新参数写一个重载的方法；这样，就不会影响对原有方法的调用。18.18.大声朗读你的类，确保它们符合逻辑。大声朗读你的类，确保它们符合逻辑。使得基类和派生类之间保持“是一个” （is-a）的关系，让类和成员对象之间保持“有一个” （has-a）的关系。19.19.在判断应该使用继承还是组合的时候，考虑一下是否需要向上转型成基础类型。在判断应该使用继承还是组合的时候，考虑一

12、下是否需要向上转型成基础类型。如果不需要，请优先考虑组合（也就是使用成员对象） 。这样可以消除对多个基类的需求。如果你采用继承，用户会假定它们可以被向上转型。Java 编程指南4/1020.20.采用字段来表示数值的变化，使用方法重载来表示行为的变化。采用字段来表示数值的变化，使用方法重载来表示行为的变化。也就是说，如果你发现某个类中含有一些状态变量，而类的方法会根据这些状态变量表现出不同的行为，那么或许你就应该重新设计，在子类和方法的重载中表达这种行为上的差异。21.21.小心重载。小心重载。方法不应该把参数值作为执行代码的条件。在这种情况下，你应该编写两个或多个重载方法作为替代。22.22

13、.使用异常体系使用异常体系最好是从最好是从 Java 标准异常体系中派生出特定的异常类。标准异常体系中派生出特定的异常类。这样，处理异常的用户便可以在捕获基本异常之后，编写处理程序来捕获指定的异常。即使你派生了新的异常类，以前的客户端代码仍然能通过基础类型来捕获这个异常。23.23.有时候仅仅使用聚合就能完成工作。有时候仅仅使用聚合就能完成工作。比如飞机上的“旅客舒适系统” ，它包括若干分离的部件：座椅、空调、视频设备等等，你需要在飞机对象上产生许多这样的部件。需要把它们声明为私有成员，然后构建一个全新的接口吗？不，在这种情况下，这些部件也属于公共接口的一部份，所以你应该加入的是公有成员对象。

14、这些对象具有各自的实现，所以仍然是安全的。注意，仅仅使用聚合并不是常用的解决方案，但有时候的确能解决问题。24.24.从客户端程序员和程序维护者的角度进行思考。从客户端程序员和程序维护者的角度进行思考。你设计的类要尽可能地易于使用。在设计类的时候，你应该预先考虑可能的变化，并使这些变化以后可以轻易完成。25.25.当心当心“巨型对象综合症巨型对象综合症” 。习惯于过程式程序设计的程序员，在刚接触面向对象程序设计领域的时候，往往会遇到这样的问题。因为他们最终还是习惯于编写过程式程序，并将它们放进一个或几个巨型对象中。注意，除了应用程序框架之外，对象应该代表程序中的概念，而不是程序本身。26.26

15、.如果你只能采用某种别扭的方式才能实现某个功能，请将这个部份局限在某个类内如果你只能采用某种别扭的方式才能实现某个功能，请将这个部份局限在某个类内部。部。27.27.如果你只能采用某种不可移植的方式才能实现某个功能，请将其抽象成服务，并局如果你只能采用某种不可移植的方式才能实现某个功能，请将其抽象成服务，并局限在某个类内部。限在某个类内部。这样一个附加的间接层次，就可以防止不可移植的部份扩散到程序的其它部分。这个惯用法的一个具体应用就是 Bridge 设计模式。28.28.对象不应仅仅用来持有数据。对象不应仅仅用来持有数据。它还应该具有精心定义的行为。在某些情况下使用“数据对象”是恰当的，但只

16、有在通用容器不适用时，才会刻意使用数据对象来包装、传输大批数据项。29.29.在原有类的基础上编写新类时，首先考虑组合。在原有类的基础上编写新类时，首先考虑组合。只在必要情况下才使用继承。如果在可以使用组合的地方仍然选择了继承，就会为设计引入不必要的复杂度。Java 编程指南5/1030.30.使用继承和方法重载来表达行为上的差异，使用字段来表示状态的变化。使用继承和方法重载来表达行为上的差异，使用字段来表示状态的变化。一个要不得的极端例子，就是派生出不同的类来表示不同颜色，而不是用一个 color 字段来表示颜色。31.31.当心当心“变异性变异性” （variance） 。语意不同的两个对象可能会拥有相同的动作（或者职责） 。这里自然而然会产生一种诱惑：仅仅为了从继承中获得某些好处，就让其中一个类成为另一个类的子类。这就是所谓“变异性” ，即在没有任何正当理由的情况下，人为地制造出一个其实并不存在的超类/子类关系。一个较好的解决办法是写一个共用的基类，把两个类都作为它的派生类，这样它们将共享同