表面上看起来，无论语法还是应用的环境（比如容器类），泛型类型（或者泛型）都类似于 C++ 中的模板。但是这种相似性仅限于表面，Java 语言中的泛型基本上完全在编译器中实现，由编译器执行类型检查和类型推断，然后生成普通的非泛型的字节码。这种实现技术称为擦除（erasure）（编译器使用泛型类型信息保证类型安全，然后在生成字节码之前将其清除），这项技术有一些奇怪，并且有时会带来一些令人迷惑的后果。虽然范型是 Java 类走向类型安全的一大步，但是在学习使用泛型的过程中几乎肯定会遇到头痛（有时候让人无法忍受）的问题。

注意：本文假设您对 JDK 5.0 中的范型有基本的了解。

泛型不是协变的

虽然将集合看作是数组的抽象会有所帮助，但是数组还有一些集合不具备的特殊性质。Java 语言中的数组是协变的（covariant），也就是说，如果 Integer 扩展了 Number（事实也是如此），那么不仅 Integer 是 Number，而且 Integer[] 也是 Number[]，在要求 Number[] 的地方完全可以传递或者赋予 Integer[]。（更正式地说，如果 Number 是 Integer 的超类型，那么 Number[] 也是 Integer[] 的超类型）。您也许认为这一原理同样适用于泛型类型 —— List<Number> 是 List<Integer> 的超类型，那么可以在需要 List<Number> 的地方传递 List<Integer>。不幸的是，情况并非如此。

不允许这样做有一个很充分的理由：这样做将破坏要提供的类型安全泛型。如果能够将 List<Integer> 赋给 List<Number>。那么下面的代码就允许将非 Integer 的内容放入 List<Integer>：

List<Integer> li = new ArrayList<Integer>();
            List<Number> ln = li; // illegal
            ln.add(new Float(3.1415));
            

因为 ln 是 List<Number>，所以向其添加 Float 似乎是完全合法的。但是如果 ln 是 li 的别名，那么这就破坏了蕴含在 li 定义中的类型安全承诺 —— 它是一个整数列表，这就是泛型类型不能协变的原因。

其他的协变问题

数组能够协变而泛型不能协变的另一个后果是，不能实例化泛型类型的数组（new List<String>[3] 是不合法的），除非类型参数是一个未绑定的通配符（new List<?>[3] 是合法的）。让我们看看如果允许声明泛型类型数组会造成什么后果：

List<String>[] lsa = new List<String>[10]; // illegal
            Object[] oa = lsa;  // OK because List<String> is a subtype of Object
            List<Integer> li = new ArrayList<Integer>();
            li.add(new Integer(3));
            oa[0] = li;
            String s = lsa[0].get(0);
            

最后一行将抛出 ClassCastException，因为这样将把 List<Integer> 填入本应是 List<String> 的位置。因为数组协变会破坏泛型的类型安全，所以不允许实例化泛型类型的数组（除非类型参数是未绑定的通配符，比如 List<?>）。

回页首

构造延迟

因为可以擦除功能，所以 List<Integer> 和 List<String> 是同一个类，编译器在编译 List<V> 时只生成一个类（和 C++ 不同）。因此，在编译 List<V> 类时，编译器不知道 V 所表示的类型，所以它就不能像知道类所表示的具体类型那样处理 List<V> 类定义中的类型参数（List<V> 中的 V）。

因为运行时不能区分 List<String> 和 List<Integer>（运行时都是 List），用泛型类型参数标识类型的变量的构造就成了问题。运行时缺乏类型信息，这给泛型容器类和希望创建保护性副本的泛型类提出了难题。

比如泛型类 Foo：

class Foo<T> {
            public void doSomething(T param) { ... }
            }
            

假设 doSomething() 方法希望复制输入的 param 参数，会怎么样呢？没有多少选择。您可能希望按以下方式实现 doSomething()：

public void doSomething(T param) {
            T copy = new T(param);  // illegal
            }
            

但是您不能使用类型参数访问构造函数，因为在编译的时候还不知道要构造什么类，因此也就不知道使用什么构造函数。使用泛型不能表达“T 必须拥有一个拷贝构造函数（copy constructor）”（甚至一个无参数的构造函数）这类约束，因此不能使用泛型类型参数所表示的类的构造函数。

clone() 怎么样呢？假设在 Foo 的定义中，T 扩展了 Cloneable：

class Foo<T extends Cloneable> {
            public void doSomething(T param) {
            T copy = (T) param.clone();  // illegal
            }
            }
            

不幸的是，仍然不能调用 param.clone()。为什么呢？因为 clone() 在 Object 中是保护访问的，调用 clone() 必须通过将 clone() 改写公共访问的类引用来完成。但是重新声明 clone() 为 public 并不知道 T，因此克隆也无济于事。

构造通配符引用

因此，不能复制在编译时根本不知道是什么类的类型引用。那么使用通配符类型怎么样？假设要创建类型为 Set<?> 的参数的保护性副本。您知道 Set 有一个拷贝构造函数。而且别人可能曾经告诉过您，如果不知道要设置的内容的类型，最好使用 Set<?> 代替原始类型的 Set，因为这种方法引起的未检查类型转换警告更少。于是，可以试着这样写：

class Foo {
            public void doSomething(Set<?> set) {
            Set<?> copy = new HashSet<?>(set);  // illegal
            }
            }
            

不幸的是，您不能用通配符类型的参数调用泛型构造函数，即使知道存在这样的构造函数也不行。不过您可以这样做：

class Foo {
            public void doSomething(Set<?> set) {
            Set<?> copy = new HashSet<Object>(set);
            }
            }
            

这种构造不那么直观，但它是类型安全的，而且可以像 new HashSet<?>(set) 那样工作。

构造数组

如何实现 ArrayList<V>？假设类 ArrayList 管理一个 V 数组，您可能希望用 ArrayList<V> 的构造函数创建一个 V 数组：

class ArrayList<V> {
            private V[] backingArray;
            public ArrayList() {
            backingArray = new V[DEFAULT_SIZE]; // illegal
            }
            }
            

但是这段代码不能工作 —— 不能实例化用类型参数表示的类型数组。编译器不知道 V 到底表示什么类型，因此不能实例化 V 数组。

Collections 类通过一种别扭的方法绕过了这个问题，在 Collections 类编译时会产生类型未检查转换的警告。ArrayList 具体实现的构造函数如下：

class ArrayList<V> {
            private V[] backingArray;
            public ArrayList() {
            backingArray = (V[]) new Object[DEFAULT_SIZE];
            }
            }
            

为何这些代码在访问 backingArray 时没有产生 ArrayStoreException 呢？无论如何，都不能将 Object 数组赋给 String 数组。因为泛型是通过擦除实现的，backingArray 的类型实际上就是 Object[]，因为 Object 代替了 V。这意味着：实际上这个类期望 backingArray 是一个 Object 数组，但是编译器要进行额外的类型检查，以确保它包含 V 类型的对象。所以这种方法很奏效，但是非常别扭，因此不值得效仿（甚至连泛型 Collections 框架的作者都这么说，请参阅参考资料）。

