16.1~4

16.1 范式的概念.md

@@ -10,11 +10,11 @@
 
 所以设计模式的最终目标就是将代码中变化的内容隔离开。如果从这个角度观察，就会发现本书实际已采用了一些设计模式。举个例子来说，继承可以想象成一种设计模式（类似一个由编译器实现的）。在都拥有同样接口（即保持不变的东西）的对象内部，它允许我们表达行为上的差异（即发生变化的东西）。合成亦可想象成一种模式，因为它允许我们修改——动态或静态——用于实现类的对象，所以也能修改类的运作方式。
 
-在《Design Patterns》一书中，大家还能看到另一种模式：“迭代器”（即Iterator，Java 1.0和1.1不负责任地把它叫作Enumeration，即“枚举”；Java1.2的集合则改回了“迭代器”的称呼）。当我们在集合里遍历，逐个选择不同的元素时，迭代器可将集合的实现细节有效地隐藏起来。利用迭代器，可以编写出通用的代码，以便对一个序列里的所有元素采取某种操作，同时不必关心这个序列是如何构建的。这样一来，我们的通用代码即可伴随任何能产生迭代器的集合使用。
+在《设计模式》一书中，大家还能看到另一种模式：“迭代器”（即`Iterator`，Java 1.0和1.1不负责任地把它叫作`Enumeration`，即“枚举”；Java1.2的集合则改回了“迭代器”的称呼）。当我们在集合里遍历，逐个选择不同的元素时，迭代器可将集合的实现细节有效地隐藏起来。利用迭代器，可以编写出通用的代码，以便对一个序列里的所有元素采取某种操作，同时不必关心这个序列是如何构建的。这样一来，我们的通用代码即可伴随任何能产生迭代器的集合使用。
 
 16.1.1 单例
 
-或许最简单的设计模式就是“单例”（Singleton），它能提供对象的一个（而且只有一个）实例。单例在Java库中得到了应用，但下面这个例子显得更直接一些：
+或许最简单的设计模式就是“单例”（`Singleton`），它能提供对象的一个（而且只有一个）实例。单例在Java库中得到了应用，但下面这个例子显得更直接一些：
 
 ```
 //: SingletonPattern.java
@@ -52,22 +52,22 @@ public class SingletonPattern {
 } ///:~
 ```
 
-创建单例的关键就是防止客户程序员采用除由我们提供的之外的任何一种方式来创建一个对象。必须将所有构造器都设为private（私有），而且至少要创建一个构造器，以防止编译器帮我们自动同步一个默认构造器（它会自做聪明地创建成为“友好的”——friendly，而非private）。
+创建单例的关键就是防止客户程序员采用除由我们提供的之外的任何一种方式来创建一个对象。必须将所有构造器都设为`private`（私有），而且至少要创建一个构造器，以防止编译器帮我们自动同步一个默认构造器（它会自做聪明地创建成为“友好的”——`friendly`，而非`private`）。
 
-此时应决定如何创建自己的对象。在这儿，我们选择了静态创建的方式。但亦可选择等候客户程序员发出一个创建请求，然后根据他们的要求动态创建。不管在哪种情况下，对象都应该保存为“私有”属性。我们通过公用方法提供访问途径。在这里，getHandle()会产生指向Singleton的一个引用。剩下的接口（getValue()和setValue()）属于普通的类接口。
+此时应决定如何创建自己的对象。在这儿，我们选择了静态创建的方式。但亦可选择等候客户程序员发出一个创建请求，然后根据他们的要求动态创建。不管在哪种情况下，对象都应该保存为“私有”属性。我们通过公用方法提供访问途径。在这里，`getHandle()`会产生指向`Singleton`的一个引用。剩下的接口（`getValue()`和`setValue()`）属于普通的类接口。
 
