fix

4.1 用构造器自动初始化.md

+# 4.1 用构造器自动初始化
+
+
+对于方法的创建，可将其想象成为自己写的每个类都调用一次`initialize()`。这个名字提醒我们在使用对象之前，应首先进行这样的调用。但不幸的是，这也意味着用户必须记住调用方法。在Java中，由于提供了名为“构造器”的一种特殊方法，所以类的设计者可担保每个对象都会得到正确的初始化。若某个类有一个构造器，那么在创建对象时，Java会自动调用那个构造器——甚至在用户毫不知觉的情况下。所以说这是可以担保的！
+
+接着的一个问题是如何命名这个方法。存在两方面的问题。第一个是我们使用的任何名字都可能与打算为某个类成员使用的名字冲突。第二是由于编译器的责任是调用构造器，所以它必须知道要调用是哪个方法。C++采取的方案看来是最简单的，且更有逻辑性，所以也在Java里得到了应用：构造器的名字与类名相同。这样一来，可保证象这样的一个方法会在初始化期间自动调用。
+
+下面是带有构造器的一个简单的类（若执行这个程序有问题，请参考第3章的“赋值”小节）。
+
+```
+//: SimpleConstructor.java
+// Demonstration of a simple constructor
+package c04;
+
+class Rock {
+  Rock() { // This is the constructor
+    System.out.println("Creating Rock");
+  }
+}
+
+public class SimpleConstructor {
+  public static void main(String[] args) {
+    for(int i = 0; i < 10; i++)
+      new Rock();
+  }
+} ///:~
+```
+
+现在，一旦创建一个对象：
+
+```
+new Rock();
+```
+
+就会分配相应的存储空间，并调用构造器。这样可保证在我们经手之前，对象得到正确的初始化。
+请注意所有方法首字母小写的编码规则并不适用于构造器。这是由于构造器的名字必须与类名完全相同！
+
+和其他任何方法一样，构造器也能使用参数，以便我们指定对象的具体创建方式。可非常方便地改动上述例子，以便构造器使用自己的参数。如下所示：
+
+```
+class Rock {
+  Rock(int i) {
+    System.out.println(
+      "Creating Rock number " + i);
+  }
+}
+
+public class SimpleConstructor {
+  public static void main(String[] args) {
+    for(int i = 0; i < 10; i++)
+      new Rock(i);
+  }
+}
+```
+
+
+利用构造器的参数，我们可为一个对象的初始化设定相应的参数。举个例子来说，假设类`Tree`有一个构造器，它用一个整数参数标记树的高度，那么就可以象下面这样创建一个`Tree`对象：
+
+```
+tree t = new Tree(12); // 12英尺高的树
+```
+
+若`Tree(int)`是我们唯一的构造器，那么编译器不会允许我们以其他任何方式创建一个`Tree`对象。
+
+构造器有助于消除大量涉及类的问题，并使代码更易阅读。例如在前述的代码段中，我们并未看到对`initialize()`方法的明确调用——那些方法在概念上独立于定义内容。在Java中，定义和初始化属于统一的概念——两者缺一不可。
+
+构造器属于一种较特殊的方法类型，因为它没有返回值。这与`void`返回值存在着明显的区别。对于`void`返回值，尽管方法本身不会自动返回什么，但仍然可以让它返回另一些东西。构造器则不同，它不仅什么也不会自动返回，而且根本不能有任何选择。若存在一个返回值，而且假设我们可以自行选择返回内容，那么编译器多少要知道如何对那个返回值作什么样的处理。

7.7 构造器和多态性.md