还有一种方法就是声明 backingArray 为 Object 数组，并在使用它的各个地方强制将它转化为 V[]。仍然会看到类型未检查转换警告（与上一种方法一样），但是它使一些未明确的假设更清楚了（比如 backingArray 不应逃避 ArrayList 的实现）。

其他方法

最好的办法是向构造函数传递类文字（Foo.class），这样，该实现就能在运行时知道 T 的值。不采用这种方法的原因在于向后兼容性 —— 新的泛型集合类不能与 Collections 框架以前的版本兼容。

下面的代码中 ArrayList 采用了以下方法：

public class ArrayList<V> implements List<V> {
            private V[] backingArray;
            private Class<V> elementType;
            public ArrayList(Class<V> elementType) {
            this.elementType = elementType;
            backingArray = (V[]) Array.newInstance(elementType, DEFAULT_LENGTH);
            }
            }
            

但是等一等！仍然有不妥的地方，调用 Array.newInstance() 时会引起未经检查的类型转换。为什么呢？同样是由于向后兼容性。Array.newInstance() 的签名是：

public static Object newInstance(Class<?> componentType, int length)
            

而不是类型安全的：

public static<T> T[] newInstance(Class<T> componentType, int length)
            

为何 Array 用这种方式进行泛化呢？同样是为了保持向后兼容。要创建基本类型的数组，如 int[]，可以使用适当的包装器类中的 TYPE 字段调用 Array.newInstance()（对于 int，可以传递 Integer.TYPE 作为类文字）。用 Class<T> 参数而不是 Class<?> 泛化 Array.newInstance()，对于引用类型有更好的类型安全，但是就不能使用 Array.newInstance() 创建基本类型数组的实例了。也许将来会为引用类型提供新的 newInstance() 版本，这样就两者兼顾了。

在这里可以看到一种模式 —— 与泛型有关的很多问题或者折衷并非来自泛型本身，而是保持和已有代码兼容的要求带来的副作用。

回页首

泛化已有的类

在转化现有的库类来使用泛型方面没有多少技巧，但与平常的情况相同，向后兼容性不会凭空而来。我已经讨论了两个例子，其中向后兼容性限制了类库的泛化。

另一种不同的泛化方法可能不存在向后兼容问题，这就是 Collections.toArray(Object[])。传入 toArray() 的数组有两个目的 —— 如果集合足够小，那么可以将其内容直接放在提供的数组中。否则，利用反射（reflection）创建相同类型的新数组来接受结果。如果从头开始重写 Collections 框架，那么很可能传递给 Collections.toArray() 的参数不是一个数组，而是一个类文字：

interface Collection<E> {
            public T[] toArray(Class<T super E> elementClass);
            }
            

因为 Collections 框架作为良好类设计的例子被广泛效仿，但是它的设计受到向后兼容性约束，所以这些地方值得您注意，不要盲目效仿。

首先，常常被混淆的泛型 Collections API 的一个重要方面是 containsAll()、removeAll() 和 retainAll() 的签名。您可能认为 remove() 和 removeAll() 的签名应该是：

interface Collection<E> {
            public boolean remove(E e);  // not really
            public void removeAll(Collection<? extends E> c);  // not really
            }
            

但实际上却是：

interface Collection<E> {
            public boolean remove(Object o);
            public void removeAll(Collection<?> c);
            }
            

为什么呢？答案同样是因为向后兼容性。x.remove(o) 的接口表明“如果 o 包含在 x 中，则删除它，否则什么也不做。”如果 x 是一个泛型集合，那么 o 不一定与 x 的类型参数兼容。如果 removeAll() 被泛化为只有类型兼容时才能调用（Collection<? extends E>），那么在泛化之前，合法的代码序列就会变得不合法，比如：

// a collection of Integers
            Collection c = new HashSet();
            // a collection of Objects
            Collection r = new HashSet();
            c.removeAll(r);
            

如果上述片段用直观的方法泛化（将 c 设为 Collection<Integer>，r 设为 Collection<Object>），如果 removeAll() 的签名要求其参数为 Collection<? extends E> 而不是 no-op，那么就无法编译上面的代码。泛型类库的一个主要目标就是不打破或者改变已有代码的语义，因此，必须用比从头重新设计泛型所使用类型约束更弱的类型约束来定义 remove()、removeAll()、retainAll() 和 containsAll()。

在泛型之前设计的类可能阻碍了“显然的”泛型化方法。这种情况下就要像上例这样进行折衷，但是如果从头设计新的泛型类，理解 Java 类库中的哪些东西是向后兼容的结果很有意义，这样可以避免不适当的模仿。

回页首

擦除的实现

因为泛型基本上都是在 Java 编译器中而不是运行库中实现的，所以在生成字节码的时候，差不多所有关于泛型类型的类型信息都被“擦掉”了。换句话说，编译器生成的代码与您手工编写的不用泛型、检查程序的类型安全后进行强制类型转换所得到的代码基本相同。与 C++ 不同，List<Integer> 和 List<String> 是同一个类（虽然是不同的类型但都是 List<?> 的子类型，与以前的版本相比，在 JDK 5.0 中这是一个更重要的区别）。

擦除意味着一个类不能同时实现 Comparable<String> 和 Comparable<Number>，因为事实上两者都在同一个接口中，指定同一个 compareTo() 方法。声明 DecimalString 类以便与 String 与 Number 比较似乎是明智的，但对于 Java 编译器来说，这相当于对同一个方法进行了两次声明：

public class DecimalString implements Comparable<Number>, Comparable<String> { ... } // nope
            

擦除的另一个后果是，对泛型类型参数是用强制类型转换或者 instanceof 毫无意义。下面的代码完全不会改善代码的类型安全性：

public <T> T naiveCast(T t, Object o) { return (T) o; }
            

编译器仅仅发出一个类型未检查转换警告，因为它不知道这种转换是否安全。naiveCast() 方法实际上根本不作任何转换，T 直接被替换为 Object，与期望的相反，传入的对象被强制转换为 Object。

擦除也是造成上述构造问题的原因，即不能创建泛型类型的对象，因为编译器不知道要调用什么构造函数。如果泛型类需要构造用泛型类型参数来指定类型的对象，那么构造函数应该接受类文字（Foo.class）并将它们保存起来，以便通过反射创建实例。

回页首

结束语

泛型是 Java 语言走向类型安全的一大步，但是泛型设施的设计和类库的泛化并非未经过妥协。扩展虚拟机指令集来支持泛型被认为是无法接受的，因为这会为 Java 厂商升级其 JVM 造成难以逾越的障碍。因此采用了可以完全在编译器中实现的擦除方法。类似地，在泛型 Java 类库时，保持向后兼容也为类库的泛化方式设置了很多限制，产生了一些混乱的、令人沮丧的结构（如 Array.newInstance()）。这并非泛型本身的问题，而是与语言的演化与兼容有关。但这些也使得泛型学习和应用起来更让人迷惑，更加困难。