-Java也允许通过克隆（Clone）方式来创建一个对象。在这个例子中，将类设为final可禁止克隆的发生。由于Singleton是从Object直接继承的，所以clone()方法会保持protected（受保护）属性，不能够使用它（强行使用会造成编译期错误）。然而，假如我们是从一个类结构中继承，那个结构已经重载了clone()方法，使其具有public属性，并实现了Cloneable，那么为了禁止克隆，需要重载clone()，并抛出一个CloneNotSupportedException（不支持克隆异常），就象第12章介绍的那样。亦可重载clone()，并简单地返回this。那样做会造成一定的混淆，因为客户程序员可能错误地认为对象尚未克隆，仍然操纵的是原来的那个。
+Java也允许通过克隆（`Clone`）方式来创建一个对象。在这个例子中，将类设为`final`可禁止克隆的发生。由于`Singleton`是从`Object`直接继承的，所以`clone()`方法会保持`protected`（受保护）属性，不能够使用它（强行使用会造成编译期错误）。然而，假如我们是从一个类结构中继承，那个结构已经重载了`clone()`方法，使其具有`public`属性，并实现了`Cloneable`，那么为了禁止克隆，需要重载`clone()`，并抛出一个`CloneNotSupportedException`（不支持克隆异常），就象第12章介绍的那样。亦可重载`clone()`，并简单地返回`this`。那样做会造成一定的混淆，因为客户程序员可能错误地认为对象尚未克隆，仍然操纵的是原来的那个。
 
 注意我们并不限于只能创建一个对象。亦可利用该技术创建一个有限的对象池。但在那种情况下，可能需要解决池内对象的共享问题。如果不幸真的遇到这个问题，可以自己设计一套方案，实现共享对象的登记与撤消登记。
 
 16.1.2 模式分类
 
-《Design Patterns》一书讨论了23种不同的模式，并依据三个标准分类（所有标准都涉及那些可能发生变化的方面）。这三个标准是：
+《设计模式》一书讨论了23种不同的模式，并依据三个标准分类（所有标准都涉及那些可能发生变化的方面）。这三个标准是：
 
 (1) 创建：对象的创建方式。这通常涉及对象创建细节的隔离，这样便不必依赖具体类型的对象，所以在新添一种对象类型时也不必改动代码。
 
 (2) 结构：设计对象，满足特定的项目限制。这涉及对象与其他对象的连接方式，以保证系统内的改变不会影响到这些连接。
 
-(3) 行为：对程序中特定类型的行动进行操纵的对象。这要求我们将希望采取的操作封装起来，比如解释一种语言、实现一个请求、在一个序列中遍历（就象在迭代器中那样）或者实现一种算法。本章提供了“观察器”（Observer）和“访问器”（Visitor）的模式的例子。
+(3) 行为：对程序中特定类型的行动进行操纵的对象。这要求我们将希望采取的操作封装起来，比如解释一种语言、实现一个请求、在一个序列中遍历（就象在迭代器中那样）或者实现一种算法。本章提供了“观察器”（`Observer`）和“访问器”（`Visitor`）的模式的例子。
 
-《Design Patterns》为所有这23种模式都分别使用了一节，随附的还有大量示例，但大多是用C++编写的，少数用Smalltalk编写（如看过这本书，就知道这实际并不是个大问题，因为很容易即可将基本概念从两种语言翻译到Java里）。现在这本书并不打算重复《Design Patterns》介绍的所有模式，因为那是一本独立的书，大家应该单独阅读。相反，本章只准备给出一些例子，让大家先对模式有个大致的印象，并理解它们的重要性到底在哪里。
+《设计模式》为所有这23种模式都分别使用了一节，随附的还有大量示例，但大多是用C++编写的，少数用Smalltalk编写（如看过这本书，就知道这实际并不是个大问题，因为很容易即可将基本概念从两种语言翻译到Java里）。现在这本书并不打算重复《设计模式》介绍的所有模式，因为那是一本独立的书，大家应该单独阅读。相反，本章只准备给出一些例子，让大家先对模式有个大致的印象，并理解它们的重要性到底在哪里。

16.2 观察器范式.md

 # 16.2 观察器模式
 
