JAVA代码编写的30条建议

Java代码编写的30条建议
(1)类名首字母要大写。字段、方法和对象(句柄)的首字母应该小写。对于所有标识符，其中包含的所有单词应该靠在一起，中间单词的第一个字母应该大写。例如:
thissisclassname
thismethodefieldname
如果定义中出现了常量初始化字符，请将静态final基本类型标识符中的所有字母大写。这将把它们标记为编译时常数。
Java包是个特例:都是小写字母，甚至是中间的单词。对于域名扩展名，比如com、org、net或者edu，都要小写(这也是Java 1.1和Java 1.2的区别之一)。

(2)创建通用类时，请采用“经典形式”并包括以下元素的定义:

equals()
hashCode()
toString()
clone()(实现可克隆的)
实现可序列化的

(3)对于您创建的每个类，考虑放入一个main()，它包含测试该类的代码。为了在项目中使用一个类，我们不需要删除测试代码。如果进行了任何更改，可以方便地返回到测试。这些代码也可以用作如何使用类的示例。

(4)方法应该设计成一个简洁的功能单元，可以用来描述和实现一个不连续的类接口。理想情况下，方法应该简明扼要。如果长度很大，可以用某种方式分成几个更短的方法。这也有助于类中代码的重用(有时，方法必须非常大，但它们仍然应该只做同样的事情)。

(5)设计类的时候，请设身处地为客户程序员着想(类的用法要非常清楚)。然后，把你自己放在管理代码的人的位置上(什么样的变化是可预期的，并且考虑使它们更简单的方法)。
(6)把课讲得尽可能短而精，只解决一个具体问题。下面是对类设计的一些建议:
■一个复杂的switch语句:考虑采用“多态”机制
■众多的方法涉及到类型极其不同的操作:考虑用几个类来实现
■很多成员变量的特性差异很大:考虑用几个类。

(7)让一切尽可能“私密”——私密。如果你能使库的一部分成为“公共的”(一个方法、类或字段等)。)，永远都拿不出来。如果强行推出，可能会破坏其他人已有的代码，让他们不得不重新编写和设计。如果你只发表你必须发表的东西，你可以放心地改变其他任何东西。在多线程环境中，隐私是一个特别重要的因素——只有私有字段在异步使用时才能得到保护。

(8)我想提醒你“巨型物体综合症”。对于一些习惯了顺序编程思维，又是OOP新手的新手来说，往往喜欢先写一个顺序程序，然后嵌入到一两个巨大的对象中。根据编程原则，对象应该表达应用程序的概念，而不是应用程序本身。

(9)如果你不得不做一些难看的编程，你至少应该把那些代码放在一个类里面。

(10)每当发现类与类紧密结合时，就要考虑是否采用内部类，以改进编码和维护(见第14章14.1.2小节“用内部类改进代码”)。

(11)尽可能仔细地添加注释，使用javadoc注释文档语法生成自己的程序文档。

(12)避免使用“幻数”，幻数很难很好地匹配代码。如果以后需要修改，无疑会成为一场噩梦，因为你根本不知道“100”指的是“数组大小”还是“完全不同的东西”。因此，我们应该创建一个常数，为它使用一个有说服力的描述性名称，并在整个程序中采用一个常数标识符。这将使程序更容易理解和维护。

(13)当涉及到构建器和异常时，通常希望丢弃在构建器中捕获的任何异常——如果它导致该对象的创建失败。这样调用者就不会认为对象创建正确，盲目继续。

(14)当客户端程序员用完对象时，如果您的类需要任何清理工作，请考虑将清理代码放在一个定义良好的方法中，使用类似cleanup()的名称来清楚地表明其目的。此外，您可以在类中放置一个布尔标记来指示对象是否已被清除。在类的finalize()方法中，请确保对象已被清除，并且从RuntimeException继承的类已被丢弃(如果尚未丢弃)，从而指出编程错误。在采用这样的方案之前，请确保finalize()可以在自己的系统中工作(您可能需要调用system . runfinalizersonnexit(true)来确保这种行为)。

(15)在特定的范围内，如果一个对象必须被清除(不通过垃圾收集机制处理)，请采用以下方法:初始化该对象；如果成功，立即进入带有finally子句的try块，开始清理工作。

