解决问题的复杂程度直接取决于抽象的种类和质量。

    挑战：如何在“问题空间”（问题实际存在的地方）的元素与“方案空间”（对实际问题进行建模的地方，如计算机）的元素之间建立理想的“一对一”对应或映射关系。

    很多时候bug是发生在不正确的初始化和清理上。

    单根继承？

    代码的重复使用或者再生

    组合与继承的选择？

    继承的一个好处是它支持“累积开发”，允许我们引入新的代码，同时不会为现有代码造成错误。这样可将 新错误隔离到新代码里。通过从一个现成的、功能性的类继承，同时增添成员新的数据成员及方法（并重新 定义现有方法），我们可保持现有代码原封不动（另外有人也许仍在使用它），不会为其引入自己的编程错 误。一旦出现错误，就知道它肯定是由于自己的新代码造成的。这样一来，与修改现有代码的主体相比，改 正错误所需的时间和精力就可以少很多。 类的隔离效果非常好，这是许多程序员事先没有预料到的。甚至不需要方法的源代码来实现代码的再生。最 多只需要导入一个包（这对于继承和合并都是成立的）。 大家要记住这样一个重点：程序开发是一个不断递增或者累积的过程，就象人们学习知识一样。当然可根据 要求进行尽可能多的分析，但在一个项目的设计之初，谁都不可能提前获知所有的答案。如果能将自己的项 目看作一个有机的、能不断进步的生物，从而不断地发展和改进它，就有望获得更大的成功以及更直接的反馈。

    之所以要使用final 方法，可能是出于对两方面理由的考虑。第一个是为方法“上锁”，防止任何继承类改 变它的本来含义。设计程序时，若希望一个方法的行为在继承期间保持不变，而且不可被覆盖或改写，就可 以采取这种做法。 采用final 方法的第二个理由是程序执行的效率。将一个方法设成 final 后，编译器就可以把对那个方法的 所有调用都置入“嵌入”调用里。只要编译器发现一个final 方法调用，就会（根据它自己的判断）忽略为 执行方法调用机制而采取的常规代码插入方法（将自变量压入堆栈；跳至方法代码并执行它；跳回来；清除 156 堆栈自变量；最后对返回值进行处理）。相反，它会用方法主体内实际代码的一个副本来替换方法调用。这 样做可避免方法调用时的系统开销。当然，若方法体积太大，那么程序也会变得雍肿，可能受到到不到嵌入 代码所带来的任何性能提升。因为任何提升都被花在方法内部的时间抵消了。Java 编译器能自动侦测这些情 况，并颇为“明智”地决定是否嵌入一个 final 方法。然而，最好还是不要完全相信编译器能正确地作出所 有判断。通常，只有在方法的代码量非常少，或者想明确禁止方法被覆盖的时候，才应考虑将一个方法设为 final。

    为打开一个文件以便输入，需要使用一个 FileInputStream，同时将一个 String 或 File 对象作为文件名使 用。为提高速度，最好先对文件进行缓冲处理，从而获得用于一个BufferedInputStream 的构建器的结果句 柄。为了以格式化的形式读取输入数据，我们将那个结果句柄赋给用于一个 DataInputStream 的构建器。

    记住这样一个事实：Java 对“是否等价”的测试并不对所比较对象的内部进行检查，从而核实它们的 值是否相同。==和!=运算符只是简单地对比句柄的内容。若句柄内的地址相同，就认为句柄指向同样的对 象，所以认为它们是“等价”的。所以运算符真正检测的是“由于别名问题，句柄是否指向同一个对象？”

    正确地说，应该是 RTTI 使用不当才“有害”。我们之所以想避免 RTTI 的使用，是由于它的错误运用会造成扩展性受到损害。 而我们事前提出的目标就是能向系统自由加入新类型，同时保证对周围的代码造成尽可能小的影响。由于 RTTI 常被滥用（让它查找系统中的每一种类型），会造成代码的扩展能力大打折扣——添加一种新类型时， 必须找出使用了RTTI 的所有代码。即使仅遗漏了其中的一个，也不能从编译器那里得到任何帮助