-观察器（Observer）模式解决的是一个相当普通的问题：由于某些对象的状态发生了改变，所以一组对象都需要更新，那么该如何解决？在Smalltalk的MVC（模型－视图－控制器）的“模型－视图”部分中，或在几乎等价的“文档－视图结构”中，大家可以看到这个问题。现在我们有一些数据（“文档”）以及多个视图，假定为一张图（Plot）和一个文本视图。若改变了数据，两个视图必须知道对自己进行更新，而那正是“观察器”要负责的工作。这是一种十分常见的问题，它的解决方案已包括进标准的java.util库中。
+观察器（`Observer`）模式解决的是一个相当普通的问题：由于某些对象的状态发生了改变，所以一组对象都需要更新，那么该如何解决？在Smalltalk的MVC（模型－视图－控制器）的“模型－视图”部分中，或在几乎等价的“文档－视图结构”中，大家可以看到这个问题。现在我们有一些数据（“文档”）以及多个视图，假定为一张图（`Plot`）和一个文本视图。若改变了数据，两个视图必须知道对自己进行更新，而那正是“观察器”要负责的工作。这是一种十分常见的问题，它的解决方案已包括进标准的`java.util`库中。
 
-在Java中，有两种类型的对象用来实现观察器模式。其中，Observable类用于跟踪那些当发生一个改变时希望收到通知的所有个体——无论“状态”是否改变。如果有人说“好了，所有人都要检查自己，并可能要进行更新”，那么Observable类会执行这个任务——为列表中的每个“人”都调用notifyObservers()方法。notifyObservers()方法属于基类Observable的一部分。
+在Java中，有两种类型的对象用来实现观察器模式。其中，`Observable`类用于跟踪那些当发生一个改变时希望收到通知的所有个体——无论“状态”是否改变。如果有人说“好了，所有人都要检查自己，并可能要进行更新”，那么`Observable`类会执行这个任务——为列表中的每个“人”都调用`notifyObservers()`方法。`notifyObservers()`方法属于基类`Observable`的一部分。
 
 在观察器模式中，实际有两个方面可能发生变化：观察对象的数量以及更新的方式。也就是说，观察器模式允许我们同时修改这两个方面，不会干扰围绕在它周围的其他代码。
 
-下面这个例子类似于第14章的ColorBoxes示例。箱子（Boxes）置于一个屏幕网格中，每个都初始化一种随机的颜色。此外，每个箱子都“实现”（implement）了“观察器”（Observer）接口，而且随一个Observable对象进行了注册。若点击一个箱子，其他所有箱子都会收到一个通知，指出一个改变已经发生。这是由于Observable对象会自动调用每个Observer对象的update()方法。在这个方法内，箱子会检查被点中的那个箱子是否与自己紧邻。若答案是肯定的，那么也修改自己的颜色，保持与点中那个箱子的协调。
+下面这个例子类似于第14章的`ColorBoxes`示例。箱子（`Boxes`）置于一个屏幕网格中，每个都初始化一种随机的颜色。此外，每个箱子都“实现”（`implement`）了“观察器”（`Observer`）接口，而且随一个`Observable`对象进行了注册。若点击一个箱子，其他所有箱子都会收到一个通知，指出一个改变已经发生。这是由于`Observable`对象会自动调用每个`Observer`对象的`update()`方法。在这个方法内，箱子会检查被点中的那个箱子是否与自己紧邻。若答案是肯定的，那么也修改自己的颜色，保持与点中那个箱子的协调。
 
 ```
 //: BoxObserver.java
@@ -54,12 +54,12 @@ class OCBox extends Canvas implements Observer {
   Observable notifier;
   int x, y; // Locations in grid
   Color cColor = newColor();
-  static final Color[] colors = { 
-    Color.black, Color.blue, Color.cyan, 
+  static final Color[] colors = {
+    Color.black, Color.blue, Color.cyan,
     Color.darkGray, Color.gray, Color.green,
-    Color.lightGray, Color.magenta, 
-    Color.orange, Color.pink, Color.red, 
-    Color.white, Color.yellow 
+    Color.lightGray, Color.magenta,
+    Color.orange, Color.pink, Color.red,
+    Color.white, Color.yellow
   };
   static final Color newColor() {
     return colors[
@@ -91,14 +91,14 @@ class OCBox extends Canvas implements Observer {
     }
   }
   private final boolean nextTo(OCBox b) {
-    return Math.abs(x - b.x) <= 1 && 
+    return Math.abs(x - b.x) <= 1 &&
            Math.abs(y - b.y) <= 1;
   }
 } ///:~
 ```
 