1.1 字符与编码的发展

从计算机对多国语言的支持角度看，大致可以分为三个阶段：

字符串在内存中的存放方法：

在 ASCII 阶段，单字节字符串使用一个字节存放一个字符（SBCS）。比如，"Bob123" 在内存中为：

42	6F	62	31	32	33	00
B	o	b	1	2	3	\0

在使用 ANSI 编码支持多种语言阶段，每个字符使用一个字节或多个字节来表示（MBCS），因此，这种方式存放的字符也被称作多字节字符。比如，"中文123" 在中文 Windows 95 内存中为7个字节，每个汉字占2个字节，每个英文和数字字符占1个字节：

D6	D0	CE	C4	31	32	33	00
中		文		1	2	3	\0

在 UNICODE 被采用之后，计算机存放字符串时，改为存放每个字符在 UNICODE 字符集中的序号。目前计算机一般使用 2 个字节（16 位）来存放一个序号（DBCS），因此，这种方式存放的字符也被称作宽字节字符。比如，字符串 "中文123" 在 Windows 2000 下，内存中实际存放的是 5 个序号：

2D	4E	87	65	31	00	32	00	33	00	00	00	← 在 x86 CPU 中，低字节在前
中		文		1		2		3		\0

一共占 10 个字节。

回页首

1.2 字符，字节，字符串

理解编码的关键，是要把字符的概念和字节的概念理解准确。这两个概念容易混淆，我们在此做一下区分：

由于不同 ANSI 编码所规定的标准是不相同的，因此，对于一个给定的多字节字符串，我们必须知道它采用的是哪一种编码规则，才能够知道它包含了哪些“字符”。而对于 UNICODE 字符串来说，不管在什么环境下，它所代表的“字符”内容总是不变的。

回页首

1.3 字符集与编码

各个国家和地区所制定的不同 ANSI 编码标准中，都只规定了各自语言所需的“字符”。比如：汉字标准（GB2312）中没有规定韩国语字符怎样存储。这些 ANSI 编码标准所规定的内容包含两层含义：

1. 使用哪些字符。也就是说哪些汉字，字母和符号会被收入标准中。所包含“字符”的集合就叫做“字符集”。
2. 规定每个“字符”分别用一个字节还是多个字节存储，用哪些字节来存储，这个规定就叫做“编码”。

各个国家和地区在制定编码标准的时候，“字符的集合”和“编码”一般都是同时制定的。因此，平常我们所说的“字符集”，比如：GB2312, GBK, JIS 等，除了有“字符的集合”这层含义外，同时也包含了“编码”的含义。

“UNICODE 字符集”包含了各种语言中使用到的所有“字符”。用来给 UNICODE 字符集编码的标准有很多种，比如：UTF-8, UTF-7, UTF-16, UnicodeLittle, UnicodeBig 等。

回页首

1.4 常用的编码简介

简单介绍一下常用的编码规则，为后边的章节做一个准备。在这里，我们根据编码规则的特点，把所有的编码分成三类：

我们实际上没有必要去深究每一种编码具体把某一个字符编码成了哪几个字节，我们只需要知道“编码”的概念就是把“字符”转化成“字节”就可以了。对于“UNICODE 编码”，由于它们是可以通过计算得到的，因此，在特殊的场合，我们可以去了解某一种“UNICODE 编码”是怎样的规则。

回页首

2. 字符与编码在程序中的实现

2.1 程序中的字符与字节

在 C++ 和 Java 中，用来代表“字符”和“字节”的数据类型，以及进行编码的方法：

以上需要注意几点：

1. Java 中的 char 代表一个“UNICODE 字符（宽字节字符）”，而 C++ 中的 char 代表一个字节。
2. MultiByteToWideChar() 和 WideCharToMultiByte() 是 Windows API 函数。

回页首

2.2 C++ 中相关实现方法

声明一段字符串常量：

UNICODE 字符串的 I/O 操作，字符与字节的转换操作：

在 Visual C++ 中，UNICODE 字符串常量有更简单的表示方法。如果源程序的编码与当前默认 ANSI 编码不符，则需要使用 #pragma setlocale，告诉编译器源程序使用的编码：

以上需要注意 #pragma setlocale 与 setlocale(LC_ALL, "") 的作用是不同的，#pragma setlocale 在编译时起作用，setlocale() 在运行时起作用。

回页首

2.3 Java 中相关实现方法

字符串类 String 中的内容是 UNICODE 字符串：

字符串 I/O 操作，字符与字节转换操作。在 Java 包 java.io.* 中，以“Stream”结尾的类一般是用来操作“字节串”的类，以“Reader”，“Writer”结尾的类一般是用来操作“字符串”的类。

如果 java 的源程序编码与当前默认 ANSI 编码不符，则在编译的时候，需要指明一下源程序的编码。比如：

以上需要注意区分源程序的编码与 I/O 操作的编码，前者是在编译时起作用，后者是在运行时起作用。

回页首

3. 几种误解，以及乱码产生的原因和解决办法

3.1 容易产生的误解

第一种误解，往往是导致乱码产生的原因。第二种误解，往往导致本来容易纠正的乱码问题变得更复杂。

在这里，我们可以看到，其中所讲的“误解一”，即采用每“一个字节”就是“一个字符”的转化方法，实际上也就等同于采用 iso-8859-1 进行转化。因此，我们常常使用 bytes = string.getBytes("iso-8859-1") 来进行逆向操作，得到原始的“字节串”。然后再使用正确的 ANSI 编码，比如 string = new String(bytes, "GB2312")，来得到正确的“UNICODE 字符串”。

回页首

3.2 非 UNICODE 程序在不同语言环境间移植时的乱码

非 UNICODE 程序中的字符串，都是以某种 ANSI 编码形式存在的。如果程序运行时的语言环境与开发时的语言环境不同，将会导致 ANSI 字符串的显示失败。

比如，在日文环境下开发的非 UNICODE 的日文程序界面，拿到中文环境下运行时，界面上将显示乱码。如果这个日文程序界面改为采用 UNICODE 来记录字符串，那么当在中文环境下运行时，界面上将可以显示正常的日文。

由于客观原因，有时候我们必须在中文操作系统下运行非 UNICODE 的日文软件，这时我们可以采用一些工具，比如，南极星，AppLocale 等，暂时的模拟不同的语言环境。

回页首

3.3 网页提交字符串

当页面中的表单提交字符串时，首先把字符串按照当前页面的编码，转化成字节串。然后再将每个字节转化成 "%XX" 的格式提交到 Web 服务器。比如，一个编码为 GB2312 的页面，提交 "中" 这个字符串时，提交给服务器的内容为 "%D6%D0"。

在服务器端，Web 服务器把收到的 "%D6%D0" 转化成 [0xD6, 0xD0] 两个字节，然后再根据 GB2312 编码规则得到 "中" 字。