+# 7.7 构造器和多态性
+
+同往常一样，构造器与其他种类的方法是有区别的。在涉及到多态性的问题后，这种方法依然成立。尽管构造器并不具有多态性（即便可以使用一种“虚拟构造器”——将在第11章介绍），但仍然非常有必要理解构造器如何在复杂的分级结构中以及随同多态性使用。这一理解将有助于大家避免陷入一些令人不快的纠纷。
+
+7.7.1 构造器的调用顺序
+
+构造器调用的顺序已在第4章进行了简要说明，但那是在继承和多态性问题引入之前说的话。
+
+用于基类的构造器肯定在一个派生类的构造器中调用，而且逐渐向上链接，使每个基类使用的构造器都能得到调用。之所以要这样做，是由于构造器负有一项特殊任务：检查对象是否得到了正确的构建。一个派生类只能访问它自己的成员，不能访问基类的成员（这些成员通常都具有`private`属性）。只有基类的构造器在初始化自己的元素时才知道正确的方法以及拥有适当的权限。所以，必须令所有构造器都得到调用，否则整个对象的构建就可能不正确。那正是编译器为什么要强迫对派生类的每个部分进行构造器调用的原因。在派生类的构造器主体中，若我们没有明确指定对一个基类构造器的调用，它就会“默默”地调用默认构造器。如果不存在默认构造器，编译器就会报告一个错误（若某个类没有构造器，编译器会自动组织一个默认构造器）。
+
+下面让我们看看一个例子，它展示了按构建顺序进行组合、继承以及多态性的效果：
+
+```
+//: Sandwich.java
+// Order of constructor calls
+
+class Meal {
+  Meal() { System.out.println("Meal()"); }
+}
+
+class Bread {
+  Bread() { System.out.println("Bread()"); }
+}
+
+class Cheese {
+  Cheese() { System.out.println("Cheese()"); }
+}
+
+class Lettuce {
+  Lettuce() { System.out.println("Lettuce()"); }
+}
+
+class Lunch extends Meal {
+  Lunch() { System.out.println("Lunch()");}
+}
+
+class PortableLunch extends Lunch {
+  PortableLunch() {
+    System.out.println("PortableLunch()");
+  }
+}
+
+class Sandwich extends PortableLunch {
+  Bread b = new Bread();
+  Cheese c = new Cheese();
+  Lettuce l = new Lettuce();
+  Sandwich() {
+    System.out.println("Sandwich()");
+  }
+  public static void main(String[] args) {
+    new Sandwich();
+  }
+} ///:~
+```
+
+这个例子在其他类的外部创建了一个复杂的类，而且每个类都有一个构造器对自己进行了宣布。其中最重要的类是`Sandwich`，它反映出了三个级别的继承（若将从`Object`的默认继承算在内，就是四级）以及三个成员对象。在`main()`里创建了一个`Sandwich`对象后，输出结果如下：
+
+```
+Meal()
+Lunch()
+PortableLunch()
+Bread()
+Cheese()
+Lettuce()
+Sandwich()
+```
+
+这意味着对于一个复杂的对象，构造器的调用遵照下面的顺序：
+
+(1) 调用基类构造器。这个步骤会不断重复下去，首先得到构建的是分级结构的根部，然后是下一个派生类，等等。直到抵达最深一层的派生类。
+
+(2) 按声明顺序调用成员初始化模块。
+
+(3) 调用派生构造器的主体。
+
+构造器调用的顺序是非常重要的。进行继承时，我们知道关于基类的一切，并且能访问基类的任何`public`和`protected`成员。这意味着当我们在派生类的时候，必须能假定基类的所有成员都是有效的。采用一种标准方法，构建行动已经进行，所以对象所有部分的成员均已得到构建。但在构造器内部，必须保证使用的所有成员都已构建。为达到这个要求，唯一的办法就是首先调用基类构造器。然后在进入派生类构造器以后，我们在基类能够访问的所有成员都已得到初始化。此外，所有成员对象（亦即通过组合方法置于类内的对象）在类内进行定义的时候（比如上例中的`b`，`c`和`l`），由于我们应尽可能地对它们进行初始化，所以也应保证构造器内部的所有成员均为有效。若坚持按这一规则行事，会有助于我们确定所有基类成员以及当前对象的成员对象均已获得正确的初始化。但不幸的是，这种做法并不适用于所有情况，这将在下一节具体说明。
+
+7.7.2 继承和`finalize()`
+
+通过“组合”方法创建新类时，永远不必担心对那个类的成员对象的收尾工作。每个成员都是一个独立的对象，所以会得到正常的垃圾收集以及收尾处理——无论它是不是不自己某个类一个成员。但在进行初始化的时候，必须覆盖派生类中的`finalize()`方法——如果已经设计了某个特殊的清除进程，要求它必须作为垃圾收集的一部分进行。覆盖派生类的`finalize()`时，务必记住调用`finalize()`的基类版本。否则，基类的初始化根本不会发生。下面这个例子便是明证：
+
+```
+//: Frog.java
+// Testing finalize with inheritance
+
+class DoBaseFinalization {
+  public static boolean flag = false;
+}
+
+class Characteristic {
+  String s;
+  Characteristic(String c) {
+    s = c;
+    System.out.println(
+      "Creating Characteristic " + s);
+  }
+  protected void finalize() {
+    System.out.println(
+      "finalizing Characteristic " + s);
+  }
+}
+
+class LivingCreature {
+  Characteristic p =
+    new Characteristic("is alive");
+  LivingCreature() {
+    System.out.println("LivingCreature()");
+  }
+  protected void finalize() {
+    System.out.println(
+      "LivingCreature finalize");
+    // Call base-class version LAST!
+    if(DoBaseFinalization.flag)
+      try {
+        super.finalize();
+      } catch(Throwable t) {}
+  }
+}
+
+class Animal extends LivingCreature {
+  Characteristic p =
+    new Characteristic("has heart");
+  Animal() {
+    System.out.println("Animal()");
+  }
+  protected void finalize() {
+    System.out.println("Animal finalize");
+    if(DoBaseFinalization.flag)
+      try {
+        super.finalize();
+      } catch(Throwable t) {}
+  }
+}
+
+class Amphibian extends Animal {
+  Characteristic p =
+    new Characteristic("can live in water");
+  Amphibian() {
+    System.out.println("Amphibian()");
+  }
+  protected void finalize() {
+    System.out.println("Amphibian finalize");
+    if(DoBaseFinalization.flag)
+      try {
+        super.finalize();
+      } catch(Throwable t) {}
+  }
+}
+
+public class Frog extends Amphibian {
+  Frog() {
+    System.out.println("Frog()");
+  }
+  protected void finalize() {
+    System.out.println("Frog finalize");
+    if(DoBaseFinalization.flag)
+      try {
+        super.finalize();
+      } catch(Throwable t) {}
+  }
+  public static void main(String[] args) {
+    if(args.length != 0 &&
+       args[0].equals("finalize"))
+       DoBaseFinalization.flag = true;
+    else
+      System.out.println("not finalizing bases");
+    new Frog(); // Instantly becomes garbage
+    System.out.println("bye!");
+    // Must do this to guarantee that all
+    // finalizers will be called:
+    System.runFinalizersOnExit(true);
+  }
+} ///:~
+```
+
+`DoBasefinalization`类只是简单地容纳了一个标志，向分级结构中的每个类指出是否应调用`super.finalize()`。这个标志的设置建立在命令行参数的基础上，所以能够在进行和不进行基类收尾工作的前提下查看行为。
+分级结构中的每个类也包含了`Characteristic`类的一个成员对象。大家可以看到，无论是否调用了基类收尾模块，`Characteristi`c成员对象都肯定会得到收尾（清除）处理。
+
+每个被覆盖的`finalize()`至少要拥有对`protected`成员的访问权力，因为`Object`类中的`finalize()`方法具有`protected`属性，而编译器不允许我们在继承过程中消除访问权限（“友好的”比“受到保护的”具有更小的访问权限）。
+
+在`Frog.main()`中，`DoBaseFinalization`标志会得到配置，而且会创建单独一个`Frog`对象。请记住垃圾收集（特别是收尾工作）可能不会针对任何特定的对象发生，所以为了强制采取这一行动，`System.runFinalizersOnExit(true)`添加了额外的开销，以保证收尾工作的正常进行。若没有基类初始化，则输出结果是：
+
+```
+not finalizing bases
+Creating Characteristic is alive
+LivingCreature()
+Creating Characteristic has heart
+Animal()
+Creating Characteristic can live in water
+Amphibian()
+Frog()
+bye!
+Frog finalize
+finalizing Characteristic is alive
+finalizing Characteristic has heart
+finalizing Characteristic can live in water
+```
+
+从中可以看出确实没有为基类·调用收尾模块。但假如在命令行加入`finalize`参数，则会获得下述结果：
+
+```
+Creating Characteristic is alive
+LivingCreature()
+Creating Characteristic has heart
+Animal()
+Creating Characteristic can live in water
+Amphibian()
+Frog()
+bye!
+Frog finalize
+Amphibian finalize
+Animal finalize
+LivingCreature finalize
+finalizing Characteristic is alive
+finalizing Characteristic has heart
+finalizing Characteristic can live in water
+```
+
+尽管成员对象按照与它们创建时相同的顺序进行收尾，但从技术角度说，并没有指定对象收尾的顺序。但对于基类，我们可对收尾的顺序进行控制。采用的最佳顺序正是在这里采用的顺序，它与初始化顺序正好相反。按照与C++中用于“析构器”相同的形式，我们应该首先执行派生类的收尾，再是基类的收尾。这是由于派生类的收尾可能调用基类中相同的方法，要求基类组件仍然处于活动状态。因此，必须提前将它们清除（析构）。
+
+7.7.3 构造器内部的多态性方法的行为
+
+构造器调用的分级结构（顺序）为我们带来了一个有趣的问题，或者说让我们进入了一种进退两难的局面。若当前位于一个构造器的内部，同时调用准备构建的那个对象的一个动态绑定方法，那么会出现什么情况呢？在原始的方法内部，我们完全可以想象会发生什么——动态绑定的调用会在运行期间进行解析，因为对象不知道它到底从属于方法所在的那个类，还是从属于从它派生出来的某些类。为保持一致性，大家也许会认为这应该在构造器内部发生。
+
+但实际情况并非完全如此。若调用构造器内部一个动态绑定的方法，会使用那个方法被覆盖的定义。然而，产生的效果可能并不如我们所愿，而且可能造成一些难于发现的程序错误。
+
+从概念上讲，构造器的职责是让对象实际进入存在状态。在任何构造器内部，整个对象可能只是得到部分组织——我们只知道基类对象已得到初始化，但却不知道哪些类已经继承。然而，一个动态绑定的方法调用却会在分级结构里“向前”或者“向外”前进。它调用位于派生类里的一个方法。如果在构造器内部做这件事情，那么对于调用的方法，它要操纵的成员可能尚未得到正确的初始化——这显然不是我们所希望的。
+
+通过观察下面这个例子，这个问题便会昭然若揭：
+
+```
+//: PolyConstructors.java
+// Constructors and polymorphism
+// don't produce what you might expect.
+
+abstract class Glyph {
+  abstract void draw();
+  Glyph() {
+    System.out.println("Glyph() before draw()");
+    draw();
+    System.out.println("Glyph() after draw()");
+  }
+}
+
+class RoundGlyph extends Glyph {
+  int radius = 1;
+  RoundGlyph(int r) {
+    radius = r;
+    System.out.println(
+      "RoundGlyph.RoundGlyph(), radius = "
+      + radius);
+  }
+  void draw() {
+    System.out.println(
+      "RoundGlyph.draw(), radius = " + radius);
+  }
+}
+
+public class PolyConstructors {
+  public static void main(String[] args) {
+    new RoundGlyph(5);
+  }
+} ///:~
+```
+
+在`Glyph`中，`draw()`方法是“抽象的”（`abstract`），所以它可以被其他方法覆盖。事实上，我们在`RoundGlyph`中不得不对其进行覆盖。但`Glyph`构造器会调用这个方法，而且调用会在`RoundGlyph.draw()`中止，这看起来似乎是有意的。但请看看输出结果：
+
+```
+Glyph() before draw()
+RoundGlyph.draw(), radius = 0
+Glyph() after draw()
+RoundGlyph.RoundGlyph(), radius = 5
+```
+
+当`Glyph`的构造器调用`draw()`时，`radius`的值甚至不是默认的初始值1，而是0。这可能是由于一个点号或者屏幕上根本什么都没有画而造成的。这样就不得不开始查找程序中的错误，试着找出程序不能工作的原因。
+
+前一节讲述的初始化顺序并不十分完整，而那是解决问题的关键所在。初始化的实际过程是这样的：
+
+(1) 在采取其他任何操作之前，为对象分配的存储空间初始化成二进制零。
+
+(2) 就象前面叙述的那样，调用基类构造器。此时，被覆盖的`draw()`方法会得到调用（的确是在`RoundGlyph`构造器调用之前），此时会发现`radius`的值为0，这是由于步骤(1)造成的。
+
+(3) 按照原先声明的顺序调用成员初始化代码。
+
+(4) 调用派生类构造器的主体。
+
+采取这些操作要求有一个前提，那就是所有东西都至少要初始化成零（或者某些特殊数据类型与“零”等价的值），而不是仅仅留作垃圾。其中包括通过“组合”技术嵌入一个类内部的对象引用。如果假若忘记初始化那个引用，就会在运行期间出现异常事件。其他所有东西都会变成零，这在观看结果时通常是一个严重的警告信号。
+
+在另一方面，应对这个程序的结果提高警惕。从逻辑的角度说，我们似乎已进行了无懈可击的设计，所以它的错误行为令人非常不可思议。而且没有从编译器那里收到任何报错信息（C++在这种情况下会表现出更合理的行为）。象这样的错误会很轻易地被人忽略，而且要花很长的时间才能找出。
+
+因此，设计构造器时一个特别有效的规则是：用尽可能简单的方法使对象进入就绪状态；如果可能，避免调用任何方法。在构造器内唯一能够安全调用的是在基类中具有`final`属性的那些方法（也适用于`private`方法，它们自动具有`final`属性）。这些方法不能被覆盖，所以不会出现上述潜在的问题。