-如果是首次查阅Observable的联机帮助文档，可能会多少感到有些困惑，因为它似乎表明可以用一个原始的Observable对象来管理更新。但这种说法是不成立的；大家可自己试试——在BoxObserver中，创建一个Observable对象，替换BoxObservable对象，看看会有什么事情发生。事实上，什么事情也不会发生。为真正产生效果，必须从Observable继承，并在派生类代码的某个地方调用setChanged()。这个方法需要设置“changed”（已改变）标志，它意味着当我们调用notifyObservers()的时候，所有观察器事实上都会收到通知。在上面的例子中，setChanged()只是简单地在notifyObservers()中调用，大家可依据符合实际情况的任何标准决定何时调用setChanged()。
+如果是首次查阅`Observable`的联机帮助文档，可能会多少感到有些困惑，因为它似乎表明可以用一个原始的`Observable`对象来管理更新。但这种说法是不成立的；大家可自己试试——在`BoxObserver`中，创建一个`Observable`对象，替换`BoxObservable`对象，看看会有什么事情发生。事实上，什么事情也不会发生。为真正产生效果，必须从`Observable`继承，并在派生类代码的某个地方调用`setChanged()`。这个方法需要设置`changed`（已改变）标志，它意味着当我们调用`notifyObservers()`的时候，所有观察器事实上都会收到通知。在上面的例子中，`setChanged()`只是简单地在`notifyObservers()`中调用，大家可依据符合实际情况的任何标准决定何时调用`setChanged()`。
 
-BoxObserver包含了单个Observable对象，名为notifier。每次创建一个OCBox对象时，它都会同notifier联系到一起。在OCBox中，只要点击鼠标，就会发出对notifyObservers()方法的调用，并将被点中的那个对象作为一个参数传递进去，使收到消息（用它们的update()方法）的所有箱子都能知道谁被点中了，并据此判断自己是否也要变动。通过notifyObservers()和update()中的代码的结合，我们可以应付一些非常复杂的局面。
+`BoxObserver`包含了单个`Observable`对象，名为`notifier`。每次创建一个`OCBox`对象时，它都会同`notifier`联系到一起。在`OCBox`中，只要点击鼠标，就会发出对`notifyObservers()`方法的调用，并将被点中的那个对象作为一个参数传递进去，使收到消息（用它们的`update()`方法）的所有箱子都能知道谁被点中了，并据此判断自己是否也要变动。通过`notifyObservers()`和`update()`中的代码的结合，我们可以应付一些非常复杂的局面。
 
-在notifyObservers()方法中，表面上似乎观察器收到通知的方式必须在编译期间固定下来。然而，只要稍微仔细研究一下上面的代码，就会发现BoxObserver或OCBox中唯一需要留意是否使用BoxObservable的地方就是创建Observable对象的时候——从那时开始，所有东西都会使用基本的Observable接口。这意味着以后若想更改通知方式，可以继承其他Observable类，并在运行期间交换它们。
+在`notifyObservers()`方法中，表面上似乎观察器收到通知的方式必须在编译期间固定下来。然而，只要稍微仔细研究一下上面的代码，就会发现`BoxObserver`或`OCBox`中唯一需要留意是否使用`BoxObservable`的地方就是创建`Observable`对象的时候——从那时开始，所有东西都会使用基本的`Observable`接口。这意味着以后若想更改通知方式，可以继承其他`Observable`类，并在运行期间交换它们。

16.3 模拟垃圾回收站.md

@@ -5,7 +5,7 @@
 这并不是一种普通的设计，因为它增加了一个新的限制。正是这个限制使问题变得非常有趣——它更象我们在工作中碰到的那些非常麻烦的问题。这个额外的限制是：垃圾抵达垃圾回收站时，它们全都是混合在一起的。程序必须为那些垃圾的分类定出一个模型。这正是RTTI发挥作用的地方：我们有大量不知名的垃圾，程序将正确判断出它们所属的类型。
 
 ```
-//: RecycleA.java 
+//: RecycleA.java
 // Recycling with RTTI
 package c16.recyclea;
 import java.util.*;
@@ -82,7 +82,7 @@ public class RecycleA {
           bin.addElement(new
             Glass(Math.random() * 100));
       }
-    Vector 
+    Vector
       glassBin = new Vector(),
       paperBin = new Vector(),
       alBin = new Vector();
@@ -106,21 +106,21 @@ public class RecycleA {
 } ///:~
 ```
 