在 Tomcat 服务器中，request.getParameter() 得到乱码时，常常是因为前面提到的“误解一”造成的。默认情况下，当提交 "%D6%D0" 给 Tomcat 服务器时，request.getParameter() 将返回 [0x00D6, 0x00D0] 两个 UNICODE 字符，而不是返回一个 "中" 字符。因此，我们需要使用 bytes = string.getBytes("iso-8859-1") 得到原始的字节串，再用 string = new String(bytes, "GB2312") 重新得到正确的字符串 "中"。

回页首

3.4 从数据库读取字符串

通过数据库客户端（比如 ODBC 或 JDBC）从数据库服务器中读取字符串时，客户端需要从服务器获知所使用的 ANSI 编码。当数据库服务器发送字节流给客户端时，客户端负责将字节流按照正确的编码转化成 UNICODE 字符串。

如果从数据库读取字符串时得到乱码，而数据库中存放的数据又是正确的，那么往往还是因为前面提到的“误解一”造成的。解决的办法还是通过 string = new String( string.getBytes("iso-8859-1"), "GB2312") 的方法，重新得到原始的字节串，再重新使用正确的编码转化成字符串。

回页首

3.5 电子邮件中的字符串

当一段 Text 或者 HTML 通过电子邮件传送时，发送的内容首先通过一种指定的字符编码转化成“字节串”，然后再把“字节串”通过一种指定的传输编码（Content-Transfer-Encoding）进行转化得到另一串“字节串”。比如，打开一封电子邮件源代码，可以看到类似的内容：

最常用的 Content-Transfer-Encoding 有 Base64 和 Quoted-Printable 两种。在对二进制文件或者中文文本进行转化时，Base64 得到的“字节串”比 Quoted-Printable 更短。在对英文文本进行转化时，Quoted-Printable 得到的“字节串”比 Base64 更短。

邮件的标题，用了一种更简短的格式来标注“字符编码”和“传输编码”。比如，标题内容为 "中"，则在邮件源代码中表示为：

其中，

• 第一个“=?”与“?”中间的部分指定了字符编码，在这个例子中指定的是 GB2312。
• “?”与“?”中间的“B”代表 Base64。如果是“Q”则代表 Quoted-Printable。
• 最后“?”与“?=”之间的部分，就是经过 GB2312 转化成字节串，再经过 Base64 转化后的标题内容。

如果“传输编码”改为 Quoted-Printable，同样，如果标题内容为 "中"：

如果阅读邮件时出现乱码，一般是因为“字符编码”或“传输编码”指定有误，或者是没有指定。比如，有的发邮件组件在发送邮件时，标题 "中"：

这样的表示，实际上是明确指明了标题为 [0x00D6, 0x00D0]，即 "ÖÐ"，而不是 "中"。

回页首

4. 几种错误理解的纠正

误解：“ISO-8859-1 是国际编码？”

非也。iso-8859-1 只是单字节字符集中最简单的一种，也就是“字节编号”与“UNICODE 字符编号”一致的那种编码规则。当我们要把一个“字节串”转化成“字符串”，而又不知道它是哪一种 ANSI 编码时，先暂时地把“每一个字节”作为“一个字符”进行转化，不会造成信息丢失。然后再使用 bytes = string.getBytes("iso-8859-1") 的方法可恢复到原始的字节串。

误解：“Java 中，怎样知道某个字符串的内码？”

Java 中，字符串类 java.lang.String 处理的是 UNICODE 字符串，不是 ANSI 字符串。我们只需要把字符串作为“抽象的符号的串”来看待。因此不存在字符串的内码的问题。

异常转型在上面已经提到过了，实际上就是捕获到异常后，将异常以新的类型的异常再抛出，这样做一般为了异常的信息更直观！比如：
public void run() throws MyException{
 ...
 try{
  ...
 }catch(IOException e){
  ...
  throw new MyException();
 }finally{
  ...
 }
}

        异常链，在JDK1.4以后版本中，Throwable类支持异常链机制。Throwable 包含了其线程创建时线程执行堆栈的快照。它还包含了给出有关错误更多信息的消息字符串。最后，它还可以包含 cause（原因）：另一个导致此 throwable 抛出的 throwable。它也称为异常链 设施，因为 cause 自身也会有 cause，依此类推，就形成了异常链，每个异常都是由另一个异常引起的。 
        通俗的说，异常链就是把原始的异常包装为新的异常类，并在新的异常类中封装了原始异常类，这样做的目的在于找到异常的根本原因。

        通过Throwable的两个构造方法可以创建自定义的包含异常原因的异常类型：
Throwable(String message, Throwable cause)
          构造一个带指定详细消息和 cause 的新 throwable。
Throwable(Throwable cause)
          构造一个带指定 cause 和 (cause==null ? null :cause.toString())（它通常包含类和 cause 的详细消息）的详细消息的新 throwable。
getCause()
          返回此 throwable 的 cause；如果 cause 不存在或未知，则返回 null。
initCause(Throwable cause)
          将此 throwable 的 cause 初始化为指定值。

        在Throwable的子类Exception中，也有类似的指定异常原因的构造方法：
Exception(String message, Throwable cause)
          构造带指定详细消息和原因的新异常。
Exception(Throwable cause)
          根据指定的原因和 (cause==null ? null : cause.toString()) 的详细消息构造新异常（它通常包含 cause 的类和详细消息）。
因此，可以通过扩展Exception类来构造带有异常原因的新的异常类。

七、Java异常处理的原则和技巧

1、避免过大的try块，不要把不会出现异常的代码放到try块里面，尽量保持一个try块对应一个或多个异常。
2、细化异常的类型，不要不管什么类型的异常都写成Excetpion。
3、catch块尽量保持一个块捕获一类异常，不要忽略捕获的异常，捕获到后要么处理，要么转译，要么重新抛出新类型的异常。
4、不要把自己能处理的异常抛给别人。
5、不要用try...catch参与控制程序流程，异常控制的根本目的是处理程序的非正常情况。

public class Throwable

Throwable 类是 Java 语言中所有错误或异常的超类。只有当对象是此类（或其子类之一）的实例时，才能通过 Java 虚拟机或者 Java throw 语句抛出。类似地，只有此类或其子类之一才可以是 catch 子句中的参数类型。

两个子类的实例，Error 和 Exception，通常用于指示发生了异常情况。通常，这些实例是在异常情况的上下文中新近创建的，因此包含了相关的信息（比如堆栈跟踪数据）。

Throwable 包含了其线程创建时线程执行堆栈的快照。它还包含了给出有关错误更多信息的消息字符串。最后，它还可以包含 cause（原因）：另一个导致此 throwable 抛出的 throwable。此 cause 设施在 1.4 版本中首次出现。它也称为异常链 设施，因为 cause 自身也会有 cause，依此类推，就形成了异常链，每个异常都是由另一个异常引起的。

导致 throwable cause 的一个理由是，抛出它的类构建在低层抽象之中，而高层操作由于低层操作的失败而失败。让低层抛出的 throwable 向外传播是一种糟糕的设计方法，因为它通常与高层提供的抽象不相关。此外，这样做将高层 API 与其实现细节关联起来，假定低层异常是经过检查的异常。抛出“经过包装的异常”（即包含 cause 的异常）允许高层与其调用方交流失败详细信息，而不会招致上述任何一个缺点。这种方式保留了改变高层实现而不改变其 API 的灵活性（尤其是，异常集合通过其方法抛出）。

