修改术语

1.7 对象的创建和存在时间.md

@@ -50,7 +50,7 @@ C++允许我们决定是在写程序时创建对象，还是在运行期间创
 
 1.向下转换与模板／通用性
 
-为了使这些集合能够重复使用，或者“再生”，Java提供了一种通用类型，以前曾把它叫作`Object`。单根结构意味着、所有东西归根结底都是一个对象”！所以容纳了`Object`的一个集合实际可以容纳任何东西。这使我们对它的重复使用变得非常简便。
+为了使这些集合能够重复使用，或者“复用”，Java提供了一种通用类型，以前曾把它叫作`Object`。单根结构意味着、所有东西归根结底都是一个对象”！所以容纳了`Object`的一个集合实际可以容纳任何东西。这使我们对它的重复使用变得非常简便。
 为使用这样的一个集合，只需添加指向它的对象引用即可，以后可以通过引用重新使用对象。但由于集合只能容纳`Object`，所以在我们向集合里添加对象引用时，它会向上转换成`Object`，这样便丢失了它的身份或者标识信息。再次使用它的时候，会得到一个`Object`引用，而非指向我们早先置入的那个类型的引用。所以怎样才能归还它的本来面貌，调用早先置入集合的那个对象的有用接口呢？
 
 在这里，我们再次用到了转换（Cast）。但这一次不是在分级结构中向上转换成一种更“通用”的类型。而是向下转换成一种更“特殊”的类型。这种转换方法叫作“向下转换”（Downcasting）。举个例子来说，我们知道在向上转换的时候，`Circle`（圆）属于`Shape`（几何形状）的一种类型，所以向上转换是安全的。但我们不知道一个`Object`到底是`Circle`还是`Shape`，所以很难保证向下转换的安全进行，除非确切地知道自己要操作的是什么。

10.1 输入和输出.md

@@ -58,7 +58,7 @@ As a source of data. Connect it to a FilterInputStream object to provide a usefu
 
 ByteArrayInputStream 允许内存中的一个缓冲区作为InputStream使用 从中提取字节的缓冲区／作为一个数据源使用。通过将其同一个FilterInputStream对象连接，可提供一个有用的接口
 
-StringBufferInputStream 将一个String转换成InputStream 一个String（字串）。基础的实施方案实际采用一个
+StringBufferInputStream 将一个String转换成InputStream 一个String（字串）。基础的实现方案实际采用一个
 
 StringBuffer（字串缓冲）／作为一个数据源使用。通过将其同一个FilterInputStream对象连接，可提供一个有用的接口
 

15.4 数据报.md

@@ -8,7 +8,7 @@ Java对数据报的支持与它对TCP套接字的支持大致相同，但也存
 DatagramSocket用于收发数据包，而DatagramPacket包含了具体的信息。准备接收一个数据报时，只需提供一个缓冲区，以便安置接收到的数据。数据包抵达时，通过DatagramSocket，作为信息起源地的因特网地址以及端口编号会自动得到初化。所以一个用于接收数据报的DatagramPacket构造器是：
 DatagramPacket(buf, buf.length)
 其中，buf是一个字节数组。既然buf是个数组，大家可能会奇怪为什么构造器自己不能调查出数组的长度呢？实际上我也有同感，唯一能猜到的原因就是C风格的编程使然，那里的数组不能自己告诉我们它有多大。
-可以重复使用数据报的接收代码，不必每次都建一个新的。每次用它的时候（再生），缓冲区内的数据都会被覆盖。
+可以重复使用数据报的接收代码，不必每次都建一个新的。每次用它的时候（复用），缓冲区内的数据都会被覆盖。
 缓冲区的最大容量仅受限于允许的数据报包大小，这个限制位于比64KB稍小的地方。但在许多应用程序中，我们都宁愿它变得还要小一些，特别是在发送数据的时候。具体选择的数据包大小取决于应用程序的特定要求。
 发出一个数据报时，DatagramPacket不仅需要包含正式的数据，也要包含因特网地址以及端口号，以决定它的目的地。所以用于输出DatagramPacket的构造器是：
 DatagramPacket(buf, length, inetAddress, port)

15.8 远程方法.md

@@ -4,7 +4,7 @@
 
 15.8.1 远程接口概念
 
-RMI对接口有着强烈的依赖。在需要创建一个远程对象的时候，我们通过传递一个接口来隐藏基层的实施细节。所以客户得到远程对象的一个引用时，它们真正得到的是接口引用。这个引用正好同一些本地的根代码连接，由后者负责通过网络通信。但我们并不关心这些事情，只需通过自己的接口引用发送消息即可。
+RMI对接口有着强烈的依赖。在需要创建一个远程对象的时候，我们通过传递一个接口来隐藏基层的实现细节。所以客户得到远程对象的一个引用时，它们真正得到的是接口引用。这个引用正好同一些本地的根代码连接，由后者负责通过网络通信。但我们并不关心这些事情，只需通过自己的接口引用发送消息即可。
 
 创建一个远程接口时，必须遵守下列规则：
 
@@ -14,7 +14,7 @@ RMI对接口有着强烈的依赖。在需要创建一个远程对象的时候
 
 (3) 除与应用程序本身有关的异常之外，远程接口中的每个方法都必须在自己的throws从句中声明java.rmi.RemoteException。
 
-(4) 作为参数或返回值传递的一个远程对象（不管是直接的，还是在本地对象中嵌入）必须声明为远程接口，不可声明为实施类。
+(4) 作为参数或返回值传递的一个远程对象（不管是直接的，还是在本地对象中嵌入）必须声明为远程接口，不可声明为实现类。
 
 下面是一个简单的远程接口示例，它代表的是一个精确计时服务：
 