-要注意的第一个地方是package语句：
+要注意的第一个地方是`package`语句：
 
 ```
 package c16.recyclea;
 ```
 
-这意味着在本书采用的源码目录中，这个文件会被置入从c16（代表第16章的程序）分支出来的recyclea子目录中。第17章的解包工具会负责将其置入正确的子目录。之所以要这样做，是因为本章会多次改写这个特定的例子；它的每个版本都会置入自己的“包”（package）内，避免类名的冲突。
+这意味着在本书采用的源码目录中，这个文件会被置入从`c16`（代表第16章的程序）分支出来的`recyclea`子目录中。第17章的解包工具会负责将其置入正确的子目录。之所以要这样做，是因为本章会多次改写这个特定的例子；它的每个版本都会置入自己的“包”（`package`）内，避免类名的冲突。
 
-其中创建了几个Vector对象，用于容纳Trash引用。当然，Vector实际容纳的是Object（对象），所以它们最终能够容纳任何东西。之所以要它们容纳Trash（或者从Trash派生出来的其他东西），唯一的理由是我们需要谨慎地避免放入除Trash以外的其他任何东西。如果真的把某些“错误”的东西置入Vector，那么不会在编译期得到出错或警告提示——只能通过运行期的一个异常知道自己已经犯了错误。
+其中创建了几个`Vector`对象，用于容纳`Trash`引用。当然，`Vector`实际容纳的是`Object`（对象），所以它们最终能够容纳任何东西。之所以要它们容纳`Trash`（或者从`Trash`派生出来的其他东西），唯一的理由是我们需要谨慎地避免放入除`Trash`以外的其他任何东西。如果真的把某些“错误”的东西置入`Vector`，那么不会在编译期得到出错或警告提示——只能通过运行期的一个异常知道自己已经犯了错误。
 
-Trash引用加入后，它们会丢失自己的特定标识信息，只会成为简单的Object引用（向上转换）。然而，由于存在多态性的因素，所以在我们通过Enumeration sorter调用动态绑定方法时，一旦结果Object已经转换回Trash，仍然会发生正确的行为。sumValue()也用一个Enumeration对Vector中的每个对象进行操作。
+`Trash`引用加入后，它们会丢失自己的特定标识信息，只会成为简单的`Object`引用（向上转换）。然而，由于存在多态性的因素，所以在我们通过`Enumeration sorter`调用动态绑定方法时，一旦结果`Object`已经转换回`Trash`，仍然会发生正确的行为。`sumValue()`也用一个`Enumeration`对`Vector`中的每个对象进行操作。
 
-表面上持，先把Trash的类型向上转换到一个集合容纳基类型的引用，再回过头重新向下转换，这似乎是一种非常愚蠢的做法。为什么不只是一开始就将垃圾置入适当的容器里呢？（事实上，这正是拨开“回收”一团迷雾的关键）。在这个程序中，我们很容易就可以换成这种做法，但在某些情况下，系统的结构及灵活性都能从向下转换中得到极大的好处。
+表面上持，先把`Trash`的类型向上转换到一个集合容纳基类型的引用，再回过头重新向下转换，这似乎是一种非常愚蠢的做法。为什么不只是一开始就将垃圾置入适当的容器里呢？（事实上，这正是拨开“回收”一团迷雾的关键）。在这个程序中，我们很容易就可以换成这种做法，但在某些情况下，系统的结构及灵活性都能从向下转换中得到极大的好处。
 
 该程序已满足了设计的初衷：它能够正常工作！只要这是个一次性的方案，就会显得非常出色。但是，真正有用的程序应该能够在任
-何时候解决问题。所以必须问自己这样一个问题：“如果情况发生了变化，它还能工作吗？”举个例子来说，厚纸板现在是一种非常有价值的可回收物品，那么如何把它集成到系统中呢（特别是程序很大很复杂的时候）？由于前面在switch语句中的类型检查编码可能散布于整个程序，所以每次加入一种新类型时，都必须找到所有那些编码。若不慎遗漏一个，编译器除了指出存在一个错误之外，不能再提供任何有价值的帮助。
+何时候解决问题。所以必须问自己这样一个问题：“如果情况发生了变化，它还能工作吗？”举个例子来说，厚纸板现在是一种非常有价值的可回收物品，那么如何把它集成到系统中呢（特别是程序很大很复杂的时候）？由于前面在`switch`语句中的类型检查编码可能散布于整个程序，所以每次加入一种新类型时，都必须找到所有那些编码。若不慎遗漏一个，编译器除了指出存在一个错误之外，不能再提供任何有价值的帮助。
 