导致 throwable cause 的另一个 cause 是，抛出它的方法必须符合通用接口，而通用接口不允许方法直接抛出 cause。例如，假定持久集合符合 Collection 接口，而其持久性在 java.io 的基础上实现。假定 put 方法的内部可以抛出 IOException。实现可以与其调用方交流 IOException 的详细消息，同时通过以一种合适的未检查的异常来包装 IOException，使其符合 Collection 接口。（持久集合的规范应该指示它能够抛出这种异常。）

Cause 可以通过两种方式与 throwable 关联起来：通过一个将 cause 看作参数的构造方法；或者通过 initCause(Throwable) 方法。对于那些希望将 cause 与其关联起来的新 throwable 类，应该提供带有 cause 的构造方法，并委托（可能间接）给一个带有 cause 的 Throwable 构造方法。例如：

     try {
lowLevelOp();
} catch (LowLevelException le) {
throw new HighLevelException(le);  // Chaining-aware constructor
}

     try {
lowLevelOp();
} catch (LowLevelException le) {
throw (HighLevelException)
new HighLevelException().initCause(le);  // Legacy constructor
}

为理解泛型类型为何如此有用，我们要将注意力转向 Java 语言中最容易引发错误的因素之一 －需要不断地将表达式向下类型转换（downcast）为比其静态类型更为具体的数据类型。

程序中的每个向下类型转换对于 ClassCastException 而言都是潜在的危险，应当尽量避免它们。但是在 Java 语言中它们通常是无法避免的，即便在设计优良的程序中也是如此。

在 Java 语言中进行向下类型转换最常见的原因在于，经常以专用的方式来使用类，这限制了方法调用所返回的参数可能的运行时类型。例如，假定往 Hashtable 中添加元素并从中检索元素。那么在给定的程序中，被用作键的元素类型和存储在散列表中的值类型，将不能是任意对象。通常，所有的键都是某一特定类型的实例。同样地，存储的值将共同具有比 Object 更具体的公共类型。

但是在目前现有的 Java 语言版本中，不可能将散列表的特定键和元素声明为比 Object 更具体的类型。在散列表上执行插入和检索操作的类型特征符告诉我们只能插入和删除任意对象。例如， put 和 get 操作的说明如下所示：

清单 1. 插入／检索类型说明表明只能是任意对象
class Hashtable {
  Object put(Object key, Object value) {...}
  Object get(Object key) {...}
  ...
}

因此，当我们从类 Hashtable 的实例检索元素时，比如，即使我们知道在 Hashtable 中只放了 String ，而类型系统也只知道所检索的值是 Object 类型。在对检索到的值进行任何特定于 String 的操作之前，必须将它强制转换为 String ，即使是将检索到的元素添加到同一代码块中，也是如此！

清单 2. 将检索到的值强制转换成 String
import java.util.Hashtable;
class Test {
  public static void main(String[] args) {
    Hashtable h = new Hashtable();
    h.put(new Integer(0), "value");
    String s = (String)h.get(new Integer(0));
    System.out.println(s);
  }
}

请注意 main 方法主体部分的第三行中需要进行的数据类型转换。因为 Java 类型系统相当薄弱，因此代码会因象上面那样的数据类型转换而漏洞百出。这些数据类型转换不仅使 Java 代码变得更加拖沓冗长，而且它们还降低了静态类型检查的价值（因为每个数据类型转换都是一个选择忽略静态类型检查的伪指令）。我们该如何扩展该类型系统，从而不必回避它呢？

用泛型类型来解决问题！

要消除如上所述的数据类型转换，有一种普遍的方法，就是用泛型类型来增大 Java 类型系统。可以将泛型类型看作是类型“函数”；它们通过类型变量进行参数化，这些类型变量可以根据上下文用各种类型参数进行实例化。

例如，与简单地定义类 Hashtable 不同，我们可以定义泛型类 Hashtable<Key, Value> ，其中 Key 和 Value 是类型参数。除了类名后跟着尖括号括起来的一系列类型参数声明之外，在 Tiger 中定义这样的泛型类的语法和用于定义普通类的语法很相似。例如，可以按照如下所示的那样定义自己的泛型 Hashtable 类：

清单 3. 定义泛型 Hashtable 类
class Hashtable<Key, Value> { ... }

然后可以引用这些类型参数，就像我们在类定义主体内引用普通类型那样，如下所示：

清单 4. 像引用普通类型那样引用类型参数
class Hashtable<Key, Value> {
  ...
  Value put(Key k, Value v) {...}
  Value get(Key k) {...}
}

类型参数的作用域就是相应类定义的主体部分（除了静态成员之外）（在下一篇文章中，我们将讨论为何 Tiger 实现中有这样的“怪习”，即必须对静态成员进行此项限制。请留意！）。

创建一个新的 Hashtable 实例时，必须传递类型参数以指定 Key 和 Value 的类型。传递类型参数的方式取决于我们打算如何使用 Hashtable 。在上面的示例中，我们真正想要做的是创建 Hashtable 实例，它只将 Integer 映射为 String 。可以用新的 Hashtable 类来完成这件事：

清单 5. 创建将 Integer 映射为 String 的实例
import java.util.Hashtable;
class Test {
  public static void main(String[] args) {
    Hashtable<Integer, String> h = new Hashtable<Integer, String>();
    h.put(new Integer(0), "value");
    ...
  }
}
 
现在不再需要数据类型转换了。请注意用来实例化泛型类 Hashtable 的语法。就像泛型类的类型参数用尖括号括起来那样，泛型类型应用程序的参数也是用尖括号括起来的。

清单 6. 除去不必要的数据类型转换
...
String s = h.get("key");
System.out.println(s);

当然，程序员若只是为了能使用泛型类型而必须重新定义所有的标准实用程序类（比如 Hashtable 和 List ）的话，则可能会是一项浩大的工程。幸好，Tiger 为用户提供了所有 Java 集合类的泛型版本，因此我们不必自己动手来重新定义它们了。此外，这些类能与旧代码和新的泛型代码一起无缝工作。

Tiger 的基本类型限制

Tiger 中类型变量的限制之一就是，它们必须用引用类型进行实例化 －基本类型不起作用。因此，在上面这个示例中，无法完成创建从 int 映射到 String 的 Hashtable 。

这很遗憾，因为这意味着只要您想把基本类型用作泛型类型的参数，您就必须把它们组装为对象。另一方面，当前的这种情况是最糟的；您不能将 int 作为键传递给 Hashtable ，因为所有的键都必须是 Object 类型。

我们真正想看到的是，基本类型可以自动进行包装（boxing）和解包装（unboxing），类似于用 C# 所进行的操作（或者比后者更好）。遗憾的是，Tiger 不打算包括基本类型的自动包装（hiswing：jdk5.0已经带了自动装箱（Autoboxing）和自动拆箱（Auto-Unboxing））。

