一、对象
1、所有东西都是对象。可将对象想象成一种新型变量;它保存着数据，但可要求它对自身进行操作。理论上讲，可从要解决的问题身上提出所有概念性的组件，然后在程序中将其表达为一个对象。
2、程序是一大堆对象的组合;通过消息传递，各对象知道自己该做些什么。为了向对象发出请求，需向那个对象“发送一条消息”。更具体地讲，可将消息想象为一个调用请求，它调用的是从属于目标对象的一个子例程或函数。
3、每个对象都有自己的存储空间，可容纳其他对象。或者说，通过封装现有对象，可制作出新型对象。所 以，尽管对象的概念非常简单，但在程序中却可达到任意高的复杂程度。
4、每个对象都有一种类型。根据语法，每个对象都是某个“类”的一个“实例”。其中，“类”(Class)是“类型”(Type)的同义词。一个类最重要的特征就是“能将什么消息发给它?”。
5、同一类所有对象都能接收相同的消息。这实际是别有含义的一种说法，大家不久便能理解。由于类型为 “圆”(Circle)的一个对象也属于类型为“形状”(Shape)的一个对象，所以一个圆完全能接收形状消 息。这意味着可让程序代码统一指挥“形状”，令其自动控制所有符合“形状”描述的对象，其中自然包括 “圆”。这一特性称为对象的“可替换性”，是 OOP 最重要的概念之一。
二、数据保存
1、寄存器。这是最快的保存区域，因为它位于和其他所有保存方式不同的地方:处理器内部。然而，寄存器的数量十分有限，所以寄存器是根据需要由编译器分配。我们对此没有直接的控制权，也不可能在自己的程序里找到寄存器存在的任何踪迹。
2、堆栈。驻留于常规 RAM(随机访问存储器)区域，但可通过它的“堆栈指针”获得处理的直接支持。堆 栈指针若向下移，会创建新的内存;若向上移，则会释放那些内存。这是一种特别快、特别有效的数据保存 方式，仅次于寄存器。创建程序时，Java编译器必须准确地知道堆栈内保存的所有数据的“长度”以及“存 在时间”。这是由于它必须生成相应的代码，以便向上和向下移动指针。这一限制无疑影响了程序的灵活 性，所以尽管有些Java数据要保存在堆栈里——特别是对象句柄，但Java对象并不放到其中。
3、堆。一种常规用途的内存池(也在RAM区域)，其中保存了Java对象。和堆栈不同，“内存堆”或“堆”(Heap)最吸引人的地方在于编译器不必知道要从堆里分配多少存储空间，也不必知道存储的数据要在堆里停留多长的时间。因此，用堆保存数据时会得到更大的灵活性。要求创建一个对象时，只需用new命令编制相关的代码即可。执行这些代码时，会在堆里自动进行数据的保存。当然，为达到这种灵活性，必然会付出一定的代价:在堆里分配存储空间时会花掉更长的时间!
4、静态存储。这儿的“静态”(Static)是指“位于固定位置”(尽管也在RAM里)。程序运行期间，静态存储的数据将随时等候调用。可用static关键字指出一个对象的特定元素是静态的。但Java对象本身永远都不会置入静态存储空间。
5、常数存储。常数值通常直接置于程序代码内部。这样做是安全的，因为它们永远都不会改变。有的常数需要严格地保护，所以可考虑将它们置入只读存储器(ROM)。
6、非RAM存储。若数据完全独立于一个程序之外，则程序不运行时仍可存在，并在程序的控制范围之外。其中两个最主要的例子便是“流式对象”和“固定对象”。对于流式对象，对象会变成字节流，通常会发给另一台机器。而对于固定对象，对象保存在磁盘中。即使程序中止运行，它们仍可保持自己的状态不变。对于这些类型的数据存储，一个特别有用的技巧就是它们能存在于其他媒体中。一旦需要，甚至能将它们恢复成普通的、基于RAM的对象。
三、初始化和清除
“初始化”和“清除”是这些安全问题的其中两个。许多C程序的错误都是由于程序员忘记初始化一个变量 造成的。对于现成的库，若用户不知道如何初始化库的一个组件，就往往会出现这一类的错误。清除是另一个特殊的问题，因为用完一个元素后，由于不再关心，所以很容易把它忘记。这样一来，那个元素占用的资源会一直保留下去，极易产生资源(主要是内存)用尽的后果。
1、用构建器自动初始化
对于方法的创建，可将其想象成为自己写的每个类都调用一次initialize()。这个名字提醒我们在使用对象之前，应首先进行这样的调用。但不幸的是，这也意味着用户必须记住调用方法。在Java中，由于提供了名为“构建器”的一种特殊方法，所以类的设计者可担保每个对象都会得到正确的初始化。若某个类有一个构建器，那么在创建对象时，Java会自动调用那个构建器——甚至在用户毫不知觉的情况下。所以说这是可以担保的!接着的一个问题是如何命名这个方法。存在两方面的问题。第一个是我们使用的任何名字都可能与打算为某个类成员使用的名字冲突。第二是由于编译器的责任是调用构建器，所以它必须知道要调用是哪个方法。C++采取的方案看来是最简单的，且更有逻辑性，所以也在Java里得到了应用:构建器的名字与类名相同。这样一来，可保证象这样的一个方法会在初始化期间自动调用。
下面是带有构建器的一个简单的类：
1 | // SimpleConstructor.java |
2、清除：收尾和垃圾回收
程序员都知道“初始化”的重要性，但通常忘记清除的重要性。毕竟，谁需要来清除一个int呢?但是对于库来说，用完后简单地“释放”一个对象并非总是安全的。当然，Java可用垃圾收集器回收由不再使用的对象占据的内存。现在考虑一种非常特殊且不多见的情况。假定我们的对象分配了一个“特殊”内存区域，没有使用new。垃圾收集器只知道释放那些由new分配的内存，所以不知道如何释放对象的“特殊”内存。为解决这个问题，Java提供了一个名为finalize()的方法，可为我们的类定义它。在理想情况下，它的工作原理应该是这样的:一旦垃圾收集器准备好释放对象占用的存储空间，它首先调用finalize()，而且只有在下一次垃圾收集过程中，才会真正回收对象的内存。所以如果使用finalize()，就可以在垃圾收集期间进行一些重要的清除或清扫工作。
但也是一个潜在的编程陷阱，因为有些程序员(特别是在C++开发背景的)刚开始可能会错误认为它就是在C++中为“破坏器”(Destructor)使用的finalize()——破坏(清除)一个对象的时候，肯定会调用这个函数。但在这里有必要区分一下C++和Java的区别，因为C++的对象肯定会被清除(排开编程错误的因素)，而Java对象并非肯定能作为垃圾被“收集”去。或者换句话说:
垃圾收集并不等于“破坏”!
若能时刻牢记这一点，踩到陷阱的可能性就会大大减少。它意味着在我们不再需要一个对象之前，有些行动是必须采取的，而且必须由自己来采取这些行动。Java并未提供“破坏器”或者类似的概念，所以必须创建一个原始的方法，用它来进行这种清除。例如，假设在对象创建过程中，它会将自己描绘到屏幕上。如果不从屏幕明确删除它的图像，那么它可能永远都不会被清除。若在finalize()里置入某种删除机制，那么假设对象被当作垃圾收掉了，图像首先会将自身从屏幕上移去。但若未被收掉，图像就会保留下来。所以要记住的第二个重点是:
我们的对象可能不会当作垃圾被收掉!
有时可能发现一个对象的存储空间永远都不会释放，因为自己的程序永远都接近于用光空间的临界点。若程序执行结束，而且垃圾收集器一直都没有释放我们创建的任何对象的存储空间，则随着程序的退出，那些资源会返回给操作系统。这是一件好事情，因为垃圾收集本身也要消耗一些开销。如永远都不用它，那么永远也不用支出这部分开销。
四、类再生
“Java 引人注目的一项特性是代码的重复使用或者再生。但最具革命意义的是，除代码的复制和修改以外，我们还能做多得多的其他事情。”
在象 C 那样的程序化语言里，代码的重复使用早已可行，但效果不是特别显著。与 Java 的其他地方一样，这个方案解决的也是与类有关的问题。我们通过创建新类来重复使用代码，但却用不着重新创建，可以直接使用别人已建好并调试好的现成类。
1、合成
在新类里简单地创建原有类的对象。我们把这种方法叫作“合成”，因为新类由现有类的对象合并而成。我们只是简单地重复利用代码的功能，而不是采用它的形式。
为进行合成，我们只需在新类里简单地置入对 象句柄即可。举个例子来说，假定需要在一个对象里容纳几个String对象、两种基本数据类型以及属于另一个类的一个对象。对于非基本类型的对象来说，只需将句柄置于新类即可;而对于基本数据类型来说，则需在自己的类中定义它们。如下所示：
1 | // SprinklerSystem.java |
2、继承
创建一个新类，将其作为现有类的一个“类型”。我们可以原样采取现有类的形式，并在其中加入新代码，同时不会对现有的类产生影响。这种魔术般的行为叫作“继承”(Inheritance)，涉及的大多数工作都是由编译器完成的。对于面向对象的程序设计，“继承”是最重要的基础概念之一。
用于合成的语法是非常简单且直观的。但为了进行继承，必须采用一种全然不同的形式。需要继承的时候，我们会说:“这个新类和那个旧类差不多。”为了在代码里表面这一观念，需要给出类名。但在类主体的起始花括号之前，需要放置一个关键字extends，在后面跟随“基础类”的名字。若采取这种做法，就可自动获得基础类的所有数据成员以及方法。下面是一个例子:
1 | // Detergent.java |
五、多形性
“对于面向对象的程序设计语言，多型性是第三种最基本的特征(前两种是数据抽象和继承)。”
“多形性”(Polymorphism)从另一个角度将接口从具体的实施细节中分离出来，亦即实现了“是什么”与“怎样做”两个模块的分离。利用多形性的概念，代码的组织以及可读性均能获得改善。此外，还能创建“易于扩展”的程序。无论在项目的创建过程中，还是在需要加入新特性的时候，它们都可以方便地“成长”。
通过合并各种特征与行为，封装技术可创建出新的数据类型。通过对具体实施细节的隐藏，可将接口与实施细节分离，使所有细节成为“private”(私有)。这种组织方式使那些有程序化编程背景人感觉颇为舒适。但多形性却涉及对“类型”的分解。通过上一章的学习，大家已知道通过继承可将一个对象当作它自己的类型或者它自己的基础类型对待。这种能力是十分重要的，因为多个类型(从相同的基础类型中衍生出来)可被当作同一种类型对待。而且只需一段代码，即可对所有不同的类型进行同样的处理。利用具有多形性的方法调用，一种类型可将自己与另一种相似的类型区分开，只要它们都是从相同的基础类型中衍生出来的。这种区分是通过各种方法在行为上的差异实现的，可通过基础类实现对那些方法的调用。
六、传递和返回对象
实际传递的只是一个句柄。
在许多程序设计语言中，我们可用语言的“普通”方式到处传递对象，而且大多数时候都不会遇到问题。但 有些时候却不得不采取一些非常做法，使得情况突然变得稍微复杂起来(在 C++中则是变得非常复杂)。 Java 亦不例外，我们十分有必要准确认识在对象传递和赋值时所发生的一切。若读者是从某些特殊的程序设计环境中转移过来的，那么一般都会问到:“Java 有指针吗?”有些人认为指 针的操作很困难，而且十分危险，所以一厢情愿地认为它没有好处。同时由于Java 有如此好的口碑，所以应该很轻易地免除自己以前编程中的麻烦，其中不可能夹带有指针这样的“危险品”。然而准确地说，Java 是有指针的!事实上，Java 中每个对象(除基本数据类型以外)的标识符都属于指针的一种。但它们的使用受到了严格的限制和防范，不仅编译器对它们有“戒心”，运行期系统也不例外。或者换从另一个角度说， Java 有指针，但没有传统指针的麻烦。我曾一度将这种指针叫做“句柄”，但你可以把它想像成“安全指 针”。
1、传递句柄
将句柄传递进入一个方法时，指向的仍然是相同的对象。一个简单的实验可以证明这一点
1 | // PassHandles.java |
2、制作本地副本
稍微总结一下:Java 中的所有自变量或参数传递都是通过传递句柄进行的。也就是说，当我们传递“一个对 象”时，实际传递的只是指向位于方法外部的那个对象的“一个句柄”。所以一旦要对那个句柄进行任何修 改，便相当于修改外部对象。此外:
参数传递过程中会自动产生别名问题
不存在本地对象，只有本地句柄
句柄有自己的作用域，而对象没有
对象的“存在时间”在Java 里不是个问题
没有语言上的支持(如常量)可防止对象被修改(以避免别名的副作用)
若只是从对象中读取信息，而不修改它，传递句柄便是自变量传递中最有效的一种形式。这种做非常恰当;默认的方法一般也是最有效的方法。然而，有时仍需将对象当作“本地的”对待，使我们作出的改变只影响一个本地副本，不会对外面的对象造成影响。许多程序设计语言都支持在方法内自动生成外部对象的一个本地副本。尽管Java 不具备这种能力，但允许我们达到同样的效果。
3、克隆
若需修改一个对象，同时不想改变调用者的对象，就要制作该对象的一个本地副本。这也是本地副本最常见的一种用途。若决定制作一个本地副本，只需简单地使用 clone()方法即可。Clone 是“克隆”的意思，即制作完全一模一样的副本。这个方法在基础类Object 中定义成“protected”(受保护)模式。但在希望克隆的任何衍生类中，必须将其覆盖为“public”模式。
4、只读类
尽管在一些特定的场合，由 clone()产生的本地副本能够获得我们希望的结果，但程序员(方法的作者)不得不亲自禁止别名处理的副作用。假如想制作一个库，令其具有常规用途，但却不能担保它肯定能在正确的类中得以克隆，这时又该怎么办呢?更有可能的一种情况是，假如我们想让别名发挥积极的作用——禁止不必要的对象复制——但却不希望看到由此造成的副作用，那么又该如何处理呢?
一个办法是创建“不变对象”，令其从属于只读类。可定义一个特殊的类，使其中没有任何方法能造成对象 内部状态的改变。在这样的一个类中，别名处理是没有问题的。因为我们只能读取内部状态，所以当多处代 码都读取相同的对象时，不会出现任何副作用。
作为“不变对象”一个简单例子，Java 的标准库包含了“封装器”(wrapper)类，可用于所有基本数据类 型。大家可能已发现了这一点，如果想在一个象 Vector(只采用 Object 句柄)这样的集合里保存一个 int 数值，可以将这个int封装到标准库的Integer类内部。
七、IO系统
“对语言设计人员来说，创建好的输入/输出系统是一项特别困难的任务。”
由于存在大量不同的设计方案，所以该任务的困难性是很容易证明的。其中最大的挑战似乎是如何覆盖所有可能的因素。不仅有三种不同的种类的 IO 需要考虑(文件、控制台、网络连接)，而且需要通过大量不同的方式与它们通信(顺序、随机访问、二进制、字符、按行、按字等等)。
Java 库的设计者通过创建大量类来攻克这个难题。事实上，Java 的 IO 系统采用了如此多的类，以致刚开始会产生不知从何处入手的感觉(具有讽刺意味的是，Java 的 IO 设计初衷实际要求避免过多的类)。从 Java 1.0 升级到 Java 1.1 后，IO 库的设计也发生了显著的变化。此时并非简单地用新库替换旧库，Sun 的设计人员对原来的库进行了大手笔的扩展，添加了大量新的内容。因此，我们有时不得不混合使用新库与旧库，产生令人无奈的复杂代码。
1、输入和输出
可将Java库的IO类分割为输入与输出两个部分，这一点在用Web浏览器阅读联机Java类文档时便可知道。通过继承，从 InputStream(输入流)衍生的所有类都拥有名为 read()的基本方法，用于读取单个字节或者字节数组。类似地，从 OutputStream 衍生的所有类都拥有基本方法 write()，用于写入单个字节或者字节数组。然而，我们通常不会用到这些方法;它们之所以存在，是因为更复杂的类可以利用它们，以便提供一个更有用的接口。因此，我们很少用单个类创建自己的系统对象。一般情况下，我们都是将多个对象重叠在一起，提供自己期望的功能。我们之所以感到Java 的流库(Stream Library)异常复杂，正是由于为了创建单独一个结果流，却需要创建多个对象的缘故。
2、增添属性和有用的接口
利用层次化对象动态和透明地添加单个对象的能力的做法叫作“装饰器”(Decorator)方案。装饰器方案规定封装于初始化对象中的所有对象都拥有相同的接口，以便 利用装饰器的“透明”性质——我们将相同的消息发给一个对象，无论它是否已被“装饰”。这正是在 Java IO 库里存在“过滤器”(Filter)类的原因:抽象的“过滤器”类是所有装饰器的基础类(装饰器必须拥有与它装饰的那个对象相同的接口，但装饰器亦可对接口作出扩展，这种情况见诸于几个特殊的“过滤器”类中)。
子类处理要求大量子类对每种可能的组合提供支持时，便经常会用到装饰器——由于组合形式太多，造成子 类处理变得不切实际。Java IO库要求许多不同的特性组合方案，这正是装饰器方案显得特别有用的原因。但是，装饰器方案也有自己的一个缺点。在我们写一个程序的时候，装饰器为我们提供了大得多的灵活性(因为可以方便地混合与匹配属性)，但它们也使自己的代码变得更加复杂。原因在于Java IO 库操作不便，我们必须创建许多类——“核心”IO 类型加上所有装饰器——才能得到自己希望的单个 IO 对象。
3、本身的缺陷:RandomAccessFile
RandomAccessFile 用于包含了已知长度记录的文件，以便我们能用 seek()从一条记录移至另一条;然后读取或修改那些记录。各记录的长度并不一定相同;只要知道它们有多大以及置于文件何处即可。
首先，我们有点难以相信RandomAccessFile不属于InputStream或者OutputStream分层结构的一部分。除了恰巧实现了DataInput以及DataOutput(这两者亦由DataInputStream和DataOutputStream实现)接口之外，它们与那些分层结构并无什么关系。它甚至没有用到现有InputStream或OutputStream类的功能——采用的是一个完全不相干的类。该类属于全新的设计，含有自己的全部(大多数为固有)方法。之所以要这样做，是因为RandomAccessFile拥有与其他IO类型完全不同的行为，因为我们可在一个文件里向前或向后移动。不管在哪种情况下，它都是独立运作的，作为Object 的一个“直接继承人”使用。
从根本上说，RandomAccessFile 类似 DataInputStream 和 DataOutputStream 的联合使用。其中，getFilePointer()用于了解当前在文件的什么地方，seek()用于移至文件内的一个新地点，而 length()用于判断文件的最大长度。此外，构建器要求使用另一个自变量(与C 的fopen()完全一样)，指出自己只是随机读(“r”)，还是读写兼施(“rw”)。这里没有提供对“只写文件”的支持。也就是说，假如是从DataInputStream继承的，那么 RandomAccessFile 也有可能能很好地工作。
还有更难对付的。很容易想象我们有时要在其他类型的数据流中搜索，比如一个 ByteArrayInputStream，但搜索方法只有RandomAccessFile才会提供。而后者只能针对文件才能操作，不能针对数据流操作。此时，BufferedInputStream 确实允许我们标记一个位置(使用 mark()，它的值容纳于单个内部变量中)，并用reset()重设那个位置。但这些做法都存在限制，并不是特别有用。
4、File 类
File 类有一个欺骗性的名字——通常会认为它对付的是一个文件，但实情并非如此。它既代表一个特定文件的名字，也代表目录内一系列文件的名字。若代表一个文件集，便可用list()方法查询这个集，返回的是一个字串数组。之所以要返回一个数组，而非某个灵活的集合类，是因为元素的数量是固定的。而且若想得到一个不同的目录列表，只需创建一个不同的File 对象即可。事实上，“FilePath”(文件路径)似乎是一个更好的名字。
5、Java 1.1的IO流
Java 1.1对IO流库进行了一些重大的改进。看到Reader 和Writer类时，大多数人的第一个印象(就象我一样)就是它们用来替换原来的InputStream和 OutputStream 类。但实情并非如此。尽管不建议使用原始数据流库的某些功能(如使用它们，会从编译器收 到一条警告消息)，但原来的数据流依然得到了保留，以便维持向后兼容，而且:
(1) 在老式层次结构里加入了新类，所以Sun 公司明显不会放弃老式数据流。
(2) 在许多情况下，我们需要与新结构中的类联合使用老结构中的类。
为达到这个目的，需要使用一些“桥”类:
InputStreamReader 将一个 InputStream 转换成 Reader
OutputStreamWriter 将一个 OutputStream 转换成 Writer
所以与原来的IO流库相比，经常都要对新IO流进行层次更多的封装。同样地，这也属于装饰器方案的一个缺点——需要为额外的灵活性付出代价。
之所以在Java 1.1里添加了Reader和Writer层次，最重要的原因便是国际化的需求。老式IO流层次结构只支持8位字节流，不能很好地控制16位Unicode字符。由于Unicode主要面向的是国际化支持(Java内含的char是16位的Unicode)，所以添加了Reader和Writer层次，以提供对所有IO操作中的Unicode的支持。除此之外，新库也对速度进行了优化，可比旧库更快地运行。
6、压缩
Java 1.1 也添加一个类，用以支持对压缩格式的数据流的读写。它们封装到现成的 IO 类中，以提供压缩功能。
此时Java 1.1的一个问题显得非常突出:它们不是从新的Reader和Writer类衍生出来的，而是属于 InputStream 和 OutputStream 层次结构的一部分。所以有时不得不混合使用两种类型的数据流(注意可用 InputStreamReader 和 OutputStreamWriter 在不同的类型间方便地进行转换)。
Java 1.1 压缩类功能：
1、CheckedInputStream GetCheckSum()为任何InputStream产生校验和(不仅是解压)
2、CheckedOutputStream GetCheckSum()为任何OutputStream产生校验和(不仅是解压)
3、DeflaterOutputStream 用于压缩类的基础类
4、ZipOutputStream 一个DeflaterOutputStream，将数据压缩成Zip文件格式
5、GZIPOutputStream 一个DeflaterOutputStream，将数据压缩成GZIP 文件格式
6、InflaterInputStream 用于解压类的基础类
7、ZipInputStream 一个DeflaterInputStream，解压用Zip文件格式保存的数据
8、GZIPInputStream 一个DeflaterInputStream，解压用GZIP 文件格式保存的数据
尽管存在许多种压缩算法，但是 Zip 和 GZIP 可能最常用的。所以能够很方便地用多种现成的工具来读写这些 格式的压缩数据。
7、对象序列化
Java 1.1 增添了一种有趣的特性，名为“对象序列化”(Object Serialization)。它面向那些实现了Serializable 接口的对象，可将它们转换成一系列字节，并可在以后完全恢复回原来的样子。这一过程亦可通过网络进行。这意味着序列化机制能自动补偿操作系统间的差异。换句话说，可以先在 Windows 机器上创建一个对象，对其序列化，然后通过网络发给一台 Unix 机器，然后在那里准确无误地重新“装配”。不必关心数据在不同机器上如何表示，也不必关心字节的顺序或者其他任何细节。
就其本身来说，对象的序列化是非常有趣的，因为利用它可以实现“有限持久化”。请记住“持久化”意味着对象的“生存时间”并不取决于程序是否正在执行——它存在或“生存”于程序的每一次调用之间。通过序列化一个对象，将其写入磁盘，以后在程序重新调用时重新恢复那个对象，就能圆满实现一种“持久”效果。之所以称其为“有限”，是因为不能用某种“persistent”(持久)关键字简单地地定义一个对象，并让系统自动照看其他所有细节问题(尽管将来可能成为现实)。相反，必须在自己的程序中明确地序列化和 组装对象。
语言里增加了对象序列化的概念后，可提供对两种主要特性的支持。Java 1.1 的“远程方法调用”(RMI)使本来存在于其他机器的对象可以表现出好象就在本地机器上的行为。将消息发给远程对象时，需要通过对 象序列化来传输参数和返回值。
对象的序列化也是Java Beans必需的，后者由Java 1.1引入。使用一个Bean 时，它的状态信息通常在设计期间配置好。程序启动以后，这种状态信息必须保存下来，以便程序启动以后恢复;具体工作由对象序列化完成。
对象的序列化处理非常简单，只需对象实现了 Serializable 接口即可(该接口仅是一个标记，没有方法)。在Java 1.1 中，许多标准库类都发生了改变，以便能够序列化——其中包括用于基本数据类型的全部封装器、所有集合类以及其他许多东西。甚至 Class 对象也可以序列化(第 11 章讲述了具体实现过程)。为序列化一个对象，首先要创建某些OutputStream对象，然后将其封装到ObjectOutputStream对象内。此 时，只需调用 writeObject() 即可完成对象的序列化，并将其发送给 OutputStream。相反的过程是将一个 InputStream 封装到ObjectInputStream 内，然后调用 readObject()。和往常一样，我们最后获得的是指向一个上溯造型Object 的句柄，所以必须下溯造型，以便能够直接设置。对象序列化特别“聪明”的一个地方是它不仅保存了对象的“全景图”，而且能追踪对象内包含的所有句柄并保存那些对象;接着又能对每个对象内包含的句柄进行追踪;以此类推。我们有时将这种情况称为“对象网”，单个对象可与之建立连接。而且它还包含了对象的句柄数组以及成员对象。若必须自行操纵一套对象序列化机制，那么在代码里追踪所有这些链接时可能会显得非常麻烦。在另一方面，由于Java 对象的序列化似乎找不出什么缺点，所以请尽量不要自己动手，让它用优化的算法自动维护整个对象网。
八、多线程
利用对象，可将一个程序分割成相互独立的区域。我们通常也需要将一个程序转换成多个独立运行的子任务。
象这样的每个子任务都叫作一个“线程”(Thread)。编写程序时，可将每个线程都想象成独立运行，而且都有自己的专用 CPU。一些基础机制实际会为我们自动分割 CPU 的时间。我们通常不必关心这些细节问题，所以多线程的代码编写是相当简便的。
这时理解一些定义对以后的学习狠有帮助。“进程”是指一种“自包容”的运行程序，有自己的地址空间。“多任务”操作系统能同时运行多个进程(程序)——但实际是由于CPU分时机制的作用，使每个进程都能循环获得自己的 CPU 时间片。但由于轮换速度非常快，使得所有程序好象是在“同时”运行一样。“线程”是进程内部单一的一个顺序控制流。因此，一个进程可能容纳了多个同时执行的线程。
多线程的应用范围很广。但在一般情况下，程序的一些部分同特定的事件或资源联系在一起，同时又不想为它而暂停程序其他部分的执行。这样一来，就可考虑创建一个线程，令其与那个事件或资源关联到一起，并让它独立于主程序运行。一个很好的例子便是“Quit”或“退出”按钮——我们并不希望在程序的每一部分代码中都轮询这个按钮，同时又希望该按钮能及时地作出响应(使程序看起来似乎经常都在轮询它)。事实上，多线程最主要的一个用途就是构建一个“反应灵敏”的用户界面。
1、反应灵敏的用户界面
“线程模型”(以及Java 中的编程支持)是一种程序编写规范，可在单独一个程序里实现几个操作的同时进行。根据这一机制，CPU 可为每个线程都分配自己的一部分时间。每个线程都“感觉”自己好象拥有整个 CPU，但 CPU 的计算时间实际却是在所有线程间分摊的。线程机制多少降低了一些计算效率，但无论程序的设计，资源的均衡，还是用户操作的方便性，都从中获得了巨大的利益。综合考虑，这一机制是非常有价值的。当然，如果本来就安装了多块 CPU，那么操作系统能够自行决定为不同的 CPU 分配哪些线程，程序的总体运行速度也会变得更快(所有这些都要求操作系统以及应用程序的支持)。多线程和多任务是充分发挥多处理机系统能力的一种最有效的方式。
1、为创建一个线程，最简单的方法就是从 Thread 类继承。这个类包含了创建和运行线程所需的一切东西。 Thread 最重要的方法是 run()。但为了使用 run()，必须对其进行过载或者覆盖，使其能充分按自己的吩咐行事。因此，run()属于那些会与程序中的其他线程“并发”或“同时”执行的代码。
2、线程类(Thread)与程序的主类(Main)是分隔开的。这样做非常合理，而且易于理解。然而，还有另一种方式也是经常要用到的。尽管它不十分明确，但一般都要更简洁一些(这也解释了它为什么十分流行)。通过将主程序类变成一个线程，这种形式可将主程序类与线程类合并到一起。由于对一个GUI程序来说，主程序类必须从Frame或Applet继承，所以必须用一个接口加入额外的功能。这个接口叫作Runnable，其中包含了与Thread一致的基本方法。事实上，Thread也实现了Runnable，它只指出有一个 run()方法。对合并后的程序/线程来说，它的用法不是十分明确。当我们启动程序时，会创建一个 Runnable (可运行的)对象，但不会自行启动线程。线程的启动必须明确进行。
3、创建多个不同的线程的问题。我们不可用前面的例子来做到这一点，所以必须倒退回去，利用从Thread继承的多个独立类来封装run()。但这是一种更常规的方案，而且更易理解，所以尽管前例揭示了我们经常都能看到的编码样式，但并不推荐在大多数情况下都那样做，因为它只是稍微复杂一些，而且灵活性稍低一些。
4、“Daemon”线程的作用是在程序的运行期间于后台提供一种“常规”服务，但它并不属于程序的一个基本部分。因此，一旦所有非 Daemon 线程完成，程序也会中止运行。相反，假若有任何非 Daemon 线程仍在运行 (比如还有一个正在运行 main()的线程)，则程序的运行不会中止。 通过调用isDaemon()，可调查一个线程是不是一个Daemon，而且能用setDaemon()打开或者关闭一个线程的 Daemon状态。如果是一个Daemon线程，那么它创建的任何线程也会自动具备Daemon属性。
2、共享有限的资源
可将单线程程序想象成一种孤立的实体，它能遍历我们的问题空间，而且一次只能做一件事情。由于只有一个实体，所以永远不必担心会有两个实体同时试图使用相同的资源，就象两个人同时都想停到一个车位，同时都想通过一扇门，甚至同时发话。
进入多线程环境后，它们则再也不是孤立的。可能会有两个甚至更多的线程试图同时同一个有限的资源。必须对这种潜在资源冲突进行预防，否则就可能发生两个线程同时访问一个银行帐号，打印到同一台计算机，以及对同一个值进行调整等等。
有的时候，我们并不介意一个资源在尝试使用它的时候是否正被访问。但为了让多线程机制能够正常运转，需要采取一些措施来防止两个线程访问相同的资源——至少在关键的时期。为防止出现这样的冲突，只需在线程使用一个资源时为其加锁即可。访问资源的第一个线程会其加上锁以后，其他线程便不能再使用那个资源，除非被解锁。如果车子的前座是有限的资源，高喊“这是我的!”的孩子会主张把它锁起来。
3、堵塞
一个线程可以有四种状态:
(1) 新(New):线程对象已经创建，但尚未启动，所以不可运行。
(2) 可运行(Runnable):意味着一旦时间分片机制有空闲的CPU周期提供给一个线程，那个线程便可立即开始运行。因此，线程可能在、也可能不在运行当中，但一旦条件许可，没有什么能阻止它的运行——它既没有“死”掉，也未被“堵塞”。
(3) 死(Dead):从自己的run()方法中返回后，一个线程便已“死”掉。亦可调用stop()令其死掉，但会产生一个违例——属于 Error 的一个子类(也就是说，我们通常不捕获它)。记住一个违例的“掷”出应当是一个特殊事件，而不是正常程序运行的一部分。所以不建议你使用 stop()(在 Java 1.2 则是坚决反对)。另外还有一个 destroy()方法(它永远不会实现)，应该尽可能地避免调用它，因为它非常武断，根本不会解除对象的锁定。
(4) 堵塞(Blocked):线程可以运行，但有某种东西阻碍了它。若线程处于堵塞状态，调度机制可以简单地跳过它，不给它分配任何 CPU 时间。除非线程再次进入“可运行”状态，否则不会采取任何操作。
堵塞状态是前述四种状态中最有趣的，值得我们作进一步的探讨。线程被堵塞可能是由下述五方面的原因造成的:
(1) 调用sleep(毫秒数)，使线程进入“睡眠”状态。在规定的时间内，这个线程是不会运行的。
(2) 用suspend()暂停了线程的执行。除非线程收到resume()消息，否则不会返回“可运行”状态。
(3) 用wait()暂停了线程的执行。除非线程收到nofify()或者notifyAll()消息，否则不会变成“可运行”(是的，这看起来同原因 2 非常相象，但有一个明显的区别是我们马上要揭示的)。
(4) 线程正在等候一些 IO(输入输出)操作完成。
(5) 线程试图调用另一个对象的“同步”方法，但那个对象处于锁定状态，暂时无法使用。
由于线程可能进入堵塞状态，而且由于对象可能拥有“同步”方法——除非同步锁定被解除，否则线程不能 访问那个对象——所以一个线程完全可能等候另一个对象，而另一个对象又在等候下一个对象，以此类推。 这个“等候”链最可怕的情形就是进入封闭状态——最后那个对象等候的是第一个对象!此时，所有线程都 会陷入无休止的相互等待状态，大家都动弹不得。我们将这种情况称为“死锁”。尽管这种情况并非经常出现，但一旦碰到，程序的调试将变得异常艰难。
4、优先级
线程的优先级(Priority)告诉调试程序该线程的重要程度有多大。如果有大量线程都被堵塞，都在等候运行，调试程序会首先运行具有最高优先级的那个线程。然而，这并不表示优先级较低的线程不会运行(换言之，不会因为存在优先级而导致死锁)。若线程的优先级较低，只不过表示它被准许运行的机会小一些而已。
所有线程都隶属于一个线程组。那可以是一个默认线程组，亦可是一个创建线程时明确指定的组。在创建之初，线程被限制到一个组里，而且不能改变到一个不同的组。每个应用都至少有一个线程从属于系统线程组。若创建多个线程而不指定一个组，它们就会自动归属于系统线程组。 线程组也必须从属于其他线程组。必须在构建器里指定新线程组从属于哪个线程组。若在创建一个线程组的时候没有指定它的归属，则同样会自动成为系统线程组的一名属下。因此，一个应用程序中的所有线程组最终都会将系统线程组作为自己的“父”。
九、网络编程
历史上的网络编程都倾向于困难、复杂，而且极易出错。
程序员必须掌握与网络有关的大量细节，有时甚至要对硬件有深刻的认识。一般地，我们需要理解连网协议中不同的“层”(Layer)。而且对于每个连网库，一般都包含了数量众多的函数，分别涉及信息块的连接、 打包和拆包;这些块的来回运输;以及握手等等。这是一项令人痛苦的工作。
但是，连网本身的概念并不是很难。我们想获得位于其他地方某台机器上的信息，并把它们移到这儿;或者相反。这与读写文件非常相似，只是文件存在于远程机器上，而且远程机器有权决定如何处理我们请求或者发送的数据。
Java 最出色的一个地方就是它的“无痛苦连网”概念。有关连网的基层细节已被尽可能地提取出去，并隐藏在JVM 以及Java 的本机安装系统里进行控制。我们使用的编程模型是一个文件的模型;事实上，网络连接 (一个“套接字”)已被封装到系统对象里，所以可象对其他数据流那样采用同样的方法调用。除此以外，在我们处理另一个连网问题——同时控制多个网络连接——的时候，Java 内建的多线程机制也是十分方便的。
1、机器的标识
为了分辨来自别处的一台机器，以及为了保证自己连接的是希望的那台机器，必须有一种机制能独一无二地标识出网络内的每台机器。早期网络只解决了如何在本地网络环境中为机器提供唯一的名字。但 Java 面向的是整个因特网，这要求用一种机制对来自世界各地的机器进行标识。为达到这个目的，我们采用了 IP (互联网地址)的概念。IP 以两种形式存在着:
(1) 大家最熟悉的DNS(域名服务)形式。我自己的域名是bruceeckel.com。所以假定我在自己的域内有一 台名为 Opus 的计算机，它的域名就可以是 Opus.bruceeckel.com。这正是大家向其他人发送电子函件时采用的名字，而且通常集成到一个万维网(WWW)地址里。
(2) 此外，亦可采用“四点”格式，亦即由点号(.)分隔的四组数字，比如202.98.32.111。 不管哪种情况，IP地址在内部都表达成一个由32个二进制位(bit)构成的数字，所以IP地址的每一组数字都不能超过255。利用由java.net 提供的 static InetAddress.getByName()，我们可以让一个特定的 Java 对象表达上述任何一种形式的数字。结果是类型为 InetAddress 的一个对象，可用它构成一个“套接字”(Socket)，大家在后面会见到这一点。
1.1、服务器和客户机
网络最基本的精神就是让两台机器连接到一起，并相互“交谈”或者“沟通”。一旦两台机器都发现了对方，就可以展开一次令人愉快的双向对话。但它们怎样才能“发现”对方呢?这就象在游乐园里那样:一台机器不得不停留在一个地方，侦听其他机器说:“嘿，你在哪里呢?”
“停留在一个地方”的机器叫作“服务器”(Server);到处“找人”的机器则叫作“客户机”(Client) 或者“客户”。它们之间的区别只有在客户机试图同服务器连接的时候才显得非常明显。一旦连通，就变成了一种双向通信，谁来扮演服务器或者客户机便显得不那么重要了。
所以服务器的主要任务是侦听建立连接的请求，这是由我们创建的特定服务器对象完成的。而客户机的任务是试着与一台服务器建立连接，这是由我们创建的特定客户机对象完成的。一旦连接建好，那么无论在服务器端还是客户机端，连接只是魔术般地变成了一个 IO 数据流对象。从这时开始，我们可以象读写一个普通的文件那样对待连接。所以一旦建好连接，使用自己熟悉的 IO 命令即可。这正是 Java 连网最方便的一个地方。
1.2、端口:机器内独一无二的场所
有些时候，一个 IP 地址并不足以完整标识一个服务器。这是由于在一台物理性的机器中，往往运行着多个服务器(程序)。由 IP 表达的每台机器也包含了“端口”(Port )。我们设置一个客户机或者服务器的时候， 必须选择一个无论客户机还是服务器都认可连接的端口。就象我们去拜会某人时，IP 地址是他居住的房子，而端口是他在的那个房间。
注意端口并不是机器上一个物理上存在的场所，而是一种软件抽象(主要是为了表述的方便)。客户程序知道如何通过机器的 IP 地址同它连接，但怎样才能同自己真正需要的那种服务连接呢(一般每个端口都运行着一种服务，一台机器可能提供了多种服务，比如 HTTP 和 FTP 等等)?端口编号在这里扮演了重要的角色，它是必需的一种二级定址措施。也就是说，我们请求一个特定的端口，便相当于请求与那个端口编号关联的服务。“报时”便是服务的一个典型例子。通常，每个服务都同一台特定服务器机器上的一个独一无二的端口编号关联在一起。客户程序必须事先知道自己要求的那项服务的运行端口号。
系统服务保留了使用端口 1 到端口 1024 的权力，所以不应让自己设计的服务占用这些以及其他任何已知正在使用的端口。
2、套接字
“套接字”或者“插座”(Socket)也是一种软件形式的抽象，用于表达两台机器间一个连接的“终端”。 针对一个特定的连接，每台机器上都有一个“套接字”，可以想象它们之间有一条虚拟的“线缆”。线缆的每一端都插入一个“套接字”或者“插座”里。当然，机器之间的物理性硬件以及电缆连接都是完全未知的。抽象的基本宗旨是让我们尽可能不必知道那些细节。
在 Java 中，我们创建一个套接字，用它建立与其他机器的连接。从套接字得到的结果是一个 InputStream 以及OutputStream(若使用恰当的转换器，则分别是Reader和Writer)，以便将连接作为一个IO流对象对 待。有两个基于数据流的套接字类:ServerSocket，服务器用它“侦听”进入的连接;以及 Socket，客户用它初始一次连接。一旦客户(程序)申请建立一个套接字连接，ServerSocket 就会返回(通过accept()方法)一个对应的服务器端套接字，以便进行直接通信。从此时起，我们就得到了真正的“套接字-套接字” 连接，可以用同样的方式对待连接的两端，因为它们本来就是相同的!此时可以利用 getInputStream()以及 getOutputStream()从每个套接字产生对应的InputStream和OutputStream对象。这些数据流必须封装到缓冲区内。对类进行格式化，就象对待其他任何流对象那样。
对于Java 库的命名机制，ServerSocket(服务器套接字)的使用无疑是容易产生混淆的又一个例证。大家可能认为 ServerSocket 最好叫作“ServerConnector”(服务器连接器)，或者其他什么名字，只是不要在其中安插一个“Socket”。也可能以为ServerSocket和Socket都应从一些通用的基础类继承。事实上，这两种类确实包含了几个通用的方法，但还不够资格把它们赋给一个通用的基础类。相反，ServerSocket 的主要任务是在那里耐心地等候其他机器同它连接，再返回一个实际的 Socket。这正是“ServerSo cket ”这个命名不恰当的地方，因为它的目标不是真的成为一个 Socket，而是在其他人同它连接的时候产生一个 Socket 对象。
然而，ServerSocket 确实会在主机上创建一个物理性的“服务器”或者侦听用的套接字。这个套接字会侦听进入的连接，然后利用 accept()方法返回一个“已建立”套接字(本地和远程端点均已定义)。容易混淆的地方是这两个套接字(侦听和已建立)都与相同的服务器套接字关联在一起。侦听套接字只能接收新的连接请求，不能接收实际的数据包。所以尽管 ServerSocket 对于编程并无太大的意义，但它确实是“物理性”的。
创建一个 ServerSocket 时，只需为其赋予一个端口编号。不必把一个 IP 地址分配它，因为它已经在自己代表的那台机器上了。但在创建一个 Socket 时，却必须同时赋予 IP 地址以及要连接的端口编号(另一方面， 从 ServerSocket.accept()返回的 Socket 已经包含了所有这些信息)。
3、服务多个客户
在典型的服务器中，我们希望同时能处理多个客户的请求。解决这个问题的关键就是多线程处理机制。而对于那些本身不支持多线程的语言，达到 这个要求无疑是异常困难的。大家已经知道Java 已对多线程的处理进行了尽可能的简化。由于Java 的线程处理方式非常直接，所以让服务器控制多名客户并不是件难事。 最基本的方法是在服务器(程序)里创建单个 ServerSocket，并调用accept()来等候一个新连接。一旦 accept()返回，我们就取得结果获得的 Socket，并用它新建一个线程，令其只为那个特定的客户服务。然后再调用 accept() ，等候下一次新的连接请求。
4、数据报
大家迄今看到的例子使用的都是“传输控制协议”(TCP)，亦称作“基于数据流的套接字”。根据该协议的设计宗旨，它具有高度的可靠性，而且能保证数据顺利抵达目的地。换言之，它允许重传那些由于各种原因半路“走失”的数据。而且收到字节的顺序与它们发出来时是一样的。当然，这种控制与可靠性需要我们付出一些代价:TCP 具有非常高的开销。
还有另一种协议，名为“用户数据报协议”(UDP)，它并不刻意追求数据包会完全发送出去，也不能担保它们抵达的顺序与它们发出时一样。我们认为这是一种“不可靠协议”(TCP 当然是“可靠协议”)。听起来似乎很糟，但由于它的速度快得多，所以经常还是有用武之地的。对某些应用来说，比如声音信号的传输，如果少量数据包在半路上丢失了，那么用不着太在意，因为传输的速度显得更重要一些。大多数互联网游戏，如 Diablo，采用的也是 UDP 协议通信，因为网络通信的快慢是游戏是否流畅的决定性因素。也可以想想一台报时服务器，如果某条消息丢失了，那么也真的不必过份紧张。另外，有些应用也许能向服务器传回一条UDP消息，以便以后能够恢复。如果在适当的时间里没有响应，消息就会丢失。
Java 对数据报的支持与它对 TCP 套接字的支持大致相同，但也存在一个明显的区别。对数据报来说，我们在客户和服务器程序都可以放置一个DatagramSocket(数据报套接字)，但与ServerSocket不同，前者不会干巴巴地等待建立一个连接的请求。这是由于不再存在“连接”，取而代之的是一个数据报陈列出来。另一项本质的区别的是对 TCP 套接字来说，一旦我们建好了连接，便不再需要关心谁向谁“说话”——只需通过 会话流来回传送数据即可。但对数据报来说，它的数据包必须知道自己来自何处，以及打算去哪里。这意味着我们必须知道每个数据报包的这些信息，否则信息就不能正常地传递。
DatagramSocket用于收发数据包，而DatagramPacket包含了具体的信息。准备接收一个数据报时，只需提供一个缓冲区，以便安置接收到的数据。数据包抵达时，通过 DatagramSocket，作为信息起源地的因特网地址以及端口编号会自动得到初化。所以一个用于接收数据报的 DatagramPacket 构建器是:
1 | DatagramPacket(buf, buf.length) |
其中，buf 是一个字节数组。既然 buf 是个数组，大家可能会奇怪为什么构建器自己不能调查出数组的长度呢?实际上我也有同感，唯一能猜到的原因就是 C 风格的编程使然，那里的数组不能自己告诉我们它有多大。
可以重复使用数据报的接收代码，不必每次都建一个新的。每次用它的时候(再生)，缓冲区内的数据都会被覆盖。
缓冲区的最大容量仅受限于允许的数据报包大小，这个限制位于比64KB稍小的地方。但在许多应用程序中，我们都宁愿它变得还要小一些，特别是在发送数据的时候。具体选择的数据包大小取决于应用程序的特定要求。
发出一个数据报时，DatagramPacket 不仅需要包含正式的数据，也要包含因特网地址以及端口号，以决定它的目的地。所以用于输出DatagramPacket 的构建器是:
1 | DatagramPacket(buf, length, inetAddress, port) |
这一次，buf(一个字节数组)已经包含了我们想发出的数据。 length 可以是 buf 的长度，但也可以更短一些，意味着我们只想发出那么多的字节。另两个参数分别代表数据包要到达的因特网地址以及目标机器的一个目标端口。
5、用 JDBC 连接数据库
据估算，将近一半的软件开发都要涉及客户(机)/服务器方面的操作。Java 为自己保证的一项出色能力就是构建与平台无关的客户机/服务器数据库应用。在Java 1.1 中，这一保证通过 Java 数据库连接(JDBC)实现了。
数据库最主要的一个问题就是各家公司之间的规格大战。确实存在一种“标准”数据库语言，即“结构查询语言”(SQL-92)，但通常都必须确切知道自己要和哪家数据库公司打交道，否则极易出问题，尽管存在所谓的“标准”。JDBC 是面向“与平台无关”设计的，所以在编程的时候不必关心自己要使用的是什么数据库产品。然而，从JDBC里仍有可能发出对某些数据库公司专用功能的调用，所以仍然不可任性妄为。
和Java中的许多API一样，JDBC也做到了尽量的简化。我们发出的方法调用对应于从数据库收集数据时想当然的做法:同数据库连接，创建一个语句并执行查询，然后处理结果集。
为实现这一“与平台无关”的特点，JDBC 为我们提供了一个“驱动程序管理器”，它能动态维护数据库查询所需的所有驱动程序对象。所以假如要连接由三家公司开发的不同种类的数据库，就需要三个单独的驱动程序对象。驱动程序对象会在装载时由“驱动程序管理器”自动注册，并可用 Class.forName()强行装载。 为打开一个数据库，必须创建一个“数据库 URL”，它要指定下述三方面的内容:
(1) 用“jdbc”指出要使用JDBC。
(2) “子协议”:驱动程序的名字或者一种数据库连接机制的名称。由于 JDBC 的设计从 ODBC 吸收了许多灵 感，所以可以选用的第一种子协议就是“jdbc-odbc 桥”，它用“odbc”关键字即可指定。
(3) 数据库标识符:随使用的数据库驱动程序的不同而变化，但一般都提供了一个比较符合逻辑的名称，由数据库管理软件映射(对应)到保存了数据表的一个物理目录。为使自己的数据库标识符具有任何含义，必须用自己的数据库管理软件为自己喜欢的名字注册(注册的具体过程又随运行平台的不同而变化)。所有这些信息都统一编译到一个字串里，即“数据库URL”。举个例子来说，若想通过ODBC子协议同一个标识为“people”的数据库连接，相应的数据库URL可设为:
2
>
如果通过一个网络连接，数据库 URL 也需要包含对远程机器进行标识的信息。
准备好同数据库连接后，可调用静态方法DriverManager.getConnection()，将数据库的URL以及进入那个数据库所需的用户名密码传递给它。得到的返回结果是一个Connection 对象，利用它即可查询和操纵数据库。
6、远程方法
为通过网络执行其他机器上的代码，传统的方法不仅难以学习和掌握，也极易出错。思考这个问题最佳的方式是:某些对象正好位于另一台机器，我们可向它们发送一条消息，并获得返回结果，就象那些对象位于自己的本地机器一样。Java 1.1 的“远程方法调用”(RMI)采用的正是这种抽象。
十、设计范式
在向面向对象程序设计的演化过程中，或许最重要的一步就是“设计范式”(Design Pattern)的问世。它在由Gamma，Helm和Johnson编著的《Design Patterns》一书中被定义成一个“里程碑”(该书由Addison-Wesley于1995年出版)。那本书列出了解决这个问题的23种不同的方法。在本章中，我们准备伴随几个例子揭示出设计范式的基本概念。这或许能激起您阅读《Design Pattern》一书的欲望。事实上，那本书现在已成为几乎所有 OOP 程序员都必备的参考书。
1、范式的概念
在最开始，可将范式想象成一种特别聪明、能够自我适应的手法，它可以解决特定类型的问题。也就是说，它类似一些需要全面认识某个问题的人。在了解了问题的方方面面以后，最后提出一套最通用、最灵活的解决方案。具体问题或许是以前见到并解决过的。然而，从前的方案也许并不是最完善的，大家会看到它如何在一个范式里具体表达出来。
尽管我们称之为“设计范式”，但它们实际上并不局限于设计领域。思考“范式”时，应脱离传统意义上分析、设计以及实施的思考方式。相反，“范式”是在一个程序里具体表达一套完整的思想，所以它有时可能出现在分析阶段或者高级设计阶段。这一点是非常有趣的，因为范式具有以代码形式直接实现的形式，所以可能不希望它在低级设计或者具体实施以前显露出来(而且事实上，除非真正进入那些阶段，否则一般意识不到自己需要一个范式来解决问题)。
范式的基本概念亦可看成是程序设计的基本概念:添加一层新的抽象!只要我们抽象了某些东西，就相当于隔离了特定的细节。而且这后面最引人注目的动机就是“将保持不变的东西身上发生的变化孤立出来”。这样做的另一个原因是一旦发现程序的某部分由于这样或那样的原因可能发生变化，我们一般都想防止那些改变在代码内部繁衍出其他变化。这样做不仅可以降低代码的维护代价，也更便于我们理解(结果同样是降低开销)。
为设计出功能强大且易于维护的应用项目，通常最困难的部分就是找出我称之为“领头变化”的东西。这意味着需要找出造成系统改变的最重要的东西，或者换一个角度，找出付出代价最高、开销最大的那一部分。一旦发现了“领头变化”，就可以为自己定下一个焦点，围绕它展开自己的设计。
所以设计范式的最终目标就是将代码中变化的内容隔离开。如果从这个角度观察，就会发现本书实际已采用了一些设计范式。举个例子来说，继承可以想象成一种设计范式(类似一个由编译器实现的)。在都拥有同样接口(即保持不变的东西)的对象内部，它允许我们表达行为上的差异(即发生变化的东西)。合成亦可想象成一种范式，因为它允许我们修改——动态或静态——用于实现类的对象，所以也能修改类的运作方 式。
在《Design Patterns》一书中，大家还能看到另一种范式:“继承器”(即Iterator，Java 1.0和1.1不负责任地把它叫作 Enumeration，即“枚举”;Java1.2 的集合则改回了“继承器”的称呼)。当我们在集合里遍历，逐个选择不同的元素时，继承器可将集合的实施细节有效地隐藏起来。利用继承器，可以编写出通用的代码，以便对一个序列里的所有元素采取某种操作，同时不必关心这个序列是如何构建的。这样一来，我们的通用代码即可伴随任何能产生继承器的集合使用。
2、观察器范式
观察器(Observer)范式解决的是一个相当普通的问题:由于某些对象的状态发生了改变，所以一组对象都需要更新，那么该如何解决?在Smalltalk 的MVC(模型-视图-控制器)的“模型-视图”部分中，或在几乎等价的“文档-视图结构”中，大家可以看到这个问题。现在我们有一些数据(“文档”)以及多个视图，假定为一张图(Plot)和一个文本视图。若改变了数据，两个视图必须知道对自己进行更新，而那正是“观察器”要负责的工作。这是一种十分常见的问题，它的解决方案已包括进标准的 java.util 库中。
在 Java 中，有两种类型的对象用来实现观察器范式。其中，Observable 类用于跟踪那些当发生一个改变时希望收到通知的所有个体——无论“状态”是否改变。如果有人说“好了，所有人都要检查自己，并可能要进行更新”，那么 Observable 类会执行这个任务——为列表中的每个“人”都调用notifyObservers()方法。notifyObservers()方法属于基础类Observable的一部分。
在观察器范式中，实际有两个方面可能发生变化:观察对象的数量以及更新的方式。也就是说，观察器范式允许我们同时修改这两个方面，不会干扰围绕在它周围的其他代码。
3、模拟垃圾回收站
这个问题的本质是若将垃圾丢进单个垃圾筒，事实上是未经分类的。但在以后，某些特殊的信息必须恢复，以便对垃圾正确地归类。在最开始的解决方案中，RTTI 扮演了关键的角色。 这并不是一种普通的设计，因为它增加了一个新的限制。正是这个限制使问题变得非常有趣——它更象我们在工作中碰到的那些非常麻烦的问题。这个额外的限制是:垃圾抵达垃圾回收站时，它们全都是混合在一起的。程序必须为那些垃圾的分类定出一个模型。这正是RTTI发挥作用的地方:我们有大量不知名的垃圾，程序将正确判断出它们所属的类型。
4、改进设计
《Design Patterns》书内所有方案的组织都围绕“程序进化时会发生什么变化”这个问题展开。对于任何设计来说，这都可能是最重要的一个问题。若根据对这个问题的回答来构造自己的系统，就可以得到两个方面的结果:系统不仅更易维护(而且更廉价)，而且能产生一些能够重复使用的对象，进而使其他相关系统的构造也变得更廉价。这正是面向对象程序设计的优势所在，但这一优势并不是自动体现出来的。它要求对我们对需要解决的问题有全面而且深入的理解。
就目前这个回收系统来说，对“什么会变化”这个问题的回答是非常普通的:更多的类型会加入系统。因此，设计的目标就是尽可能简化这种类型的添加。在回收程序中，我们准备把涉及特定类型信息的所有地方都封装起来。这样一来(如果没有别的原因)，所有变化对那些封装来说都是在本地进行的。这种处理方式也使代码剩余的部分显得特别清爽。
5、抽象的应用
走到这一步，接下来该考虑一下设计方案剩下的部分了——在哪里使用类?既然归类到垃圾箱的办法非常不雅且过于暴露，为什么不隔离那个过程，把它隐藏到一个类里呢?这就是著名的“如果必须做不雅的事情，至少应将其本地化到一个类里”规则。
6、多重派遣
上述设计方案肯定是令人满意的。系统内新类型的加入涉及添加或修改不同的类，但没有必要在系统内对代码作大范围的改动。除此以外，RTTI 并不象它在 RecycleA.java 里那样被不当地使用。然而，我们仍然有可能更深入一步，以最“纯”的角度来看待 RTTI，考虑如何在垃圾分类系统中将它完全消灭。
为达到这个目标，首先必须认识到:对所有与不同类型有特殊关联的活动来说——比如侦测一种垃圾的具体类型，并把它置入适当的垃圾筒里——这些活动都应当通过多形性以及动态绑定加以控制。
以前的例子都是先按类型排序，再对属于某种特殊类型的一系列元素进行操作。现在一旦需要操作特定的类型，就请先停下来想一想。事实上，多形性(动态绑定的方法调用)整个的宗旨就是帮我们管理与不同类型有特殊关联的信息。既然如此，为什么还要自己去检查类型呢?
答案在于大家或许不以为然的一个道理:Java 只执行单一派遣。也就是说，假如对多个类型未知的对象执行某项操作，Java 只会为那些类型中的一种调用动态绑定机制。这当然不能解决问题，所以最后不得不人工判断某些类型，才能有效地产生自己的动态绑定行为。
为解决这个缺陷，我们需要用到“多重派遣”机制，这意味着需要建立一个配置，使单一方法调用能产生多个动态方法调用，从而在一次处理过程中正确判断出多种类型。为达到这个要求，需要对多个类型结构进行操作:每一次派遣都需要一个类型结构。下面的例子将对两个结构进行操作:现有的 Trash 系列以及由垃圾筒(Trash Bin)的类型构成的一个系列——不同的垃圾或废品将置入这些筒内。第二个分级结构并非绝对显然的。在这种情况下，我们需要人为地创建它，以执行多重派遣。
7、访问器范式
接下来，让我们思考如何将具有完全不同目标的一个设计范式应用到垃圾归类系统。
对这个范式，我们不再关心在系统中加入新型 Trash 时的优化。事实上，这个范式使新型 Trash 的添加显得更加复杂。假定我们有一个基本类结构，它是固定不变的;它或许来自另一个开发者或公司，我们无权对那个结构进行任何修改。然而，我们又希望在那个结构里加入新的多形性方法。这意味着我们一般必须在基础类的接口里添加某些东西。因此，我们目前面临的困境是一方面需要向基础类添加方法，另一方面又不能改动基础类。怎样解决这个问题呢?
“访问器”(Visitor)范式使我们能扩展基本类型的接口，方法是创建类型为 Visitor 的一个独立的类结构，对以后需对基本类型采取的操作进行虚拟。基本类型的任务就是简单地“接收”访问器，然后调用访问器的动态绑定方法。
8、RTTI 真的有害吗
各种设计方案都在努力避免使用RTTI，这或许会给大家留下“RTTI 有害”的印象(还记得可怜的 goto 吗，由于给人印象不佳，根本就没有放到 Java 里来)。但实际情况并非绝对如此。正确地说，应该是 RTTI 使用不当才“有害”。我们之所以想避免 RTTI 的使用，是由于它的错误运用会造成扩展性受到损害。而我们事前提出的目标就是能向系统自由加入新类型，同时保证对周围的代码造成尽可能小的影响。由于 RTTI 常被滥用(让它查找系统中的每一种类型)，会造成代码的扩展能力大打折扣——添加一种新类型时，必须找出使用了RTTI 的所有代码。即使仅遗漏了其中的一个，也不能从编译器那里得到任何帮助。 然而，RTTI 本身并不会自动产生非扩展性的代码。