@@ -31,13 +31,13 @@ interface PerfectTimeI extends Remote {
 
 它表面上与其他接口是类似的，只是对Remote进行了扩展，而且它的所有方法都会“抛”出RemoteException（远程异常）。记住接口和它所有的方法都是public的。
 
-15.8.2 远程接口的实施
+15.8.2 远程接口的实现
 
 服务器必须包含一个扩展了UnicastRemoteObject的类，并实现远程接口。这个类也可以含有附加的方法，但客户只能使用远程接口中的方法。这是显然的，因为客户得到的只是指向接口的一个引用，而非实现它的那个类。
 
 必须为远程对象明确定义构造器，即使只准备定义一个默认构造器，用它调用基础类构造器。必须把它明确地编写出来，因为它必须“抛”出RemoteException异常。
 
-下面列出远程接口PerfectTime的实施过程：
+下面列出远程接口PerfectTime的实现过程：
 
 ```
 //: PerfectTime.java

16.1 范式的概念.md

@@ -2,7 +2,7 @@
 
 在最开始，可将范式想象成一种特别聪明、能够自我适应的手法，它可以解决特定类型的问题。也就是说，它类似一些需要全面认识某个问题的人。在了解了问题的方方面面以后，最后提出一套最通用、最灵活的解决方案。具体问题或许是以前见到并解决过的。然而，从前的方案也许并不是最完善的，大家会看到它如何在一个范式里具体表达出来。
 
-尽管我们称之为“设计范式”，但它们实际上并不局限于设计领域。思考“范式”时，应脱离传统意义上分析、设计以及实施的思考方式。相反，“范式”是在一个程序里具体表达一套完整的思想，所以它有时可能出现在分析阶段或者高级设计阶段。这一点是非常有趣的，因为范式具有以代码形式直接实现的形式，所以可能不希望它在低级设计或者具体实施以前显露出来（而且事实上，除非真正进入那些阶段，否则一般意识不到自己需要一个范式来解决问题）。
+尽管我们称之为“设计范式”，但它们实际上并不局限于设计领域。思考“范式”时，应脱离传统意义上分析、设计以及实现的思考方式。相反，“范式”是在一个程序里具体表达一套完整的思想，所以它有时可能出现在分析阶段或者高级设计阶段。这一点是非常有趣的，因为范式具有以代码形式直接实现的形式，所以可能不希望它在低级设计或者具体实现以前显露出来（而且事实上，除非真正进入那些阶段，否则一般意识不到自己需要一个范式来解决问题）。
 
 范式的基本概念亦可看成是程序设计的基本概念：添加一层新的抽象！只要我们抽象了某些东西，就相当于隔离了特定的细节。而且这后面最引人注目的动机就是“将保持不变的东西身上发生的变化孤立出来”。这样做的另一个原因是一旦发现程序的某部分由于这样或那样的原因可能发生变化，我们一般都想防止那些改变在代码内部繁衍出其他变化。这样做不仅可以降低代码的维护代价，也更便于我们理解（结果同样是降低开销）。
 
@@ -10,7 +10,7 @@
 
 所以设计范式的最终目标就是将代码中变化的内容隔离开。如果从这个角度观察，就会发现本书实际已采用了一些设计范式。举个例子来说，继承可以想象成一种设计范式（类似一个由编译器实现的）。在都拥有同样接口（即保持不变的东西）的对象内部，它允许我们表达行为上的差异（即发生变化的东西）。合成亦可想象成一种范式，因为它允许我们修改——动态或静态——用于实现类的对象，所以也能修改类的运作方式。
 
-在《Design Patterns》一书中，大家还能看到另一种范式：“继承器”（即Iterator，Java 1.0和1.1不负责任地把它叫作Enumeration，即“枚举”；Java1.2的集合则改回了“继承器”的称呼）。当我们在集合里遍历，逐个选择不同的元素时，继承器可将集合的实施细节有效地隐藏起来。利用继承器，可以编写出通用的代码，以便对一个序列里的所有元素采取某种操作，同时不必关心这个序列是如何构建的。这样一来，我们的通用代码即可伴随任何能产生继承器的集合使用。
+在《Design Patterns》一书中，大家还能看到另一种范式：“继承器”（即Iterator，Java 1.0和1.1不负责任地把它叫作Enumeration，即“枚举”；Java1.2的集合则改回了“继承器”的称呼）。当我们在集合里遍历，逐个选择不同的元素时，继承器可将集合的实现细节有效地隐藏起来。利用继承器，可以编写出通用的代码，以便对一个序列里的所有元素采取某种操作，同时不必关心这个序列是如何构建的。这样一来，我们的通用代码即可伴随任何能产生继承器的集合使用。
 
 16.1.1 单子
 

3.1 使用Java运算符.md

@@ -222,7 +222,7 @@ x = a * (-b);
 
 两种很不错的快捷运算方式是递增和递减运算符（常称作“自动递增”和“自动递减”运算符）。其中，递减运算符是`--`，意为“减少一个单位”；递增运算符是`++`，意为“增加一个单位”。举个例子来说，假设A是一个`int`（整数）值，则表达式`++A`就等价于（`A = A + 1`）。递增和递减运算符结果生成的是变量的值。
 
-对每种类型的运算符，都有两个版本可供选用；通常将其称为“前缀版”和“后缀版”。“前递增”表示`++`运算符位于变量或表达式的前面；而“后递增”表示`++`运算符位于变量或表达式的后面。类似地，“前递减”意味着`--`运算符位于变量或表达式的前面；而“后递减”意味着`--`运算符位于变量或表达式的后面。对于前递增和前递减（如`++A`或`--A`），会先执行运算，再生成值。而对于后递增和后递减（如`A++`或`A--`），会先生成值，再执行运算。下面是一个例子：
+对每种类型的运算符，都有两个版本可供选用；通常将其称为“前缀版”和“后缀版”。“前递增”表示`++`运算符位于变量或表达式的前面；而“后递增”表示`++`运算符位于变量或表达式的后面。类似地，“前递减”意味着`--`运算符位于变量或表达式的前面；而“后递减”意味着`--`运算符位于变量或表达式的后面。对于前递增和前递减（如`++A`或`--A`），会先执行运算，复用成值。而对于后递增和后递减（如`A++`或`A--`），会先生成值，再执行运算。下面是一个例子：
 
 ```
 //: AutoInc.java

5.3 接口与实现.md

 # 5.3 接口与实现
 
 
-我们通常认为访问控制是“隐藏实施细节”的一种方式。将数据和方法封装到类内后，可生成一种数据类型，它具有自己的特征与行为。但由于两方面重要的原因，访问为那个数据类型加上了自己的边界。第一个原因是规定客户程序员哪些能够使用，哪些不能。我们可在结构里构建自己的内部机制，不用担心客户程序员将其当作接口的一部分，从而自由地使用或者“滥用”。
+我们通常认为访问控制是“隐藏实现细节”的一种方式。将数据和方法封装到类内后，可生成一种数据类型，它具有自己的特征与行为。但由于两方面重要的原因，访问为那个数据类型加上了自己的边界。第一个原因是规定客户程序员哪些能够使用，哪些不能。我们可在结构里构建自己的内部机制，不用担心客户程序员将其当作接口的一部分，从而自由地使用或者“滥用”。
 
-这个原因直接导致了第二个原因：我们需要将接口同实施细节分离开。若结构在一系列程序中使用，但用户除了将消息发给`public`接口之外，不能做其他任何事情，我们就可以改变不属于`public`的所有东西（如“友好的”、`protected`以及`private`），同时不要求用户对他们的代码作任何修改。
+这个原因直接导致了第二个原因：我们需要将接口同实现细节分离开。若结构在一系列程序中使用，但用户除了将消息发给`public`接口之外，不能做其他任何事情，我们就可以改变不属于`public`的所有东西（如“友好的”、`protected`以及`private`），同时不要求用户对他们的代码作任何修改。
 
 我们现在是在一个面向对象的编程环境中，其中的一个类（`class`）实际是指“一类对象”，就象我们说“鱼类”或“鸟类”那样。从属于这个类的所有对象都共享这些特征与行为。“类”是对属于这一类的所有对象的外观及行为进行的一种描述。
 
@@ -11,7 +11,7 @@
 
 在Java中，类是最基本的OOP概念。它是本书未采用粗体印刷的关键字之一——由于数量太多，所以会造成页面排版的严重混乱。
 
-为清楚起见，可考虑用特殊的样式创建一个类：将`public`成员置于最开头，后面跟随`protected`、友好以及`private`成员。这样做的好处是类的使用者可从上向下依次阅读，并首先看到对自己来说最重要的内容（即`public`成员，因为它们可从文件的外部访问），并在遇到非公共成员后停止阅读，后者已经属于内部实施细节的一部分了。然而，利用由`javadoc`提供支持的注释文档（已在第2章介绍），代码的可读性问题已在很大程度上得到了解决。
+为清楚起见，可考虑用特殊的样式创建一个类：将`public`成员置于最开头，后面跟随`protected`、友好以及`private`成员。这样做的好处是类的使用者可从上向下依次阅读，并首先看到对自己来说最重要的内容（即`public`成员，因为它们可从文件的外部访问），并在遇到非公共成员后停止阅读，后者已经属于内部实现细节的一部分了。然而，利用由`javadoc`提供支持的注释文档（已在第2章介绍），代码的可读性问题已在很大程度上得到了解决。
 
 ```
 public class X {
@@ -26,4 +26,4 @@ public class X {
 }
 ```
 
-由于接口和实施细节仍然混合在一起，所以只是部分容易阅读。也就是说，仍然能够看到源码——实施的细节，因为它们需要保存在类里面。向一个类的消费者显示出接口实际是“类浏览器”的工作。这种工具能查找所有可用的类，总结出可对它们采取的全部操作（比如可以使用哪些成员等），并用一种清爽悦目的形式显示出来。到大家读到这本书的时候，所有优秀的Java开发工具都应推出了自己的浏览器。
+由于接口和实现细节仍然混合在一起，所以只是部分容易阅读。也就是说，仍然能够看到源码——实现的细节，因为它们需要保存在类里面。向一个类的消费者显示出接口实际是“类浏览器”的工作。这种工具能查找所有可用的类，总结出可对它们采取的全部操作（比如可以使用哪些成员等），并用一种清爽悦目的形式显示出来。到大家读到这本书的时候，所有优秀的Java开发工具都应推出了自己的浏览器。

5.4 类访问.md

@@ -29,7 +29,7 @@ import mylib.*;
 
 (3) 可能（但并常见）有一个编译单元根本没有任何公共类。此时，可按自己的意愿任意指定文件名。
 
-如果已经获得了`mylib`内部的一个类，准备用它完成由`Widget`或者`mylib`内部的其他某些`public`类执行的任务，此时又会出现什么情况呢？我们不希望花费力气为客户程序员编制文档，并感觉以后某个时候也许会进行大手笔的修改，并将自己的类一起删掉，换成另一个不同的类。为获得这种灵活处理的能力，需要保证没有客户程序员能够依赖自己隐藏于`mylib`内部的特定实施细节。为达到这个目的，只需将`public`关键字从类中剔除即可，这样便把类变成了“友好的”（类仅能在包内使用）。
+如果已经获得了`mylib`内部的一个类，准备用它完成由`Widget`或者`mylib`内部的其他某些`public`类执行的任务，此时又会出现什么情况呢？我们不希望花费力气为客户程序员编制文档，并感觉以后某个时候也许会进行大手笔的修改，并将自己的类一起删掉，换成另一个不同的类。为获得这种灵活处理的能力，需要保证没有客户程序员能够依赖自己隐藏于`mylib`内部的特定实现细节。为达到这个目的，只需将`public`关键字从类中剔除即可，这样便把类变成了“友好的”（类仅能在包内使用）。
 
 注意不可将类设成`private`（那样会使除类之外的其他东西都不能访问它），也不能设成`protected`（注释④）。因此，我们现在对于类的访问只有两个选择：“友好的”或者`public`。若不愿其他任何人访问那个类，可将所有构造器设为`private`。这样一来，在类的一个`static`成员内部，除自己之外的其他所有人都无法创建属于那个类的一个对象（注释⑤）。如下例所示：
 

5.5 总结.md

@@ -10,8 +10,8 @@
 
 有两方面的原因要求我们控制对成员的访问。第一个是防止用户接触那些他们不应碰的工具。对于数据类型的内部机制，那些工具是必需的。但它们并不属于用户接口的一部分，用户不必用它来解决自己的特定问题。所以将方法和字段变成“私有”（`private`）后，可极大方便用户。因为他们能轻易看出哪些对于自己来说是最重要的，以及哪些是自己需要忽略的。这样便简化了用户对一个类的理解。
 
-进行访问控制的第二个、也是最重要的一个原因是：允许库设计者改变类的内部工作机制，同时不必担心它会对客户程序员产生什么影响。最开始的时候，可用一种方法构建一个类，后来发现需要重新构建代码，以便达到更快的速度。如接口和实施细节早已进行了明确的分隔与保护，就可以轻松地达到自己的目的，不要求用户改写他们的代码。
-利用Java中的访问指示符，可有效控制类的创建者。那个类的用户可确切知道哪些是自己能够使用的，哪些则是可以忽略的。但更重要的一点是，它可确保没有任何用户能依赖一个类的基础实施机制的任何部分。作为一个类的创建者，我们可自由修改基础的实施细节，这一改变不会对客户程序员产生任何影响，因为他们不能访问类的那一部分。
-有能力改变基础的实施细节后，除了能在以后改进自己的设置之外，也同时拥有了“犯错误”的自由。无论当初计划与设计时有多么仔细，仍然有可能出现一些失误。由于知道自己能相当安全地犯下这种错误，所以可以放心大胆地进行更多、更自由的试验。这对自己编程水平的提高是很有帮助的，使整个项目最终能更快、更好地完成。
+进行访问控制的第二个、也是最重要的一个原因是：允许库设计者改变类的内部工作机制，同时不必担心它会对客户程序员产生什么影响。最开始的时候，可用一种方法构建一个类，后来发现需要重新构建代码，以便达到更快的速度。如接口和实现细节早已进行了明确的分隔与保护，就可以轻松地达到自己的目的，不要求用户改写他们的代码。
+利用Java中的访问指示符，可有效控制类的创建者。那个类的用户可确切知道哪些是自己能够使用的，哪些则是可以忽略的。但更重要的一点是，它可确保没有任何用户能依赖一个类的基础实现机制的任何部分。作为一个类的创建者，我们可自由修改基础的实现细节，这一改变不会对客户程序员产生任何影响，因为他们不能访问类的那一部分。
+有能力改变基础的实现细节后，除了能在以后改进自己的设置之外，也同时拥有了“犯错误”的自由。无论当初计划与设计时有多么仔细，仍然有可能出现一些失误。由于知道自己能相当安全地犯下这种错误，所以可以放心大胆地进行更多、更自由的试验。这对自己编程水平的提高是很有帮助的，使整个项目最终能更快、更好地完成。
 
 一个类的公共接口是所有用户都能看见的，所以在进行分析与设计的时候，这是应尽量保证其准确性的最重要的一个部分。但也不必过于紧张，少许的误差仍然是允许的。若最初设计的接口存在少许问题，可考虑添加更多的方法，只要保证不删除客户程序员已在他们的代码里使用的东西。

6.10 总结.md

 # 6.10 总结
 
 
-无论继承还是合成，我们都可以在现有类型的基础上创建一个新类型。但在典型情况下，我们通过合成来实现现有类型的“再生”或“重复使用”，将其作为新类型基础实施过程的一部分使用。但如果想实现接口的“再生”，就应使用继承。由于衍生或派生出来的类拥有基础类的接口，所以能够将其“向上转换”为基础类。对于下一章要讲述的多态性问题，这一点是至关重要的。
+无论继承还是合成，我们都可以在现有类型的基础上创建一个新类型。但在典型情况下，我们通过合成来实现现有类型的“复用”或“重复使用”，将其作为新类型基础实现过程的一部分使用。但如果想实现接口的“复用”，就应使用继承。由于衍生或派生出来的类拥有基础类的接口，所以能够将其“向上转换”为基础类。对于下一章要讲述的多态性问题，这一点是至关重要的。
 
 尽管继承在面向对象的程序设计中得到了特别的强调，但在实际启动一个设计时，最好还是先考虑采用合成技术。只有在特别必要的时候，才应考虑采用继承技术（下一章还会讲到这个问题）。合成显得更加灵活。但是，通过对自己的成员类型应用一些继承技巧，可在运行期准确改变那些成员对象的类型，由此可改变它们的行为。
 
-尽管对于快速项目开发来说，通过合成和继承实现的代码再生具有很大的帮助作用。但在允许其他程序员完全依赖它之前，一般都希望能重新设计自己的类结构。我们理想的类结构应该是每个类都有自己特定的用途。它们不能过大（如集成的功能太多，则很难实现它的再生），也不能过小（造成不能由自己使用，或者不能增添新功能）。最终实现的类应该能够方便地再生。
+尽管对于快速项目开发来说，通过合成和继承实现的代码复用具有很大的帮助作用。但在允许其他程序员完全依赖它之前，一般都希望能重新设计自己的类结构。我们理想的类结构应该是每个类都有自己特定的用途。它们不能过大（如集成的功能太多，则很难实现它的复用），也不能过小（造成不能由自己使用，或者不能增添新功能）。最终实现的类应该能够方便地复用。

6.2 继承的语法.md

@@ -53,7 +53,7 @@ public class Detergent extends Cleanser {
 
 需要着重强调的是`Cleanser`中的所有类都是`public`属性。请记住，倘若省略所有访问指示符，则成员默认为“友好的”。这样一来，就只允许对包成员进行访问。在这个包内，任何人都可使用那些没有访问指示符的方法。例如，`Detergent`将不会遇到任何麻烦。然而，假设来自另外某个包的类准备继承`Cleanser`，它就只能访问那些`public`成员。所以在计划继承的时候，一个比较好的规则是将所有字段都设为`private`，并将所有方法都设为`public`（`protected`成员也允许衍生出来的类访问它；以后还会深入探讨这一问题）。当然，在一些特殊的场合，我们仍然必须作出一些调整，但这并不是一个好的做法。
 
-注意`Cleanser`在它的接口中含有一系列方法：`append()`，`dilute()`，`apply()`，`scrub()`以及`print()`。由于`Detergent`是从`Cleanser`衍生出来的（通过`extends`关键字），所以它会自动获得接口内的所有这些方法——即使我们在`Detergent`里并未看到对它们的明确定义。这样一来，就可将继承想象成“对接口的重复利用”或者“接口的再生”（以后的实施细节可以自由设置，但那并非我们强调的重点）。
+注意`Cleanser`在它的接口中含有一系列方法：`append()`，`dilute()`，`apply()`，`scrub()`以及`print()`。由于`Detergent`是从`Cleanser`衍生出来的（通过`extends`关键字），所以它会自动获得接口内的所有这些方法——即使我们在`Detergent`里并未看到对它们的明确定义。这样一来，就可将继承想象成“对接口的重复利用”或者“接口的复用”（以后的实现细节可以自由设置，但那并非我们强调的重点）。
 
 正如在`scrub()`里看到的那样，可以获得在基础类里定义的一个方法，并对其进行修改。在这种情况下，我们通常想在新版本里调用来自基础类的方法。但在`scrub()`里，不可只是简单地发出对`scrub()`的调用。那样便造成了递归调用，我们不愿看到这一情况。为解决这个问题，Java提供了一个`super`关键字，它引用当前类已从中继承的一个“超类”（Superclass）。所以表达式`super.scrub()`调用的是方法`scrub()`的基础类版本。
 

6.5 protected.md

@@ -2,7 +2,7 @@
 
 现在我们已理解了继承的概念，protected这个关键字最后终于有了意义。在理想情况下，private成员随时都是“私有”的，任何人不得访问。但在实际应用中，经常想把某些东西深深地藏起来，但同时允许访问衍生类的成员。protected关键字可帮助我们做到这一点。它的意思是“它本身是私有的，但可由从这个类继承的任何东西或者同一个包内的其他任何东西访问”。也就是说，Java中的protected会成为进入“友好”状态。
 
-我们采取的最好的做法是保持成员的private状态——无论如何都应保留对基 础的实施细节进行修改的权利。在这一前提下，可通过protected方法允许类的继承者进行受到控制的访问：
+我们采取的最好的做法是保持成员的private状态——无论如何都应保留对基 础的实现细节进行修改的权利。在这一前提下，可通过protected方法允许类的继承者进行受到控制的访问：
 
 ```
 //: Orc.java

6.6 累积开发.md

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

6.8 final关键字.md

@@ -202,7 +202,7 @@ public class Jurassic {
 
 设计一个类时，往往需要考虑是否将一个方法设为final。可能会觉得使用自己的类时执行效率非常重要，没有人想覆盖自己的方法。这种想法在某些时候是正确的。
 
-但要慎重作出自己的假定。通常，我们很难预测一个类以后会以什么样的形式再生或重复利用。常规用途的类尤其如此。若将一个方法定义成final，就可能杜绝了在其他程序员的项目中对自己的类进行继承的途径，因为我们根本没有想到它会象那样使用。
+但要慎重作出自己的假定。通常，我们很难预测一个类以后会以什么样的形式复用或重复利用。常规用途的类尤其如此。若将一个方法定义成final，就可能杜绝了在其他程序员的项目中对自己的类进行继承的途径，因为我们根本没有想到它会象那样使用。
 
 标准Java库是阐述这一观点的最好例子。其中特别常用的一个类是Vector。如果我们考虑代码的执行效率，就会发现只有不把任何方法设为final，才能使其发挥更大的作用。我们很容易就会想到自己应继承和覆盖如此有用的一个类，但它的设计者却否定了我们的想法。但我们至少可以用两个理由来反驳他们。首先，Stack（堆栈）是从Vector继承来的，亦即Stack“是”一个Vector，这种说法是不确切的。其次，对于Vector许多重要的方法，如addElement()以及elementAt()等，它们都变成了synchronized（同步的）。正如在第14章要讲到的那样，这会造成显著的性能开销，可能会把final提供的性能改善抵销得一干二净。因此，程序员不得不猜测到底应该在哪里进行优化。在标准库里居然采用了如此笨拙的设计，真不敢想象会在程序员里引发什么样的情绪。
 

7.4 抽象类和方法.md

@@ -5,7 +5,7 @@
 
 之所以要建立这个通用接口，唯一的原因就是它能为不同的子类型作出不同的表示。它为我们建立了一种基本形式，使我们能定义在所有衍生类里“通用”的一些东西。为阐述这个观念，另一个方法是把Instrument称为“抽象基础类”（简称“抽象类”）。若想通过该通用接口处理一系列类，就需要创建一个抽象类。对所有与基础类声明的签名相符的衍生类方法，都可以通过动态绑定机制进行调用（然而，正如上一节指出的那样，如果方法名与基础类相同，但参数不同，就会出现重载现象，那或许并非我们所愿意的）。
 
-如果有一个象Instrument那样的抽象类，那个类的对象几乎肯定没有什么意义。换言之，Instrument的作用仅仅是表达接口，而不是表达一些具体的实施细节。所以创建一个Instrument对象是没有意义的，而且我们通常都应禁止用户那样做。为达到这个目的，可令Instrument内的所有方法都显示出错消息。但这样做会延迟信息到运行期，并要求在用户那一面进行彻底、可靠的测试。无论如何，最好的方法都是在编译期间捕捉到问题。
+如果有一个象Instrument那样的抽象类，那个类的对象几乎肯定没有什么意义。换言之，Instrument的作用仅仅是表达接口，而不是表达一些具体的实现细节。所以创建一个Instrument对象是没有意义的，而且我们通常都应禁止用户那样做。为达到这个目的，可令Instrument内的所有方法都显示出错消息。但这样做会延迟信息到运行期，并要求在用户那一面进行彻底、可靠的测试。无论如何，最好的方法都是在编译期间捕捉到问题。
 
 针对这个问题，Java专门提供了一种机制，名为“抽象方法”。它属于一种不完整的方法，只含有一个声明，没有方法主体。下面是抽象方法声明时采用的语法：
 

7.5 接口.md

 # 7.5 接口
 
 
-“interface”（接口）关键字使抽象的概念更深入了一层。我们可将其想象为一个“纯”抽象类。它允许创建者规定一个类的基本形式：方法名、参数列表以及返回类型，但不规定方法主体。接口也包含了基本数据类型的数据成员，但它们都默认为static和final。接口只提供一种形式，并不提供实施的细节。
+“interface”（接口）关键字使抽象的概念更深入了一层。我们可将其想象为一个“纯”抽象类。它允许创建者规定一个类的基本形式：方法名、参数列表以及返回类型，但不规定方法主体。接口也包含了基本数据类型的数据成员，但它们都默认为static和final。接口只提供一种形式，并不提供实现的细节。
 
 接口这样描述自己：“对于实现我的所有类，看起来都应该象我现在这个样子”。因此，采用了一个特定接口的所有代码都知道对于那个接口可能会调用什么方法。这便是接口的全部含义。所以我们常把接口用于建立类和类之间的一个“协议”。有些面向对象的程序设计语言采用了一个名为“protocol”（协议）的关键字，它做的便是与接口相同的事情。
 
@@ -100,7 +100,7 @@ public class Music5 {
 
 7.5.1 Java的“多重继承”
 
-接口只是比抽象类“更纯”的一种形式。它的用途并不止那些。由于接口根本没有具体的实施细节——也就是说，没有与存储空间与“接口”关联在一起——所以没有任何办法可以防止多个接口合并到一起。这一点是至关重要的，因为我们经常都需要表达这样一个意思：“x从属于a，也从属于b，也从属于c”。在C++中，将多个类合并到一起的行动称作“多重继承”，而且操作较为不便，因为每个类都可能有一套自己的实施细节。在Java中，我们可采取同样的行动，但只有其中一个类拥有具体的实施细节。所以在合并多个接口的时候，C++的问题不会在Java中重演。如下所示：
+接口只是比抽象类“更纯”的一种形式。它的用途并不止那些。由于接口根本没有具体的实现细节——也就是说，没有与存储空间与“接口”关联在一起——所以没有任何办法可以防止多个接口合并到一起。这一点是至关重要的，因为我们经常都需要表达这样一个意思：“x从属于a，也从属于b，也从属于c”。在C++中，将多个类合并到一起的行动称作“多重继承”，而且操作较为不便，因为每个类都可能有一套自己的实现细节。在Java中，我们可采取同样的行动，但只有其中一个类拥有具体的实现细节。所以在合并多个接口的时候，C++的问题不会在Java中重演。如下所示：
 
 ![](7-5.gif)
 

7.6 内部类.md

@@ -85,7 +85,7 @@ public class Parcel2 {
 
 迄今为止，内部类看起来仍然没什么特别的地方。毕竟，用它实现隐藏显得有些大题小做。Java已经有一个非常优秀的隐藏机制——只允许类成为“友好的”（只在一个包内可见），而不是把它创建成一个内部类。
 
-然而，当我们准备向上转换到一个基础类（特别是到一个接口）的时候，内部类就开始发挥其关键作用（从用于实现的对象生成一个接口引用具有与向上转换至一个基础类相同的效果）。这是由于内部类随后可完全进入不可见或不可用状态——对任何人都将如此。所以我们可以非常方便地隐藏实施细节。我们得到的全部回报就是一个基础类或者接口的引用，而且甚至有可能不知道准确的类型。就象下面这样：
+然而，当我们准备向上转换到一个基础类（特别是到一个接口）的时候，内部类就开始发挥其关键作用（从用于实现的对象生成一个接口引用具有与向上转换至一个基础类相同的效果）。这是由于内部类随后可完全进入不可见或不可用状态——对任何人都将如此。所以我们可以非常方便地隐藏实现细节。我们得到的全部回报就是一个基础类或者接口的引用，而且甚至有可能不知道准确的类型。就象下面这样：
 
 ```
 //: Parcel3.java
@@ -134,7 +134,7 @@ class Test {
 
 现在，Contents和Destination代表可由客户程序员使用的接口（记住接口会将自己的所有成员都变成public属性）。为方便起见，它们置于单独一个文件里，但原始的Contents和Destination在它们自己的文件中是相互public的。
 
-在Parcel3中，一些新东西已经加入：内部类PContents被设为private，所以除了Parcel3之外，其他任何东西都不能访问它。PDestination被设为protected，所以除了Parcel3，Parcel3包内的类（因为protected也为包赋予了访问权；也就是说，protected也是“友好的”），以及Parcel3的继承者之外，其他任何东西都不能访问PDestination。这意味着客户程序员对这些成员的认识与访问将会受到限制。事实上，我们甚至不能向下转换到一个private内部类（或者一个protected内部类，除非自己本身便是一个继承者），因为我们不能访问名字，就象在classTest里看到的那样。所以，利用private内部类，类设计人员可完全禁止其他人依赖类型编码，并可将具体的实施细节完全隐藏起来。除此以外，从客户程序员的角度来看，一个接口的范围没有意义的，因为他们不能访问不属于公共接口类的任何额外方法。这样一来，Java编译器也有机会生成效率更高的代码。
+在Parcel3中，一些新东西已经加入：内部类PContents被设为private，所以除了Parcel3之外，其他任何东西都不能访问它。PDestination被设为protected，所以除了Parcel3，Parcel3包内的类（因为protected也为包赋予了访问权；也就是说，protected也是“友好的”），以及Parcel3的继承者之外，其他任何东西都不能访问PDestination。这意味着客户程序员对这些成员的认识与访问将会受到限制。事实上，我们甚至不能向下转换到一个private内部类（或者一个protected内部类，除非自己本身便是一个继承者），因为我们不能访问名字，就象在classTest里看到的那样。所以，利用private内部类，类设计人员可完全禁止其他人依赖类型编码，并可将具体的实现细节完全隐藏起来。除此以外，从客户程序员的角度来看，一个接口的范围没有意义的，因为他们不能访问不属于公共接口类的任何额外方法。这样一来，Java编译器也有机会生成效率更高的代码。
 
 普通（非内部）类不可设为private或protected——只允许public或者“友好的”。
 
@@ -184,7 +184,7 @@ interface Contents {
 } ///:~
 ```
 
-尽管是含有具体实施细节的一个普通类，但Wrapping也作为它所有衍生类的一个通用“接口”使用：
+尽管是含有具体实现细节的一个普通类，但Wrapping也作为它所有衍生类的一个通用“接口”使用：
 
 ```
 //: Wrapping.java
@@ -732,7 +732,7 @@ WithInner.class
 
 一个“应用程序框架”是指一个或一系列类，它们专门设计用来解决特定类型的问题。为应用应用程序框架，我们可从一个或多个类继承，并覆盖其中的部分方法。我们在覆盖方法中编写的代码用于定制由那些应用程序框架提供的常规方案，以便解决自己的实际问题。“控制框架”属于应用程序框架的一种特殊类型，受到对事件响应的需要的支配；主要用来响应事件的一个系统叫作“由事件驱动的系统”。在应用程序设计语言中，最重要的问题之一便是“图形用户界面”（GUI），它几乎完全是由事件驱动的。正如大家会在第13章学习的那样，Java 1.1 AWT属于一种控制框架，它通过内部类完美地解决了GUI的问题。
 
-为理解内部类如何简化控制框架的创建与使用，可认为一个控制框架的工作就是在事件“就绪”以后执行它们。尽管“就绪”的意思很多，但在目前这种情况下，我们却是以计算机时钟为基础。随后，请认识到针对控制框架需要控制的东西，框架内并未包含任何特定的信息。首先，它是一个特殊的接口，描述了所有控制事件。它可以是一个抽象类，而非一个实际的接口。由于默认行为是根据时间控制的，所以部分实施细节可能包括：
+为理解内部类如何简化控制框架的创建与使用，可认为一个控制框架的工作就是在事件“就绪”以后执行它们。尽管“就绪”的意思很多，但在目前这种情况下，我们却是以计算机时钟为基础。随后，请认识到针对控制框架需要控制的东西，框架内并未包含任何特定的信息。首先，它是一个特殊的接口，描述了所有控制事件。它可以是一个抽象类，而非一个实际的接口。由于默认行为是根据时间控制的，所以部分实现细节可能包括：
 
 ```
 //: Event.java
@@ -820,11 +820,11 @@ Controller是进行实际工作的地方。它用一个EventSet容纳自己的Ev
 
 这里正是内部类大显身手的地方。它们允许我们做两件事情：
 
-(1) 在单独一个类里表达一个控制框架应用的全部实施细节，从而完整地封装与那个实施有关的所有东西。内部类用于表达多种不同类型的action()，它们用于解决实际的问题。除此以外，后续的例子使用了private内部类，所以实施细节会完全隐藏起来，可以安全地修改。
+(1) 在单独一个类里表达一个控制框架应用的全部实现细节，从而完整地封装与那个实现有关的所有东西。内部类用于表达多种不同类型的action()，它们用于解决实际的问题。除此以外，后续的例子使用了private内部类，所以实现细节会完全隐藏起来，可以安全地修改。
 
-(2) 内部类使我们具体的实施变得更加巧妙，因为能方便地访问外部类的任何成员。若不具备这种能力，代码看起来就可能没那么使人舒服，最后不得不寻找其他方法解决。
+(2) 内部类使我们具体的实现变得更加巧妙，因为能方便地访问外部类的任何成员。若不具备这种能力，代码看起来就可能没那么使人舒服，最后不得不寻找其他方法解决。
 
-现在要请大家思考控制框架的一种具体实施方式，它设计用来控制温室（Greenhouse）功能（注释④）。每个行动都是完全不同的：控制灯光、供水以及温度自动调节的开与关，控制响铃，以及重新启动系统。但控制框架的设计宗旨是将不同的代码方便地隔离开。对每种类型的行动，都要继承一个新的Event内部类，并在action()内编写相应的控制代码。
+现在要请大家思考控制框架的一种具体实现方式，它设计用来控制温室（Greenhouse）功能（注释④）。每个行动都是完全不同的：控制灯光、供水以及温度自动调节的开与关，控制响铃，以及重新启动系统。但控制框架的设计宗旨是将不同的代码方便地隔离开。对每种类型的行动，都要继承一个新的Event内部类，并在action()内编写相应的控制代码。
 
 ④：由于某些特殊原因，这对我来说是一个经常需要解决的、非常有趣的问题；原来的例子在《C++ Inside & Out》一书里也出现过，但Java提供了一种更令人舒适的解决方案。
 

8.5 排序.md

@@ -66,7 +66,7 @@ public class SortVector extends Vector {
 } ///:~
 ```
 
-现在，大家可以明白“回调”一词的来历，这是由于quickSort()方法“往回调用”了Compare中的方法。从中亦可理解这种技术如何生成通用的、可重复利用（再生）的代码。
+现在，大家可以明白“回调”一词的来历，这是由于quickSort()方法“往回调用”了Compare中的方法。从中亦可理解这种技术如何生成通用的、可重复利用（复用）的代码。
 
 为使用SortVector，必须创建一个类，令其为我们准备排序的对象实现Compare。此时内部类并不显得特别重要，但对于代码的组织却是有益的。下面是针对String对象的一个例子：
 
@@ -179,7 +179,7 @@ public class StrSortVector {
 } ///:~
 ```
 
-这样便可快速再生来自SortVector的代码，从而获得希望的功能。然而，并不是来自SortVector和Vector的所有public方法都能在StrSortVector中出现。若按这种形式再生代码，可在新类里为包含类内的每一个方法都生成一个定义。当然，也可以在刚开始时只添加少数几个，以后根据需要再添加更多的。新类的设计最终会稳定下来。
+这样便可快速复用来自SortVector的代码，从而获得希望的功能。然而，并不是来自SortVector和Vector的所有public方法都能在StrSortVector中出现。若按这种形式复用代码，可在新类里为包含类内的每一个方法都生成一个定义。当然，也可以在刚开始时只添加少数几个，以后根据需要再添加更多的。新类的设计最终会稳定下来。
 
 这种方法的好处在于它仍然只接纳String对象，也只产生String对象。而且相应的检查是在编译期间进行的，而非在运行期。当然，只有addElement()和elementAt()才具备这一特性；elements()仍然会产生一个Enumeration（枚举），它在编译期的类型是未定的。当然，对Enumeration以及在StrSortVector中的类型检查会照旧进行；如果真的有什么错误，运行期间会简单地产生一个异常。事实上，我们在编译或运行期间能保证一切都正确无误吗？（也就是说，“代码测试时也许不能保证”，以及“该程序的用户有可能做一些未经我们测试的事情”）。尽管存在其他选择和争论，使用继承都要容易得多，只是在转换时让人深感不便。同样地，一旦为Java加入参数化类型，就有望解决这个问题。
 

8.7 新集合.md

@@ -31,7 +31,7 @@ Collection和Map可通过多种形式实现，具体由编程要求决定。下
 List x = new LinkedList();
 ```
 
-当然，也可以决定将x作为一个LinkedList使用（而不是一个普通的List），并用x负载准确的类型信息。使用接口的好处就是一旦决定改变自己的实施细节，要做的全部事情就是在创建的时候改变它，就象下面这样：
+当然，也可以决定将x作为一个LinkedList使用（而不是一个普通的List），并用x负载准确的类型信息。使用接口的好处就是一旦决定改变自己的实现细节，要做的全部事情就是在创建的时候改变它，就象下面这样：
 
 ```
 List x = new ArrayList();
@@ -677,19 +677,19 @@ print()方法的作用是收集由entries产生的Iterator（反复器），并
 
 当创建自己的类，将其作为Map中的一个键使用时，必须注意到和以前的Set相同的问题。
 
-8.7.5 决定实施方案
+8.7.5 决定实现方案
 
-从早些时候的那幅示意图可以看出，实际上只有三个集合组件：Map，List和Set。而且每个接口只有两种或三种实施方案。若需使用由一个特定的接口提供的功能，如何才能决定到底采取哪一种方案呢？
+从早些时候的那幅示意图可以看出，实际上只有三个集合组件：Map，List和Set。而且每个接口只有两种或三种实现方案。若需使用由一个特定的接口提供的功能，如何才能决定到底采取哪一种方案呢？
 
-为理解这个问题，必须认识到每种不同的实施方案都有自己的特点、优点和缺点。比如在那张示意图中，可以看到Hashtable，Vector和Stack的“特点”是它们都属于“传统”类，所以不会干扰原有的代码。但在另一方面，应尽量避免为新的（Java 1.2）代码使用它们。
+为理解这个问题，必须认识到每种不同的实现方案都有自己的特点、优点和缺点。比如在那张示意图中，可以看到Hashtable，Vector和Stack的“特点”是它们都属于“传统”类，所以不会干扰原有的代码。但在另一方面，应尽量避免为新的（Java 1.2）代码使用它们。
 
-其他集合间的差异通常都可归纳为它们具体是由什么“后推”的。换言之，取决于物理意义上用于实施目标接口的数据结构是什么。例如，ArrayList，LinkedList以及Vector（大致等价于ArrayList）都实现了List接口，所以无论选用哪一个，我们的程序都会得到类似的结果。然而，ArrayList（以及Vector）是由一个数组后推得到的；而LinkedList是根据常规的双重链接列表方式实现的，因为每个单独的对象都包含了数据以及指向列表内前后元素的引用。正是由于这个原因，假如想在一个列表中部进行大量插入和删除操作，那么LinkedList无疑是最恰当的选择（LinkedList还有一些额外的功能，建立于AbstractSequentialList中）。若非如此，就情愿选择ArrayList，它的速度可能要快一些。
+其他集合间的差异通常都可归纳为它们具体是由什么“后推”的。换言之，取决于物理意义上用于实现目标接口的数据结构是什么。例如，ArrayList，LinkedList以及Vector（大致等价于ArrayList）都实现了List接口，所以无论选用哪一个，我们的程序都会得到类似的结果。然而，ArrayList（以及Vector）是由一个数组后推得到的；而LinkedList是根据常规的双重链接列表方式实现的，因为每个单独的对象都包含了数据以及指向列表内前后元素的引用。正是由于这个原因，假如想在一个列表中部进行大量插入和删除操作，那么LinkedList无疑是最恰当的选择（LinkedList还有一些额外的功能，建立于AbstractSequentialList中）。若非如此，就情愿选择ArrayList，它的速度可能要快一些。
 
 作为另一个例子，Set既可作为一个ArraySet实现，亦可作为HashSet实现。ArraySet是由一个ArrayList后推得到的，设计成只支持少量元素，特别适合要求创建和删除大量Set对象的场合使用。然而，一旦需要在自己的Set中容纳大量元素，ArraySet的性能就会大打折扣。写一个需要Set的程序时，应默认选择HashSet。而且只有在某些特殊情况下（对性能的提升有迫切的需求），才应切换到ArraySet。
 
 1. 决定使用何种List
 
-为体会各种List实施方案间的差异，最简便的方法就是进行一次性能测验。下述代码的作用是建立一个内部基础类，将其作为一个测试床使用。然后为每次测验都创建一个匿名内部类。每个这样的内部类都由一个test()方法调用。利用这种方法，可以方便添加和删除测试项目。
+为体会各种List实现方案间的差异，最简便的方法就是进行一次性能测验。下述代码的作用是建立一个内部基础类，将其作为一个测试床使用。然后为每次测验都创建一个匿名内部类。每个这样的内部类都由一个test()方法调用。利用这种方法，可以方便添加和删除测试项目。
 
 ```
 //: ListPerformance.java
@@ -926,7 +926,7 @@ HashSet
 
 3. 决定使用何种Map
 
-选择不同的Map实施方案时，注意Map的大小对于性能的影响是最大的，下面这个测试程序清楚地阐示了这一点：
+选择不同的Map实现方案时，注意Map的大小对于性能的影响是最大的，下面这个测试程序清楚地阐示了这一点：
 
 ```
 //: MapPerformance.java

9.6 用finally清除.md

@@ -173,7 +173,7 @@ finally in 1st try block
 
 9.6.2 缺点：丢失的异常
 
-一般情况下，Java的异常实施方案都显得十分出色。不幸的是，它依然存在一个缺点。尽管异常指出程序里存在一个危机，而且绝不应忽略，但一个异常仍有可能简单地“丢失”。在采用finally从句的一种特殊配置下，便有可能发生这种情况：
+一般情况下，Java的异常实现方案都显得十分出色。不幸的是，它依然存在一个缺点。尽管异常指出程序里存在一个危机，而且绝不应忽略，但一个异常仍有可能简单地“丢失”。在采用finally从句的一种特殊配置下，便有可能发生这种情况：
 
 ```
 //: LostMessage.java

SUMMARY.md

@@ -42,14 +42,14 @@
    * [4.5 数组初始化](4.5 数组初始化.md)
    * [4.6 总结](4.6 总结.md)
    * [4.7 练习](4.7 练习.md)
-* [第5章 隐藏实施过程](第5章 隐藏实施过程.md)
+* [第5章 隐藏实现过程](第5章 隐藏实现过程.md)
    * [5.1 包：库单元](5.1 包：库单元.md)
    * [5.2 Java访问指示符](5.2 Java访问指示符.md)
    * [5.3 接口与实现](5.3 接口与实现.md)
    * [5.4 类访问](5.4 类访问.md)
    * [5.5 总结](5.5 总结.md)
    * [5.6 练习](5.6 练习.md)
-* [第6章 类再生](第6章 类再生.md)
+* [第6章 类复用](第6章 类复用.md)
    * [6.1 合成的语法](6.1 合成的语法.md)
    * [6.2 继承的语法](6.2 继承的语法.md)
    * [6.3 合成与继承的结合](6.3 合成与继承的结合.md)

引言.md

@@ -69,13 +69,13 @@
 
 本章要探讨将代码封装到一起的方式，以及在库的其他部分隐藏时，为什么仍有一部分处于暴露状态。首先要讨论的是package和import关键字，它们的作用是进行文件级的封装（打包）操作，并允许我们构建由类构成的库（类库）。此时也会谈到目录路径和文件名的问题。本章剩下的部分将讨论public，private以及protected三个关键字、“友好”访问的概念以及各种场合下不同访问控制级的意义。
 
-**(6) 第6章：类再生**
+**(6) 第6章：类复用**
 
-继承的概念是几乎所有OOP语言中都占有重要的地位。它是对现有类加以利用，并为其添加新功能的一种有效途径（同时可以修改它，这是第7章的主题）。通过继承来重复使用原有的代码时（再生），一般需要保持“基础类”不变，只是将这儿或那儿的东西串联起来，以达到预期的效果。然而，继承并不是在现有类基础上制造新类的唯一手段。通过“合成”，亦可将一个对象嵌入新类。在这一章中，大家将学习在Java中重复使用代码的这两种方法，以及具体如何运用。
+继承的概念是几乎所有OOP语言中都占有重要的地位。它是对现有类加以利用，并为其添加新功能的一种有效途径（同时可以修改它，这是第7章的主题）。通过继承来重复使用原有的代码时（复用），一般需要保持“基础类”不变，只是将这儿或那儿的东西串联起来，以达到预期的效果。然而，继承并不是在现有类基础上制造新类的唯一手段。通过“合成”，亦可将一个对象嵌入新类。在这一章中，大家将学习在Java中重复使用代码的这两种方法，以及具体如何运用。
 
 **(7) 第7章：多态性**
 
-若由你自己来干，可能要花9个月的时间才能发现和理解多态性的问题，这一特性实际是OOP一个重要的基础。通过一些小的、简单的例子，读者可知道如何通过继承来创建一系列类型，并通过它们共有的基础类对那个系列中的对象进行操作。通过Java的多态性概念，同一系列中的所有对象都具有了共通性。这意味着我们编写的代码不必再依赖特定的类型信息。这使程序更易扩展，包容力也更强。由此，程序的构建和代码的维护可以变得更方便，付出的代价也会更低。此外，Java还通过“接口”提供了设置再生关系的第三种途径。这儿所谓的“接口”是对对象物理“接口”一种纯粹的抽象。一旦理解了多态性的概念，接口的含义就很容易解释了。本章也向大家介绍了Java 1.1的“内部类”。
+若由你自己来干，可能要花9个月的时间才能发现和理解多态性的问题，这一特性实际是OOP一个重要的基础。通过一些小的、简单的例子，读者可知道如何通过继承来创建一系列类型，并通过它们共有的基础类对那个系列中的对象进行操作。通过Java的多态性概念，同一系列中的所有对象都具有了共通性。这意味着我们编写的代码不必再依赖特定的类型信息。这使程序更易扩展，包容力也更强。由此，程序的构建和代码的维护可以变得更方便，付出的代价也会更低。此外，Java还通过“接口”提供了设置复用关系的第三种途径。这儿所谓的“接口”是对对象物理“接口”一种纯粹的抽象。一旦理解了多态性的概念，接口的含义就很容易解释了。本章也向大家介绍了Java 1.1的“内部类”。
 
 **(8) 第8章：对象的容纳**
 

第13章 创建窗口和程序片.md

@@ -3203,7 +3203,7 @@ public class BadTechnique extends Frame {
   }
 } ///:~
 
-的确，它能够工作。但却实在太蹩脚，而且很难编写、阅读、调试、维护以及再生。既然如此，为什么还不使用内部接收器类呢？
+的确，它能够工作。但却实在太蹩脚，而且很难编写、阅读、调试、维护以及复用。既然如此，为什么还不使用内部接收器类呢？
 
 13.17 Java 1.1用户接口API
 Java 1.1版同样增加了一些重要的新功能，包括焦点遍历，桌面色彩访问，打印“沙箱内”及早期的剪贴板支持。

第1章 对象入门.md

@@ -4,7 +4,7 @@
 
 面向对象编程（OOP）具有多方面的吸引力。对管理人员，它实现了更快和更廉价的开发与维护过程。对分析与设计人员，建模处理变得更加简单，能生成清晰、易于维护的设计模式。对程序员，对象模型显得如此高雅和浅显。此外，面向对象工具以及库的巨大威力使编程成为一项更使人愉悦的任务。每个人都可从中获益，至少表面如此。
 
-如果说它有缺点，那就是掌握它需付出的代价。思考对象的时候，需要采用形象思维，而不是程序化的思维。与程序化设计相比，对象的设计过程更具挑战性——特别是在尝试创建可重复使用（可再生）的对象时。过去，那些初涉面向对象编程领域的人都必须进行一项令人痛苦的选择：
+如果说它有缺点，那就是掌握它需付出的代价。思考对象的时候，需要采用形象思维，而不是程序化的思维。与程序化设计相比，对象的设计过程更具挑战性——特别是在尝试创建可重复使用（可复用）的对象时。过去，那些初涉面向对象编程领域的人都必须进行一项令人痛苦的选择：
 
 (1) 选择一种诸如Smalltalk的语言，“出师”前必须掌握一个巨型的库。
 

第5章 隐藏实施过程.md

-# 第5章 隐藏实施过程
+# 第5章 隐藏实现过程
 
 
 “进行面向对象的设计时，一项基本的考虑是：如何将发生变化的东西与保持不变的东西分隔开。”
 
 这一点对于库来说是特别重要的。那个库的用户（客户程序员）必须能依赖自己使用的那一部分，并知道一旦新版本的库出台，自己不需要改写代码。而与此相反，库的创建者必须能自由地进行修改与改进，同时保证客户程序员代码不会受到那些变动的影响。
 
-为达到这个目的，需遵守一定的约定或规则。例如，库程序员在修改库内的一个类时，必须保证不删除已有的方法，因为那样做会造成客户程序员代码出现断点。然而，相反的情况却是令人痛苦的。对于一个数据成员，库的创建者怎样才能知道哪些数据成员已受到客户程序员的访问呢？若方法属于某个类唯一的一部分，而且并不一定由客户程序员直接使用，那么这种痛苦的情况同样是真实的。如果库的创建者想删除一种旧有的实施方案，并置入新代码，此时又该怎么办呢？对那些成员进行的任何改动都可能中断客户程序员的代码。所以库创建者处在一个尴尬的境地，似乎根本动弹不得。
+为达到这个目的，需遵守一定的约定或规则。例如，库程序员在修改库内的一个类时，必须保证不删除已有的方法，因为那样做会造成客户程序员代码出现断点。然而，相反的情况却是令人痛苦的。对于一个数据成员，库的创建者怎样才能知道哪些数据成员已受到客户程序员的访问呢？若方法属于某个类唯一的一部分，而且并不一定由客户程序员直接使用，那么这种痛苦的情况同样是真实的。如果库的创建者想删除一种旧有的实现方案，并置入新代码，此时又该怎么办呢？对那些成员进行的任何改动都可能中断客户程序员的代码。所以库创建者处在一个尴尬的境地，似乎根本动弹不得。
 
 为解决这个问题，Java推出了“访问指示符”的概念，允许库创建者声明哪些东西是客户程序员可以使用的，哪些是不可使用的。这种访问控制的级别在“最大访问”和“最小访问”的范围之间，分别包括：public，“友好的”（无关键字），protected以及private。根据前一段的描述，大家或许已总结出作为一名库设计者，应将所有东西都尽可能保持为“private”（私有），并只展示出那些想让客户程序员使用的方法。这种思路是完全正确的，尽管它有点儿违背那些用其他语言（特别是C）编程的人的直觉，那些人习惯于在没有任何限制的情况下访问所有东西。到这一章结束时，大家应该可以深刻体会到Java访问控制的价值。
 

第6章 类再生.md

-# 第6章 类再生
+# 第6章 类复用
 
 
-“Java引人注目的一项特性是代码的重复使用或者再生。但最具革命意义的是，除代码的复制和修改以外，我们还能做多得多的其他事情。”
+“Java引人注目的一项特性是代码的重复使用或者复用。但最具革命意义的是，除代码的复制和修改以外，我们还能做多得多的其他事情。”
 
 在象C那样的程序化语言里，代码的重复使用早已可行，但效果不是特别显著。与Java的其他地方一样，这个方案解决的也是与类有关的问题。我们通过创建新类来重复使用代码，但却用不着重新创建，可以直接使用别人已建好并调试好的现成类。
 
@@ -9,5 +9,5 @@
 
 第二种方法则显得稍微有些技巧。它创建一个新类，将其作为现有类的一个“类型”。我们可以原样采取现有类的形式，并在其中加入新代码，同时不会对现有的类产生影响。这种魔术般的行为叫作“继承”（Inheritance），涉及的大多数工作都是由编译器完成的。对于面向对象的程序设计，“继承”是最重要的基础概念之一。它对我们下一章要讲述的内容会产生一些额外的影响。
 
-对于合成与继承这两种方法，大多数语法和行为都是类似的（因为它们都要根据现有的类型生成新类型）。在本章，我们将深入学习这些代码再生或者重复使用的机制。
+对于合成与继承这两种方法，大多数语法和行为都是类似的（因为它们都要根据现有的类型生成新类型）。在本章，我们将深入学习这些代码复用或者重复使用的机制。
 

第7章 多形性.md

@@ -3,8 +3,8 @@
 
 “对于面向对象的程序设计语言，多型性是第三种最基本的特征（前两种是数据抽象和继承。”
 
-“多态性”（Polymorphism）从另一个角度将接口从具体的实施细节中分离出来，亦即实现了“是什么”与“怎样做”两个模块的分离。利用多态性的概念，代码的组织以及可读性均能获得改善。此外，还能创建“易于扩展”的程序。无论在项目的创建过程中，还是在需要加入新特性的时候，它们都可以方便地“成长”。
+“多态性”（Polymorphism）从另一个角度将接口从具体的实现细节中分离出来，亦即实现了“是什么”与“怎样做”两个模块的分离。利用多态性的概念，代码的组织以及可读性均能获得改善。此外，还能创建“易于扩展”的程序。无论在项目的创建过程中，还是在需要加入新特性的时候，它们都可以方便地“成长”。
 
-通过合并各种特征与行为，封装技术可创建出新的数据类型。通过对具体实施细节的隐藏，可将接口与实施细节分离，使所有细节成为“private”（私有）。这种组织方式使那些有程序化编程背景人感觉颇为舒适。但多态性却涉及对“类型”的分解。通过上一章的学习，大家已知道通过继承可将一个对象当作它自己的类型或者它自己的基础类型对待。这种能力是十分重要的，因为多个类型（从相同的基础类型中衍生出来）可被当作同一种类型对待。而且只需一段代码，即可对所有不同的类型进行同样的处理。利用具有多态性的方法调用，一种类型可将自己与另一种相似的类型区分开，只要它们都是从相同的基础类型中衍生出来的。这种区分是通过各种方法在行为上的差异实现的，可通过基础类实现对那些方法的调用。
+通过合并各种特征与行为，封装技术可创建出新的数据类型。通过对具体实现细节的隐藏，可将接口与实现细节分离，使所有细节成为“private”（私有）。这种组织方式使那些有程序化编程背景人感觉颇为舒适。但多态性却涉及对“类型”的分解。通过上一章的学习，大家已知道通过继承可将一个对象当作它自己的类型或者它自己的基础类型对待。这种能力是十分重要的，因为多个类型（从相同的基础类型中衍生出来）可被当作同一种类型对待。而且只需一段代码，即可对所有不同的类型进行同样的处理。利用具有多态性的方法调用，一种类型可将自己与另一种相似的类型区分开，只要它们都是从相同的基础类型中衍生出来的。这种区分是通过各种方法在行为上的差异实现的，可通过基础类实现对那些方法的调用。
 
 在这一章中，大家要由浅入深地学习有关多态性的问题（也叫作动态绑定、推迟绑定或者运行期绑定）。同时举一些简单的例子，其中所有无关的部分都已剥除，只保留与多态性有关的代码。

第9章 违例差错控制.md

@@ -14,4 +14,4 @@ Java的基本原理就是“形式错误的代码不会运行”。
 
 异常机制的另一项好处就是能够简化错误控制代码。我们再也不用检查一个特定的错误，然后在程序的多处地方对其进行控制。此外，也不需要在方法调用的时候检查错误（因为保证有人能捕获这里的错误）。我们只需要在一个地方处理问题：“异常控制模块”或者“异常控制器”。这样可有效减少代码量，并将那些用于描述具体操作的代码与专门纠正错误的代码分隔开。一般情况下，用于读取、写入以及调试的代码会变得更富有条理。
 
-由于异常控制是由Java编译器强行实施的，所以毋需深入学习异常控制，便可正确使用本书编写的大量例子。本章向大家介绍了用于正确控制异常所需的代码，以及在某个方法遇到麻烦的时候，该如何生成自己的异常。
+由于异常控制是由Java编译器强行实现的，所以毋需深入学习异常控制，便可正确使用本书编写的大量例子。本章向大家介绍了用于正确控制异常所需的代码，以及在某个方法遇到麻烦的时候，该如何生成自己的异常。

附录A 使用非JAVA代码.md

@@ -419,7 +419,7 @@ A.3.4 编写回调函数
 
 另一个例子是API函数EnumWindows()，它能枚举目前系统内所有顶级窗口。EnumWindows()要求获取一个函数指针作为自己的参数，然后搜索由Windows内部维护的一个列表。对于列表内的每个窗口，它都会调用回调函数，将窗口引用作为一个参数传给回调。
 
-为了在Java里达到同样的目的，必须使用com.ms.dll包里的Callback类。我们从Callback里继承，并取消callback()。这个方法只能接近int参数，并会返回int或void。方法签名和具体的实施取决于使用这个回调的Windows API函数。
+为了在Java里达到同样的目的，必须使用com.ms.dll包里的Callback类。我们从Callback里继承，并取消callback()。这个方法只能接近int参数，并会返回int或void。方法签名和具体的实现取决于使用这个回调的Windows API函数。
 现在，我们要进行的全部工作就是创建这个Callback衍生类的一个实例，并将其作为函数指针传递给API函数。随后，J/Direct会帮助我们自动完成剩余的工作。
 
 下面这个例子调用了Win32 API函数EnumWindows()；EnumWindowsProc类里的callback()方法会获取每个顶级窗口的引用，获取标题文字，并将其打印到控制台窗口。
@@ -534,7 +534,7 @@ Java和COM最引人注目的相似之处就是COM接口与Java的“interface”
 
 ■COM对象揭示出了接口（也只有接口）
 
-■COM接口本身并不具备实施方案；要由揭示出接口的那个COM对象负责它的实施
+■COM接口本身并不具备实现方案；要由揭示出接口的那个COM对象负责它的实现
 
 ■COM接口是对语义上相关的一组函数的说明；不会揭示出任何数据
 
@@ -551,7 +551,7 @@ COM很好的对应（映射）关系。Java是两者之间一种很好的折衷
 
 A.5.1 COM基础
 
-COM是一种二进制规范，致力于实施可相互操作的对象。例如，COM认为一个对象的二进制布局必须能够调用另一个COM对象里的服务。由于是对二进制布局的一种描述，所以只要某种语言能生成这样的一种布局，就可通过它实现COM对象。通常，程序员不必关注象这样的一些低级细节，因为编译器可自动生成正确的布局。例如，假设您的程序是用C++写的，那么大多数编译器都能生成符合COM规范的一张虚拟函数表格。对那些不生成可执行代码的语言，比如VB和Java，在运行期则会自动挂接到COM。
+COM是一种二进制规范，致力于实现可相互操作的对象。例如，COM认为一个对象的二进制布局必须能够调用另一个COM对象里的服务。由于是对二进制布局的一种描述，所以只要某种语言能生成这样的一种布局，就可通过它实现COM对象。通常，程序员不必关注象这样的一些低级细节，因为编译器可自动生成正确的布局。例如，假设您的程序是用C++写的，那么大多数编译器都能生成符合COM规范的一张虚拟函数表格。对那些不生成可执行代码的语言，比如VB和Java，在运行期则会自动挂接到COM。
 COM库也提供了几个基本的函数，比如用于创建对象或查找系统中一个已注册COM类的函数。
 
 一个组件对象模型的基本目标包括：

附录C Java编程规则.md

@@ -60,7 +60,7 @@ implement Serializable
 
 (17) 创建大小固定的对象集合时，请将它们传输至一个数组（若准备从一个方法里返回这个集合，更应如此操作）。这样一来，我们就可享受到数组在编译期进行类型检查的好处。此外，为使用它们，数组的接收者也许并不需要将对象“转换”到数组里。
 
-(18) 尽量使用interfaces，不要使用abstract类。若已知某样东西准备成为一个基础类，那么第一个选择应是将其变成一个interface（接口）。只有在不得不使用方法定义或者成员变量的时候，才需要将其变成一个abstract（抽象）类。接口主要描述了客户希望做什么事情，而一个类则致力于（或允许）具体的实施细节。
+(18) 尽量使用interfaces，不要使用abstract类。若已知某样东西准备成为一个基础类，那么第一个选择应是将其变成一个interface（接口）。只有在不得不使用方法定义或者成员变量的时候，才需要将其变成一个abstract（抽象）类。接口主要描述了客户希望做什么事情，而一个类则致力于（或允许）具体的实现细节。
 
 (19) 在构造器内部，只进行那些将对象设为正确状态所需的工作。尽可能地避免调用其他方法，因为那些方法可能被其他人覆盖或取消，从而在构建过程中产生不可预知的结果（参见第7章的详细说明）。
 
@@ -82,7 +82,7 @@ implement Serializable
 
 (28) 请记住，阅读代码的时间比写代码的时间多得多。思路清晰的设计可获得易于理解的程序，但注释、细致的解释以及一些示例往往具有不可估量的价值。无论对你自己，还是对后来的人，它们都是相当重要的。如对此仍有怀疑，那么请试想自己试图从联机Java文档里找出有用信息时碰到的挫折，这样或许能将你说服。
 
-(29) 如认为自己已进行了良好的分析、设计或者实施，那么请稍微更换一下思维角度。试试邀请一些外来人士——并不一定是专家，但可以是来自本公司其他部门的人。请他们用完全新鲜的眼光考察你的工作，看看是否能找出你一度熟视无睹的问题。采取这种方式，往往能在最适合修改的阶段找出一些关键性的问题，避免产品发行后再解决问题而造成的金钱及精力方面的损失。
+(29) 如认为自己已进行了良好的分析、设计或者实现，那么请稍微更换一下思维角度。试试邀请一些外来人士——并不一定是专家，但可以是来自本公司其他部门的人。请他们用完全新鲜的眼光考察你的工作，看看是否能找出你一度熟视无睹的问题。采取这种方式，往往能在最适合修改的阶段找出一些关键性的问题，避免产品发行后再解决问题而造成的金钱及精力方面的损失。
 
 (30) 良好的设计能带来最大的回报。简言之，对于一个特定的问题，通常会花较长的时间才能找到一种最恰当的解决方案。但一旦找到了正确的方法，以后的工作就轻松多了，再也不用经历数小时、数天或者数月的痛苦挣扎。我们的努力工作会带来最大的回报（甚至无可估量）。而且由于自己倾注了大量心血，最终获得一个出色的设计模式，成功的快感也是令人心动的。坚持抵制草草完工的诱惑——那样做往往得不偿失。
 

附录E 关于垃圾收集的一些话.md

@@ -7,11 +7,11 @@
 
 我之所以想到速度，部分原因是由于C++模型。C++将自己的主要精力放在编译期间“静态”发生的所有事情上，所以程序的运行期版本非常短小和快速。C++也直接建立在C模型的基础上（主要为了向后兼容），但有时仅仅由于它在C中能按特定的方式工作，所以也是C++中最方便的一种方法。最重要的一种情况是C和C++对内存的管理方式，它是某些人觉得Java速度肯定慢的重要依据：在Java中，所有对象都必须在内存“堆”里创建。
 
-而在C++中，对象是在堆栈中创建的。这样可达到更快的速度，因为当我们进入一个特定的作用域时，堆栈指针会向下移动一个单位，为那个作用域内创建的、以堆栈为基础的所有对象分配存储空间。而当我们离开作用域的时候（调用完毕所有局部构造器后），堆栈指针会向上移动一个单位。然而，在C++里创建“内存堆”（Heap）对象通常会慢得多，因为它建立在C的内存堆基础上。这种内存堆实际是一个大的内存池，要求必须进行再循环（再生）。在C++里调用delete以后，释放的内存会在堆里留下一个洞，所以再调用new的时候，存储分配机制必须进行某种形式的搜索，使对象的存储与堆内任何现成的洞相配，否则就会很快用光堆的存储空间。之所以内存堆的分配会在C++里对性能造成如此重大的性能影响，对可用内存的搜索正是一个重要的原因。所以创建基于堆栈的对象要快得多。
+而在C++中，对象是在堆栈中创建的。这样可达到更快的速度，因为当我们进入一个特定的作用域时，堆栈指针会向下移动一个单位，为那个作用域内创建的、以堆栈为基础的所有对象分配存储空间。而当我们离开作用域的时候（调用完毕所有局部构造器后），堆栈指针会向上移动一个单位。然而，在C++里创建“内存堆”（Heap）对象通常会慢得多，因为它建立在C的内存堆基础上。这种内存堆实际是一个大的内存池，要求必须进行再循环（复用）。在C++里调用delete以后，释放的内存会在堆里留下一个洞，所以再调用new的时候，存储分配机制必须进行某种形式的搜索，使对象的存储与堆内任何现成的洞相配，否则就会很快用光堆的存储空间。之所以内存堆的分配会在C++里对性能造成如此重大的性能影响，对可用内存的搜索正是一个重要的原因。所以创建基于堆栈的对象要快得多。
 
 同样地，由于C++如此多的工作都在编译期间进行，所以必须考虑这方面的因素。但在Java的某些地方，事情的发生却要显得“动态”得多，它会改变模型。创建对象的时候，垃圾收集器的使用对于提高对象创建的速度产生了显著的影响。从表面上看，这种说法似乎有些奇怪——存储空间的释放会对存储空间的分配造成影响，但它正是JVM采取的重要手段之一，这意味着在Java中为堆对象分配存储空间几乎能达到与C++中在堆栈里创建存储空间一样快的速度。
 
-可将C++的堆（以及更慢的Java堆）想象成一个庭院，每个对象都拥有自己的一块地皮。在以后的某个时间，这种“不动产”会被抛弃，而且必须再生。但在某些JVM里，Java堆的工作方式却是颇有不同的。它更象一条传送带：每次分配了一个新对象后，都会朝前移动。这意味着对象存储空间的分配可以达到非常快的速度。“堆指针”简单地向前移至处女地，所以它与C++的堆栈分配方式几乎是完全相同的（当然，在数据记录上会多花一些开销，但要比搜索存储空间快多了）。
+可将C++的堆（以及更慢的Java堆）想象成一个庭院，每个对象都拥有自己的一块地皮。在以后的某个时间，这种“不动产”会被抛弃，而且必须复用。但在某些JVM里，Java堆的工作方式却是颇有不同的。它更象一条传送带：每次分配了一个新对象后，都会朝前移动。这意味着对象存储空间的分配可以达到非常快的速度。“堆指针”简单地向前移至处女地，所以它与C++的堆栈分配方式几乎是完全相同的（当然，在数据记录上会多花一些开销，但要比搜索存储空间快多了）。
 
 现在，大家可能注意到了堆事实并非一条传送带。如按那种方式对待它，最终就要求进行大量的页交换（这对性能的发挥会产生巨大干扰），这样终究会用光内存，出现内存分页错误。所以这儿必须采取一个技巧，那就是著名的“垃圾收集器”。它在收集“垃圾”的同时，也负责压缩堆里的所有对象，将“堆指针”移至尽可能靠近传送带开头的地方，远离发生（内存）分页错误的地点。垃圾收集器会重新安排所有东西，使其成为一个高速、无限自由的堆模型，同时游刃有余地分配存储空间。