受限泛型

有时我们想限制可能出现的泛型类的类型实例化。在上面这个示例中，类 Hashtable 的类型参数可以用我们想用的任何类型参数进行实例化，但是对于其它某些类，我们或许想将可能的类型参数集限定为给定类型范围内的子类型。

例如，我们可能想定义泛型 ScrollPane 类，它引用普通的带有滚动条功能的 Pane 。被包含的 Pane 的运行时类型通常会是类 Pane 的子类型，但是静态类型就只是 Pane 。

有时我们想用 getter 检索被包含的 Pane ，但是希望 getter 的返回类型尽可能具体些。我们可能想将类型参数 MyPane 添加到 ScrollPane 中，该类型参数可以用 Pane 的任何子类进行实例化。然后可以用这种形式的子句： extends Bound 来说明 MyPane 的声明，从而来设定 MyPane 的范围：

清单 7. 用 extends 子句来说明 MyPane 声明
class ScrollPane<MyPane extends Pane> { ... }

当然，我们可以完全不使用显式的范围，只要能确保没有用不适当的类型来实例化类型参数。

为什么要自找麻烦在类型参数上设定范围呢？这里有两个原因。首先，范围使我们增加了静态类型检查功能。有了静态类型检查，就能保证泛型类型的每次实例化都符合所设定的范围。

其次，因为我们知道类型参数的每次实例化都是这个范围之内的子类，所以可以放心地调用类型参数实例出现在这个范围之内的任何方法。如果没有对参数设定显式的范围，那么缺省情况下范围是 Object ，这意味着我们不能调用范围实例在 Object 中未曾出现的任何方法。

多态方法

除了用类型参数对类进行参数化之外，用类型参数对方法进行参数化往往也同样很有用。泛型 Java 编程用语中，用类型进行参数化的方法被称为 多态方法（Polymorphic method）。

多态方法之所以有用，是因为有时候，在一些我们想执行的操作中，参数与返回值之间的类型相关性原本就是泛型的，但是这个泛型性质不依赖于任何类级的类型信息，而且对于各个方法调用都不相同。

例如，假定想将 factory 方法添加到 List 类中。这个静态方法只带一个参数，也将是 List 唯一的元素（直到添加了其它元素）。因为我们希望 List 成为其所包含的元素类型的泛型，所以希望静态 factory 方法带有类型变量 T 这一参数并返回 List<T> 的实例。

但是我们确实希望该类型变量 T 能在方法级别上进行声明，因为它会随每次单独的方法调用而发生改变（而且，正如我在下一篇文章中将讨论的那样，Tiger 设计的“怪习”规定静态成员不在类级类型参数的范畴之内）。Tiger 让我们通过将类型参数作为方法声明的前缀，从而在单独的方法级别上声明类型参数。例如，可以按照如下所示的那样为 factory 方法 make 添加前缀：

清单 8. 将类型参数作为前缀添加到方法声明
class Utilities {
   <T extends Object> public static List<T> make(T first) {
     return new List<T>(first);
   }
}

除了多态方法中所增加的灵活性之外，Tiger 中还增加了一个优点。Tiger 使用类型推断机制，根据参数类型来自动推断出多态方法的类型。这可以大大减少方法调用的繁琐和复杂性。例如，如果想调用 make 方法来构造包含 new Integer(0) 的 List<Integer> 新实例，那么只需编写：

清单 9. 强制 make 构造新实例
Utilities.make(Integer(0))

然后会自动地从方法参数中推断出类型参数的实例化。

结束语

正如我们所见到的那样，在 Java 语言中添加泛型类型肯定会大大增强我们使用静态类型系统的能力。学习如何使用泛型类型相当简单，但是同样也需要避免一些缺陷。在接下来的文章中，我们将讨论如何充分使用将出现在 Tiger 中的泛型类型的特定表现，以及一些缺陷。我们还将研究对泛型 Java 类型工具的扩展，我们期盼这些工具可以出现在仍处于设计阶段的 Java 平台之中。

泛型类型的限制

让我们先查阅一下 Tiger 和 JSR-14 中泛型类型的使用限制：

不应在静态成员中引用封闭类型参数。
不能用基本类型实例化泛型类型参数。
不能在数据类型转换或 instanceof 操作中使用“外露”类型参数。
不能在 new 操作中使用“外露”类型参数。
不能在类定义的 implements 或 extends 子句中使用“外露”类型参数。
为什么会有这些限制呢？这要归因于 Tiger 和 JSR-14 为在 JVM 上实现泛型类型所使用的机制。由于 JVM 根本不支持泛型类型，所以这些编译器“耍了个花招”，使得似乎存在对泛型类型的支持 ― 它们用泛型类型信息检查所有的代码，但随即“擦除”所有的泛型类型并生成只包含普通类型的类文件。

例如，将象 List<T> 这样的泛型类型擦除得只剩下 List 。“外露”类型参数 ― 单独出现而不是位于某个类型中的类型参数（如类 List<T> 中的类型参数 T ）― 被简单地擦除成它们的上界（就 T 而言，其上界就是 Object ）。

这一技术的功能极其强大；我们可以使几乎所有泛型类型的精度得到增强，但又与 JVM 保持兼容。事实上，我们甚至可以交替地使用非泛型的旧类（比如 List ）和其对应的泛型类（ List<T> ）；两者在运行时看起来是一样的。

遗憾的是，正如以上的限制所示，获得这一功能是有代价的。以这种方式进行擦除在类型系统中引入了缺陷，这些缺陷限制我们使用泛型类型的安全性。

为了帮助说明每种限制，我们查阅会出现这些限制的示例。在本文中，我们将讨论前三个限制。与后两个限制有关的问题过于复杂，因而需要更深入的研究，留待下一篇文章讨论。

静态成员中的封闭类型参数

编译器完全禁止在静态方法和静态内部类中引用封闭类型参数。所以，举例来说，以下代码在 Tiger 中就是非法的：

清单 1. 在静态上下文中非法引用封闭类型参数
class C<T> {
  static void m() {
    T t;
  }

  static class D {
    C<T> t;
  }
}

当编译这一代码时，会生成两个错误：

在静态方法 m 中非法引用 T 的错误
在静态类 D 中非法引用 T 的错误

当定义静态字段时，情况变得更加复杂。在 JSR-14 和 Tiger 中，在泛型类的所有实例中共享该类中的静态字段。现在，在 JSR-14 编译器 1.0 和 1.2 中，如果您在静态字段声明中引用类型参数，编译器不会报错，但它本应该这么做。字段被共享这一事实很容易在运行时导致奇怪的错误，如在不包含数据类型转换的代码中出现 ClassCastException 。

例如，以下程序将在这两个版本的 JSR-14 下通过编译而没有任何警告：

清单 2. 在静态字段中对封闭类型参数的有问题的引用
class C<T> {
  static T member;

  C(T t) { member = t; }

  T getMember() { return member; }

