本附录包括了大量有用的发起，辅佐各人举办初级措施设计，并提供了代码编写的一般性指导：
(1) 类名首字母应该大写。字段、要领以及工具（句柄）的首字母应小写。对付所有标识符，个中包括的所有单词都应紧靠在一起，并且大写中间单词的首字母。譬喻：
ThisIsAClassName
thisIsMethodOrFieldName
若在界说中呈现了常数初始化字符，则大写static 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.2小节的“用内部类改造代码”）。
(11) 尽大概细致地加上注释，并用javadoc注释文档语法生本钱身的措施文档。
(12) 制止利用“邪术术字”，这些数字很难与代码很好地共同。如今后需要修改它，无疑会成为一场恶梦，因为基础不知道“100”到底是指“数组巨细”照旧“其他全然差异的对象”。所以，我们应建设一个常数，并为其利用具有说服力的描写性名称，并在整个措施中都回收常数标识符。这样可使措施更易领略以及更易维护。
(13) 涉及构建器和异常的时候，凡是但愿从头扬弃在构建器中捕捉的任何异常——假如它造成了谁人工具的建设失败。这样一来，挪用者就不会觉得谁人工具已正确地建设，从而盲目地继承。
(14) 当客户措施员用落成具今后，若你的类要求举办任何排除事情，可思量将排除代码置于一个精采界说的要领里，回收雷同于cleanup()这样的名字，明晰表白本身的用途。除此以外，可在类内安排一个boolean（布尔）标志，指出工具是否已被排除。在类的finalize()要领里，请确定工具已被排除，并已扬弃了从RuntimeException担任的一个类（假如还没有的话），从而指出一个编程错误。在采纳象这样的方案之前，请确定finalize()可以或许在本身的系统中事情（大概需要挪用System.runFinalizersOnExit(true)，从而确保这一行为）。
#p#分页标题#e#
(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) 如认为本身已举办了精采的阐明、设计可能实施，那么请稍微改换一下思维角度。试试邀请一些外来人士——并不必然是专家，但可以是来自本公司其他部分的人。请他们用完全新鲜的目光考查你的事情，看看是否能找出你一度熟视无睹的问题。采纳这种方法，往往能在最适合修改的阶段找出一些要害性的问题，制止产物刊行后再办理问题而造成的款子及精神方面的损失。
#p#分页标题#e#
(30) 精采的设计能带来最大的回报。简言之，对付一个特定的问题，凡是会花较长的时间才气找到一种最得当的办理方案。但一旦找到了正确的要领，今后的事情就轻松多了，再也不消经验数小时、数天可能数月的疾苦挣扎。我们的尽力事情会带来最大的回报（甚至无可估计）。并且由于本身倾注了大量心血，最终得到一个精彩的设计方案，乐成的快感也是令人心动的。僵持抵抗草草落成的诱惑——那样做往往得不偿失。
(31) 可在Web上找到大量的编程参考资源，甚至包罗大量新闻组、接头组、邮寄列表等。下面这个处所提供了大量有益的链接：
http://www.ulb.ac.be/esp/ip-Links/Java/joodcs/mm-WebBiblio.html