(16)如果在初始化过程中需要覆盖(取消)finalize()，请记得调用super.finalize()(如果对象属于我们的直接超类，则不需要)。在重写finalize()的过程中，对super.finalize()的调用应该是最后一个动作，而不是第一个动作，这样才能保证基本类组件在需要的时候仍然有效。

(17)当创建一组固定大小的对象时，请将它们转移到一个数组中(尤其是当你打算从一个方法中返回这个集合时)。通过这种方式，我们可以享受编译时数组类型检查的好处。此外，为了使用它们，阵列的接收器可能不需要将对象“整形”到阵列中。

(18)尽量用接口代替抽象类。如果已知某个东西是一个基类，那么第一选择应该是使它成为一个接口。只有当你必须使用方法定义或成员变量时，你才需要把它们变成一个抽象类。接口主要描述客户想要做什么，而一个类专用于(或者允许)特定的实现细节。

(19)在生成器中，只完成将对象设置为正确状态所需的工作。尽可能避免调用其他方法，因为那些方法可能会被其他人覆盖或取消，导致构建过程中出现不可预知的结果(详细说明见第7章)。

(20)对象不应该简单地保存一些数据；他们的行为也应该被很好地定义。

(21)在现有类别的基础上创建新类别时，请先选择“新建”或“创建”。只有当你自己的设计需求必须继承的时候，你才应该考虑这方面。如果在允许新构造的情况下使用继承，整个设计将变得不必要的复杂。

(22)行为之间的差异用继承和方法覆盖来表示，状态之间的差异用字段来表示。一个非常极端的例子是通过继承不同的类来表示颜色，这是绝对应该避免的:应该直接使用一个“颜色”字段。

(23)为了避免编程中的麻烦，请确保无论你的类路径指向哪里，每个名字都只对应一个类。否则，编译器可能会先找到另一个同名的类，并报告一条错误消息。如果您怀疑遇到了类路径问题，请尝试搜索。类路径的每个起始点都有相同名称的类文件。

(24)在Java 1.1 AWT中使用事件“adapter”时，特别容易遇到陷阱。如果一个适配器方法被覆盖，而拼写方法并不特别特别，那么最终的结果就是添加一个新方法，而不是覆盖现有的方法。然而，因为这是完全合法的，所以你不会从编译器或运行时系统得到任何错误提示——只是代码不能正常工作而已。

(25)用合理的设计方案消除“伪功能”。也就是说，如果你只需要创建类的一个对象，不要提前限制自己使用应用，加一个“只生成其中一个”的注释。请考虑将其封装为“独生子女”。如果主程序中有大量零散的代码来创建自己的对象，请考虑采用一种创造性的方案来封装这些代码。

(26)谨防“分析麻痹”。记住，不管怎样，都要提前了解整个项目的状态，然后再去考察细节。通过对全局的把握，可以快速知道一些未知因素，防止自己在考察细节时陷入“死逻辑”。

(27)谨防“过早优化”。让它先运行，然后让它更快——但只有当你不得不这么做，并且证明代码的某个部分存在性能瓶颈时，你才应该优化它。除非你使用特殊的工具来分析瓶颈，否则你很可能是在浪费时间。性能提高的隐含代价是您自己的代码变得难以理解和维护。

(28)请记住，你花在阅读代码上的时间比写代码的时间多得多。清晰的设计可以得到易于理解的程序，但笔记、详细的解释和一些例子往往是非常宝贵的。他们对你和以后的其他人都很重要。如果你对此仍有疑虑，请想象一下你在试图从在线Java文档中寻找有用信息时的挫败感，这可能会说服你。

(29)如果你认为你做了一个很好的分析、设计或实现，请稍微改变一下你的思考角度。试着邀请一些外人——不一定是专家，可以是我们公司其他部门的人。请用完全新鲜的眼光来看待你的工作，看看你能否发现那些你曾经视而不见的问题。这样往往可以在最适合修改的阶段发现一些关键问题，避免产品发布后解决问题造成的金钱和精力的损失。

(30)好的设计能带来的回报。简而言之，通常需要很长时间才能找到一个特定问题的最合适的解决方案。但是一旦找到了正确的方法，以后的工作就会轻松很多，不用纠结几个小时，几天，几个月。我们努力工作的回报甚至是不可估量的。而且由于我的努力，最终得到了一个优秀的设计方案，成功的快感也是令人兴奋的。抵制匆忙完成的诱惑——这样做通常不值得