  public static void main(String[] args) {
    C<String> c = new C<String>("test");
    System.out.println(c.getMember().toString());
    new C<Integer>(new Integer(1));
    System.out.println(c.getMember().toString());
  }
}

请注意，每次分配类 C 的实例时，都要重新设置静态字段 member 。而且，它被设置成的对象类型取决于 C 的实例的类型！在所提供的 main 方法中，第一个实例 c 是 C<String> 类型。而第二个是 C<Integer> 类型。每当从 c 访问 member 这一共享静态字段时，总是假定 member 的类型是 String 。但是，在分配了类型为 C<Integer> 的第二个实例之后， member 的类型是 Integer 。

运行 C 的 main 方法的结果可能会让您吃惊 ― 它将发出一个 ClassCastException ！源代码根本没有包含任何数据类型转换，怎么会这样呢？事实证明编译器确实在编译阶段将数据类型转换插入到代码中，这样做是为了解决类型擦除会降低某些表达式的类型的精度这一事实。这些数据类型转换被期望能够成功，但在本例中却没有成功。

应该认为 JSR-14 1.0 和 1.2 的这一特殊“功能”是个错误。它破坏了类型系统的健全性，或者可以说，它破坏了类型系统应该和程序员达成的“基本契约”。象对静态方法和类所做的那样，只要防止程序员在静态字段中引用泛型类型，情况就会好很多。

请注意允许这种有潜在“爆炸性”的代码存在所带来的问题并不是程序员有意在自己的代码中覆盖类型系统。问题是程序员可能会无意中编写这样的代码（比如，由于“复制和粘贴”操作，错误地在字段声明中包括静态修饰符）。

类型检查器应该能帮助程序员从这些类型的错误中恢复，但对于静态字段而言，类型系统实际上会使程序员更迷惑。当未使用数据类型转换的代码中显示的唯一错误就是 ClassCastException 时，我们应如何诊断这样的错误？对于不清楚 Tiger 中泛型类型所用的实现方案而又恰好假定类型系统合理运行的程序员而言，情况更糟。因为在这样的情况下，类型系统不是合理地运行。

幸运的是，JSR-14 的最新版本（1.3）宣布在静态字段中使用类型参数是不合法的。因此，我们有理由期待在 Tiger 的静态字段中使用类型参数也是不合法的。

泛型类型参数和基本类型

和我们刚才讨论的不同，这一限制没有同样的潜在缺陷，但它会使您的代码非常冗长。例如，在 java.util.Hashtable 的泛型版本中，有两种类型参数：用于 Key 类型的和用于 Value 类型的。因此，如果我们想要一个将 String 映射到 String 的 Hashtable ，我们可以用表达式 new Hashtable<String, String>() 指定新的实例。但是，如果我们想要一个将 String 映射到 int 的 Hashtable ，我们只能创建 Hashtable<String, Integer> 的实例，并将所有的 int 值包装在 Integer 中。

同样，Tiger 在这方面当然也是由所用的实现方案得到的。既然类型参数被擦除为它们的界限，而界限不能是基本类型，所以一旦类型被擦除，则对基本类型的实例化会完全没有意义。

数据类型转换或 instanceof 操作中的“外露”参数

回想一下，对于“外露”类型参数，我们是指在词汇上单独出现的类型参数，而不是更大类型的语法子组件。例如， C<T> 不是“外露”类型参数，但（在 C 主体中） T 是。

如果在代码中对“外露”类型参数进行数据类型转换或 instanceof 操作，则编译器将发出名为“unchecked”的警告。例如，以下代码将生成警告： Warning: unchecked cast to type T ：

清单 3. 带 unchecked 操作的泛型代码
import java.util.Hashtable;
interface Registry {
  public void register(Object o);
}
class C<T> implements Registry {
  int counter = 0;
  Hashtable<Integer, T> values;

  public C() {
    values = new Hashtable<Integer, T>();
  }

  public void register(Object o) {
    values.put(new Integer(counter), (T)o);
    counter++;
  }
}

您应该严肃地对待这些警告，因为它们说明您的代码在运行时会表现得非常奇怪。事实上，它们会使得诊断代码变得极为困难。在以前的代码中，我们认为如果对实例 C<JFrame> 调用 register("test") ，会发出 ClassCastException 。但并非如此；计算将继续，就仿佛数据类型转换成功了一样，然后在进一步进行计算时发出错误，或者更糟：用遭破坏的数据完成计算，但不向外发出任何错误信号。同样，对“外露”类型参数的 instanceof 检查将在编译时产生“unchecked”警告，而且检查将不会如期在运行时进行。

双刃剑

那么，这里到底发生了什么？因为 Tiger 依靠类型擦除，所以数据类型转换和 instanceof 测试中的外露类型参数被“擦除”为它们的上界（在前面的例子中，那将是类型 Object ）。因此，对类型参数的数据类型转换将变成对参数上界的转换。

同样， instanceof 将检查操作数是否是参数界限的 instanceof 。那根本不是我们打算做的，如果是的话，我们完全可以显式地强制转换为界限。因此，通常应避免对类型参数使用数据类型转换和 instanceof 检查。

然而，有时为了编译代码，您必须依靠对类型参数的数据类型转换。如果是这样的情况，只要记住，在代码的那一部分中，类型检查不保险 ― 要靠自己。

尽管泛型类型是制作健壮代码的强大武器，但我们已经演示了误用它们会使代码不再健壮而且极难诊断和修正。下次，我们将介绍 Tiger 中泛型类型的后两个限制，并讨论试图在泛型 Java 类型系统中包括它们时必定会出现的一些问题。

