terface(接口) 。只有在不得不使用方法定义或者成员 变量的时候,才需要将其变成一个 abstract(抽象)类。接口
主要描述了客户希望做什么事情,而一个类则致力于(或允 许)具体的实施细节。
(19) 在构建器内部, 只进行那些将对象设为正确状态所需 的工作。尽可能地避免调用其他方法,因为那些方法可能被 其他人覆盖或取消,从而在构建过程中产生不可预知的结果 (参见第 7 章的详细说明) 。 (20) 对象不应只是简单地容纳一些数据; 它们的行为也应 得到良好的定义。 (21) 在现成类的基础上创建新类时,请首先选择“新建” 或“创作” 。只有自己的设计要求必须继承时,才应考虑这方 面的
问题。若在本来允许新建的场合使用了继承,则整个设 计会变得没有必要地复杂。 (22) 用继承及方法覆盖来表示行为间的差异, 而用字段表 示状态间的区别。一个非常极端的例子是通过对不同类的继 承来表示颜色,这是绝对应该避免的:应直接使用一个“颜 色”字段。 (23) 为避免编程时遇到麻烦, 请保证在自己类路径指到的 任何地方,每个名字都仅对应一个类。否则,编译器可能先 找到同名的另一个类,并
报告出错消息。若怀疑自己碰到了 类路径问题,请试试在类路径的每一个起点,
搜索一下同名 的.class 文件。 (24) 在 Java 1.1 AWT 中使用事件“适配器”时,特别容易 碰到一个陷阱。若覆盖了某个适配器方法,同时拼写方法没 有特别讲究,最后的结果就是新添加一个方法,而不是覆盖
现成方法。然而,由于这样做是完全合法的,所以不会从编 译器或运行期
系统获得任何出错提示——只不过代码的工作 就变得不正常了。 (25) 用合理的设计
方案消除“伪功能” 。也就是说,假若 只需要创建类的一个对象,就不要提前限制自己使用应用程 序,并加上一条“只生成其中一个”注释。请考虑将其封装 成一个“独生子”的形式。若在主程序里有大量散乱的代码, 用于创建自己的对象,请考虑采纳一种创造性的方案,将些 代码封装起来。 (26) 警惕“分析瘫痪” 。请记住,无论如何都要提前了解 整个项目的状况,再去考察其中的细节。由于把握了全局, 可快速认识自己未知的一些因素,防止在考察细节的时候陷 入“死逻辑”中。 (27) 警惕“过早优化” 。首先让它运行起来,再考虑变得 更快——但只有在自己必须这样做、而且经证实在某部分代 码中的确存在一个性能瓶颈的时候,才应进行优化。除非用 专门的工具分析瓶颈,否则很有可能是在浪费自己的时间。 性能提升的隐含代价是自己的代码变得难于理解,而且难于 维护。 (28) 请记住,阅读代码的时间比写代码的时间多得多。思 路清晰的设计可获得易于理解的程序,但注释、细致的解释 以及
一些示例往往具有不可估量的价值。无论对你自己,还
是对后来的人,它们都是相当重要的。如对此仍有怀疑,那 么请试想自己试图从联机 Java
文档里找出有用信息时碰到的 挫折,这样或许能将你说服。