(1) 类名首字母应大写。首字母应小写字段、方法和对象(句柄)。对于所有的标识符，包含的所有单词都应该紧密地放在一起，并大写中间单词的首字母。例如： ThisIsAClassName thisIsMethodOrFieldName 如果常数初始化字符出现在定义中，则大写staticc final基本类型标识符中的所有字母。这样，它们属于编译期的常数就可以标记出来。 Java包(Package)这是一种特殊情况：它们都是小写字母，即使是中间的单词。com等域名扩展名称，org，net或edu都应该小写(这也是Java) 1.1和Java 1.2的区别之一)。
(2) 为常规用途创建一个类时，请采用“经典形式”，并对以下元素进行定义： equals() hashCode() toString() clone()(implement Cloneable) implement Serializable
(3) 为自己创造的每一个类别，考虑将一个main()放入其中，包含用于测试该类别的代码。我们不需要删除测试代码来使用项目中的类别。为了使用项目中的类别，我们不需要删除测试代码。任何形式的更改都可以很容易地返回测试。这些代码也可以作为如何使用类别的例子。 (4) 该方法应设计成一个简单的、功能性的单元，并用它来描述和实现不连续的类接口部分。理想情况下，方法要简明扼要。如果长度很大，可以考虑以某种方式将其分为短的方法。类内代码的重复使用也很方便(有时候，方法必须很大，但它们仍然应该只做同样的事情)。
(5) 在设计一个类别时，请设身处地为客户程序员考虑(类别的使用方法应该非常明确)。然后，设身处地为管理代码的人着想(预计可能会修改哪些形式，以及使用哪些方法使其更容易)。
(6) 尽可能短小精悍，只解决一个特定的问题。以下是对类别设计的一些建议： ■复杂的开关语句：考虑采用“多形”机制 ■大量的方法涉及到类型差异很大的操作:考虑使用几个类别来实现 ■许多成员变量在特征上有很大的差异：考虑使用几个类别
(7) 让一切都尽可能“私有”——private。可以使库的某一部分“公开化”(一种方法、类别或一个字段等)。)，永远不能拿出来。如果强行取出，可能会破坏他人现有的代码，使他们不得不重新编写和设计。如果你只宣布你必须宣布什么，你可以放心和大胆地改变任何其他事情。隐私是多线程环境中特别重要的因素——只有private字段才能在不同步使用的情况下得到保护。
(8) 警惕“巨大对象综合征”。对于一些习惯于顺序编程思维并首次涉足OOP领域的新手来说，他们通常喜欢先写一个顺序执行程序，然后嵌入一个或两个巨大的对象。根据编程原理，对象应该表达应用程序的概念，而不是应用程序本身。
(9) 如果要做一些不雅观的编程，至少要把那些代码放在一个类的内部。
(10) 任何时候，只要发现类与类的结合非常紧密，就需要考虑是否采用内部类来改进编码和维护(见第14章14.1.“用内部类改进代码”二节。
(11) 尽可能详细地添加注释，并用javadoc注释文档语法生成自己的程序文档。
(12) 避免使用“魔术数字”，这些数字很难与代码很好地匹配。如果以后需要修改，无疑会成为噩梦，因为我不知道“100”是指“数组大小”还是“其他完全不同的东西”。因此，我们应该创建一个常数，并使用一个令人信服的描述性名称，并在整个过程中使用常数标识符。这使得程序更容易理解和维护。
(13) 当涉及到构建器和异常时，它通常希望重新丢弃在构建器中捕获的任何异常——如果它导致对象的创建失败。通过这种方式，调用者不会认为对象已经正确创建，从而盲目地继续。
(14) 当客户程序员使用对象时，如果您的类需要任何清除工作，您可以考虑将清除代码放置在一个很好的定义方法中，并使用类似于cleanup()的名称来清楚地显示您的用途。此外，bolean(布尔)标记可以放置在类中，指出对象是否已被清除。在finalize()方法中，请确定对象已被删除，并丢弃了从runtimeException继承的类别(如果没有)，以指出编程错误。在采用这样的方案之前，请确保finalize()能够在自己的系统中工作(可能需要调用system.runFinalizersOnExit(true)，以确保这种行为)。
(15) 在特定的作用域内，如果必须清除一个对象(非垃圾收集机制处理)，请采用以下方法:初始化对象;如果成功，立即进入含有finally从句的try块，开始清除工作。
(16) 如果在初始化过程中需要覆盖(取消)finalize()请记得调用super.finalize()(如果Object属于我们的直接超类，则无需)。覆盖finalize()的过程中，super.finalize()调用应属于最后一个行动，而不是第一个行动，以确保它们在需要基本部件时仍然有效。
(17) 创建固定大小的对象集合时，请将其传输到一个数组(如果您准备从一种方法中返回该集合，则应进行此操作)。这样，我们就可以在编译期间享受数组类型检查的好处。此外，为了使用它们，数组的接收者可能不需要在数组中“建模”对象。
(18) 尽量使用interfaces，而不是abstract。如果你已经知道某样东西准备成为一个基本类别，那么第一个选择应该是把它变成一个interface(接口)。只有在必须使用方法定义或成员变量时，才需要将其变成abstract(抽象)类。界面主要描述客户想做什么，而一类则致力于(或允许)具体的实施细节。
(19) 在构建器内部，只有将对象设置为正确状态所需的工作。尽量避免调用其他方法，因为这些方法可能被其他方法覆盖或取消，从而在施工过程中产生不可预测的结果(见第7章的详细说明)。
(20) 对象不应简单地容纳一些数据;它们的行为也应该被很好地定义。
(21) 在现成类的基础上创建新类时，请先选择“新建”或“创造”。只有在必须继承自己的设计要求时，才能考虑到这个问题。如果在原允许的新场合使用继承，整个设计将变得不必要和复杂。
(22) 行为之间的差异是通过继承和方法覆盖来表示的，状态之间的差异是通过字段来表示的。一个非常极端的例子是通过对不同类型的继承来表示颜色，这是绝对应该避免的：应该直接使用“颜色”字段。
(23) 为了避免编程中的麻烦，请确保每个名字只对应一个类别，在您自己的路径指示的任何地方。否则，编译器可能会首先找到另一个同名的类别，并报告错误的消息。如果您怀疑您遇到了类路径问题，请尝试类路径的每个起点，搜索同名.class文件。
(24) 在Java 1.1 在AWT中使用事件“适配器”时，特别容易遇到陷阱。如果适配器方法被覆盖，拼写方法没有特别注意，最终的结果是添加新的方法，而不是现成的方法。然而，由于这是完全合法的，编译器或运行期系统不会得到任何错误提示——但代码的工作变得异常。 (25) 以合理的设计方案消除“伪功能”。也就是说，如果你只需要创建一个类别的对象，不要提前限制你使用应用程序，并添加一个“只生成其中一个”的注释。请考虑将其封装成“独生子女”。如果主程序中有大量分散的代码来创建自己的对象，请考虑采用创造性的方案来包装一些代码。
(26) 警惕“分析瘫痪”。请记住，无论如何，在考察细节之前，都要提前了解整个项目的情况。通过把握全局，可以快速了解自己的一些未知因素，防止在考察细节时陷入“死逻辑”。
(27) 警惕“过早优化”。首先，让它运行起来，然后考虑变得更快——但只有当你必须这样做，并且在某些代码中确实有性能瓶颈时，你才应该优化它。除非用专门的工具分析瓶颈，否则很可能会浪费时间。性能提升的隐含成本是自己的代码变得难以理解，难以维护。
(28) 请记住，阅读代码的时间比写代码的时间多得多。清晰的设计可以获得易于理解的程序，但注释、详细的解释和一些例子往往具有不可估量的价值。它们对你自己和以后的人都很重要。如果您仍然怀疑这一点，请想象您在从在线Java文档中找到有用信息时遇到的挫折，这可能会说服您。
(29) 如果你认为自己做了很好的分析、设计或实施，请稍微改变一下你的思维观点。试着邀请一些外人——不一定是专家，但可以是公司其他部门的人。请用完全新鲜的眼光来检查你的工作，看看你是否能发现你曾经视而不见的问题。这样，在最适合修改的阶段，往往可以发现一些关键问题，避免产品发布后解决问题造成的金钱和精力损失。
(30) 好的设计能带来最大的回报。总之，找到最合适的解决方案通常需要很长时间才能解决一个特定的问题。但是一旦找到了正确的方法，以后的工作就轻松多了，再也不用经历几个小时、几天或者几个月的痛苦挣扎了。我们的努力会带来最大的回报(甚至是不可估量的)。而且因为自己付出了很多努力，最终得到了一个优秀的设计方案，成功的乐趣也令人兴奋。坚持抵制草草完成的诱惑——那样做往往得不偿失
湘公网安备43019002002060