大多数好的设计者象躲避瘟疫一样来避免使用实现继承(extends 关系)。实际上80%的代码应该完全用interfaces写，而不是通过extends。“JAVA设计模式”一书详细阐述了怎样用接口继承代替实现继承。这篇文章描述设计者为什么会这么作。
Extends是有害的；也许对于Charles Manson这个级别的不是，但是足够糟糕的它应该在任何可能的时候被避开。“JAVA设计模式”一书花了很大的部分讨论用interface继承代替实现继承。
好的设计者在他的代码中，大部分用interface，而不是具体的基类。本文讨论为什么设计者会这样选择，并且也介绍一些基于interface的编程基础。
接口（Interface）和类（Class）?
Jams Gosling（Java之父）做发起人讲话。有人问他：“如果你重新构造Java，你想改变什么？”。“我想抛弃classes”他回答。在笑声平息后，它解释说，真正的问题不是由于class本身，而是实现继承(extends 关系)。接口继承（implements关系）是更好的。你应该尽可能的避免实现继承。
失去了灵活性
为什么你应该避免实现继承呢？第一个问题是明确的使用具体类名将你固定到特定的实现，给底层的改变增加了不必要的困难。
在当前的敏捷编程方法中，核心是并行的设计和开发的概念。在你详细设计程序前，你开始编程。这个技术不同于传统方法的形式----传统的方式是设计应该在编码开始前完成----但是许多成功的项目已经证明你能够更快速的开发高质量代码，相对于传统的按部就班的方法。但是在并行开发的核心是主张灵活性。你不得不以某一种方式写你的代码以至于最新发现的需求能够尽可能没有痛苦的合并到已有的代码中。
胜于实现你也许需要的特征，你只需实现你明确需要的特征，而且适度的对变化的包容。如果你没有这种灵活，并行的开发，那简直不可能。
对于Inteface的编程是灵活结构的核心。为了说明为什么，让我们看一下当使用它们的时候，会发生什么。考虑下面的代码：
f()
{ LinkedList list = new LinkedList();
//...
g( list );
}
g( LinkedList list )
{
list.add( ... );
g2( list )
}
现在，假设一个对于快速查询的需求被提出，以至于这个LinkedList不能够解决。你需要用HashSet来代替它。在已有代码中，变化不能够局部化，因为你不仅仅需要修改f()也需要修改g()（它带有LinkedList参数），并且还有g()把列表传递给的任何代码。象下面这样重写代码:
f()
{ Collection list = new LinkedList();
//...
g( list );
}
g( Collection list )
{
list.add( ... );
g2( list )
}
这样修改Linked list成hash，可能只是简单的用new HashSet()代替new LinkedList()。就这样。没有其他的需要修改的地方。
作为另一个例子，比较下面两段代码：
f()
{ Collection c = new HashSet();
//...
g( c );
}
g( Collection c )
{
for( Iterator i = c.iterator(); i.hasNext() )
do_something_with( i.next() );
}
和
f2()
{ Collection c = new HashSet();
//...
g2( c.iterator() );
}
g2( Iterator i )
{ while( i.hasNext() )
do_something_with( i.next() );
}
g2()方法现在能够遍历Collection的派生，就像你能够从Map中得到的键值对。事实上，你能够写iterator，它产生数据，代替遍历一个Collection。你能够写iterator，它从测试的框架或者文件中得到信息。这会有巨大的灵活性。
耦合
对于实现继承，一个更加关键的问题是耦合---令人烦躁的依赖，就是那种程序的一部分对于另一部分的依赖。全局变量提供经典的例子，证明为什么强耦合会引起麻烦。例如，如果你改变全局变量的类型，那么所有用到这个变量的函数也许都被影响，所以所有这些代码都要被检查，变更和重新测试。而且，所有用到这个变量的函数通过这个变量相互耦合。也就是，如果一个变量值在难以使用的时候被改变，一个函数也许就不正确的影响了另一个函数的行为。这个问题显著的隐藏于多线程的程序。
作为一个设计者，你应该努力最小化耦合关系。你不能一并消除耦合，因为从一个类的对象到另一个类的对象的方法调用是一个松耦合的形式。你不可能有一个程序，它没有任何的耦合。然而，你能够通过遵守OO规则，最小化一定的耦合（最重要的是，一个对象的实现应该完全隐藏于使用他的对象）。例如，一个对象的实例变量（不是常量的成员域），应该总是private。我意思是某段时期的，无例外的，不断的。（你能够偶尔有效地使用protected方法，但是protected实例变量是可憎的事）同样的原因你应该不用get/set函数---他们对于是一个域公用只是使人感到过于复杂的方式（尽管返回修饰的对象而不是基本类型值的访问函数是在某些情况下是由原因的，那种情况下，返回的对象类是一个在设计时的关键抽象）。
这里，我不是书生气。在我自己的工作中，我发现一个直接的相互关系在我OO方法的严格之间，快速代码开发和容易的代码实现。无论什么时候我违反中心的OO原则，如实现隐藏，我结果重写那个代码（一般因为代码是不可调试的）。我没有时间重写代码，所以我遵循那些规则。我关心的完全实用?我对干净的原因没有兴趣。
脆弱的基类问题
现在，让我们应用耦合的概念到继承。在一个用extends的继承实现系统中，派生类是非常紧密的和基类耦合，当且这种紧密的连接是不期望的。设计者已经应用了绰号“脆弱的基类问题”去描述这个行为。基础类被认为是脆弱的是，因为你在看起来安全的情况下修改基类，但是当从派生类继承时，新的行为也许引起派生类出现功能紊乱。你不能通过简单的在隔离下检查基类的方法来分辨基类的变化是安全的；而是你也必须看（和测试）所有派生类。而且，你必须检查所有的代码，它们也用在基类和派生类对象中，因为这个代码也许被新的行为所打破。一个对于基础类的简单变化可能导致整个程序不可操作。
让我们一起检查脆弱的基类和基类耦合的问题。下面的类extends了Java的ArrayList类去使它像一个stack来运转：
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}
甚至一个象这样简单的类也有问题。思考当一个用户平衡继承和用ArrayList的clear()方法去弹出堆栈时：
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();
这个代码成功编译，但是因为基类不知道关于stack指针堆栈的情况,这个stack对象当前在一个未定义的状态。下一个对于push（）调用把新的项放入索引2的位置。（stack_pointer的当前值），所以stack有效地有三个元素-下边两个是垃圾。（Java的stack类正是有这个问题，不要用它）.
对这个令人讨厌的继承的方法问题的解决办法是为Stack覆盖所有的ArrayList方法，那能够修改数组的状态，所以覆盖正确的操作Stack指针或者抛出一个例外。(removeRange()方法对于抛出一个例外一个好的候选方法)。
这个方法有两个缺点。第一，如果你覆盖了所有的东西，这个基类应该真正的是一个interface，而不是一个class。如果你不用任何继承方法，在实现继承中就没有这一点。第二，更重要的是，你不能够让一个stack支持所有的ArrayList方法。例如，令人烦恼的removeRange()没有什么作用。唯一实现无用方法的合理的途径是使它抛出一个例外，因为它应该永远不被调用。这个方法有效的把编译错误成为运行错误。不好的方法是，如果方法只是不被定义，编译器会输出一个方法未找到的错误。如果方法存在，但是抛出一个例外，你只有在程序真正的运行时，你才能够发现调用错误。
对于这个基类问题的一个更好的解决办法是封装数据结构代替用继承。这是新的和改进的Stack的版本：
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{
the_data.add( stack_poniter++, article );
}
public Object pop()
{
return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{
for（ int i = 0; i < o.length; ++i ）
push( articles[i] );
}
}
到现在为止，一直都不错，但是考虑脆弱的基类问题，我们说你想要在stack创建一个变量， 用它在一段周期内跟踪最大的堆栈尺寸。一个可能的实现也许象下面这样:
class Monitorable_stack extends Stack
{
private int high_water_mark = 0;
private int current_size;
public void push( Object article )
{
if( ++current_size > high_water_mark )
high_water_mark = current_size;
super.push( article );
}
publish Object pop()
{
--current_size;
return super.pop();
}
public int maximum_size_so_far()
{
return high_water_mark;
}
}
这个新类运行的很好，至少是一段时间。不幸的是，这个代码发掘了一个事实，push_many()通过调用push()来运行。首先，这个细节看起来不是一个坏的选择。它简化了代码，并且你能够得到push()的派生类版本，甚至当Monitorable_stack通过Stack的参考来访问的时候，以至于high_water_mark能够正确的更新