-RTTI在这里使用不当的关键是“每种类型都进行了测试”。如果由于类型的子集需要特殊的对待，所以只寻找那个子集，那么情况就会变得好一些。但假如在一个switch语句中查找每一种类型，那么很可能错过一个重点，使最终的代码很难维护。在下一节中，大家会学习如何逐步对这个程序进行改进，使其显得越来越灵活。这是在程序设计中一种非常有意义的例子。
+RTTI在这里使用不当的关键是“每种类型都进行了测试”。如果由于类型的子集需要特殊的对待，所以只寻找那个子集，那么情况就会变得好一些。但假如在一个`switch`语句中查找每一种类型，那么很可能错过一个重点，使最终的代码很难维护。在下一节中，大家会学习如何逐步对这个程序进行改进，使其显得越来越灵活。这是在程序设计中一种非常有意义的例子。

16.9 总结.md

@@ -8,7 +8,7 @@
 
 设计模式要表明的观点是“OOP并不仅仅同多态性有关”。应当与OOP有关的是“将发生变化的东西同保持不变的东西分隔开来”。多态性是达到这一目的的特别重要的手段。而且假如编程语言直接支持多态性，那么它就显得尤其有用（由于直接支持，所以不必自己动手编写，从而节省大量的精力和时间）。但设计模式向我们揭示的却是达到基本目标的另一些常规途径。而且一旦熟悉并掌握了它的用法，就会发现自己可以做出更有创新性的设计。
 
-由于《Design Patterns》这本书对程序员造成了如此重要的影响，所以他们纷纷开始寻找其他模式。随着的时间的推移，这类模式必然会越来越多。JimCoplien（http://www.bell-labs.com/~cope主页作者）向我们推荐了这样的一些站点，上面有许多很有价值的模式说明：
+由于《设计模式》这本书对程序员造成了如此重要的影响，所以他们纷纷开始寻找其他模式。随着的时间的推移，这类模式必然会越来越多。JimCoplien（http://www.bell-labs.com/~cope主页作者）向我们推荐了这样的一些站点，上面有许多很有价值的模式说明：
 
 http://st-www.cs.uiuc.edu/users/patterns
 

第16章 设计范式.md

@@ -2,7 +2,7 @@
 
 本章要向大家介绍重要但却并不是那么传统的“模式”（Pattern）程序设计方法。
 
-在向面向对象程序设计的演化过程中，或许最重要的一步就是“设计模式”（Design Pattern）的问世。它在由Gamma，Helm和Johnson编著的《Design Patterns》一书中被定义成一个“里程碑”（该书由Addison-Wesley于1995年出版，注释①）。那本书列出了解决这个问题的23种不同的方法。在本章中，我们准备伴随几个例子揭示出设计模式的基本概念。这或许能激起您阅读《Design Pattern》一书的欲望。事实上，那本书现在已成为几乎所有OOP程序员都必备的参考书。
+在向面向对象程序设计的演化过程中，或许最重要的一步就是“设计模式”（Design Pattern）的问世。它在由Gamma，Helm和Johnson编著的《设计模式》一书中被定义成一个“里程碑”（该书由Addison-Wesley于1995年出版，注释①）。那本书列出了解决这个问题的23种不同的方法。在本章中，我们准备伴随几个例子揭示出设计模式的基本概念。这或许能激起您阅读《Design Pattern》一书的欲望。事实上，那本书现在已成为几乎所有OOP程序员都必备的参考书。
 
 ①：但警告大家：书中的例子是用C++写的。
 

附录F 推荐读物.md

@@ -38,7 +38,7 @@ David Flanagan
 出版时间：1997
 简介：针对三种主要的Java ORB（Visbroker，Orbix，Joe），本书分别用大量代码实例进行了详尽的阐述。
 
-■《Design Patterns》
+■《设计模式》
 作者：Gamma，Helm，Johnson和Vlissides
 出版社：Addison-Wesley
 出版时间：1995