Merge pull request lingcoder#350 from john-h3/master

fix lingcoder#349

Author: lingcoder

docs/book/09-Polymorphism.md

@@ -503,7 +503,7 @@ public Derived extends PrivateOverride {
 private f()
 ```
 
-你可能期望输出是 **public f()**，然而 **private** 方法也是 **final** 的，对于派生类来说是隐蔽的。因此，这里 **Derived** 的 `f()` 是一个全新的方法；因为基类版本的 `f()` 屏蔽了 **Derived** ，因此它都不算是重写方法。
+你可能期望输出是 **public f()**，然而 **private** 方法可以当作是 **final** 的，对于派生类来说是隐蔽的。因此，这里 **Derived** 的 `f()` 是一个全新的方法；因为基类版本的 `f()` 屏蔽了 **Derived** ，因此它都不算是重写方法。
 
 结论是只有非 **private** 方法才能被重写，但是得小心重写 **private** 方法的现象，编译器不报错，但不会按我们所预期的执行。为了清晰起见，派生类中的方法名采用与基类中 **private** 方法名不同的命名。
 
@@ -640,7 +640,7 @@ Derived dynamicGet()
 
 ## 构造器和多态
 
-通常，构造器不同于其他类型的方法。在涉及多态时也是如此。尽管构造器不具有多态性（它们实际上是静态方法，但是隐式声明的），但是理解构造器在复杂层次结构中运作多态还是非常重要的。这个理解可以帮助你避免一些不愉快的困扰。
+通常，构造器不同于其他类型的方法。在涉及多态时也是如此。尽管构造器不具有多态性（事实上人们会把它看作是隐式声明的静态方法），但是理解构造器在复杂层次结构中运作多态还是非常重要的。这个理解可以帮助你避免一些不愉快的困扰。
 
 ### 构造器调用顺序
 
@@ -723,9 +723,9 @@ Sandwich()
 
 从创建 **Sandwich** 对象的输出中可以看出对象的构造器调用顺序如下：
 
-1. 基类构造器被调用。这个步骤重复递归，直到根基类的构造器被调用，然后是它的派生类，以此类推，直到最底层的派生类构造器被调用。
+1. 基类构造器被调用。这个步骤被递归地重复，这样一来类层次的顶级父类会被最先构造，然后是它的派生类，以此类推，直到最底层的派生类。
 2. 按声明顺序初始化成员。
-3. 最终调用派生类的构造器。
+3. 调用派生类构造器的方法体。
 
 构造器的调用顺序很重要。当使用继承时，就已经知道了基类的一切，并可以访问基类中任意 **public** 和 **protected** 的成员。这意味着在派生类中可以假定所有的基类成员都是有效的。在一个标准方法中，构造动作已经发生过，对象其他部分的所有成员都已经创建好。
 
@@ -1037,7 +1037,7 @@ RoundGlyph.RoundGlyph(), radius = 5
 
 另一方面，应该震惊于输出结果。逻辑方面我们已经做得非常完美，然而行为仍不可思议的错了，编译器也没有报错（C++ 在这种情况下会产生更加合理的行为）。像这样的 bug 很容易被忽略，需要花很长时间才能发现。
 
-因此，编写构造器有一条良好规范：做尽量少的事让对象进入良好状态。如果有可能的话，尽量不要调用类中的任何方法。在构造器中唯一能安全调用的只有基类的 **final** 方法（包括 **private** 方法，它们自动属于 **final**）。这些方法不能被重写，因此不会产生意想不到的结果。你可能无法永远遵循这条规范，但应该朝着它努力。
+因此，编写构造器有一条良好规范：做尽量少的事让对象进入良好状态。如果有可能的话，尽量不要调用类中的任何方法。在基类的构造器中能安全调用的只有基类的 **final** 方法（这也适用于可被看作是 **final** 的 **private** 方法）。这些方法不能被重写，因此不会产生意想不到的结果。你可能无法永远遵循这条规范，但应该朝着它努力。
 
 <!-- Covariant Return Types -->