[feast 07](添加第7章翻译 开头)

Author: xiangflight

README.md

@@ -25,7 +25,7 @@
 - [x] [第三章 万物皆对象](docs/book/03-Objects-Everywhere.md)
 - [x] [第四章 运算符](docs/book/04-Operators.md)
 - [x] [第五章 控制流](docs/book/05-Control-Flow.md)
-- [ ] [第六章 初始化和清理](docs/book/06-Housekeeping.md) 
+- [x] [第六章 初始化和清理](docs/book/06-Housekeeping.md) 
 - [ ] [第七章 封装](docs/book/07-Implementation-Hiding.md) 
 - [ ] [第八章 复用](docs/book/08-Reuse.md)
 - [ ] [第九章 多态](docs/book/09-Polymorphism.md)

docs/book/07-Implementation-Hiding.md

@@ -3,8 +3,20 @@
 <!-- Implementation Hiding -->
 # 第七章 封装
 
+访问控制（或者隐藏实现）与"最初的实现不恰当"有关。
+
+所有优秀的作者——包括这些编写软件的人——都知道一件好的作品都是经过反复打磨才变得优秀的。如果你把一段代码置于某个位置一段时间，过一会重新来看，你可能发现更好的实现方式。这是重构的原动力之一，重构就是重写可工作的代码，使之更加可读，易懂，因而更易维护。
+
+但是，在修改和完善代码的愿望下，也存在巨大的压力。通常，客户端程序员希望你的代码在某些方面保持不变。所以你想修改代码，但他们希望代码保持不变。由此引出了面向对象设计中的一个基本问题："如何区分变动的事物和不变的事物"。
+
+这个问题对于类库而言尤其重要。类库的使用者必须依赖他们所使用的那部分类库，并且知道如果使用了类库的新版本，不需要改写代码。另一方面，类库的开发者必须有修改和改进类库的自由，并保证客户代码不会受这些改动影响。
+
+这可以通过约定解决。例如，类库开发者必须同意在修改类库中的一个类时，不会移除已有的方法，因为那样将会破坏客户端程序员的代码。与之相反的情况更加复杂。在有成员属性的情况下，类库开发者如何知道哪些属性被客户端程序员使用？这同样会发生在那些只为实现类库类而创建的方法上，它们也不是设计成可供客户端程序员调用的。如果类库开发者想删除旧的实现，添加新的实现，结果会怎样呢？任何这些成员的改动都可能破环客户端程序员的代码。因此类库开发者会被束缚，不能修改任何事物。
+
+为了解决这一问题，Java 提供了访问修饰符供类库开发者指明哪些对于客户端程序员是可用的，哪些是不可用的。访问控制权限的等级，从"最大权限"到"最小权限"依次是：**public**，**protected**，包访问权限（没有关键字）和 **private**。根据上一段的内容，你可能会想，作为一名类库设计者，你会尽可能将一切都设为 **private**，仅向客户端程序员暴露你愿意他们使用的方法。这就是你通常所做的，尽管这与使用其他语言（尤其是 C）编程和访问不受任何限制的人们的直觉相违背。
 
 <!-- package: the Library Unit -->
+
 ## 包的概念