读TIJ -5 隐藏实施过程——(封装)

《Think in java·第 5 章隐藏实施过程》

从该章的第一句话，我就感觉：这一章会令我不满意。【将发生变化的东西与保持不变的东西分隔开】与封装一毛钱的关系都没有。封装变化又称OCP，与OOP的封装性无关。

关于库（例如其中有类A）的设计，依赖库的程序B要求库是向下兼容的。这里，程序B依赖的是A的接口。不论库的创建者想怎样自由地进行修改与改进A，前提是不得修改A的接口。否则库不是兼容的。这里，A的接口指的是A需要提供的服务，A的设计者不可能、也不会“考虑”该服务(的方法名、参数)未来是否保持不变或改变。

以JDK中的类为例，类的接口变化时采用的方式：

• 列举 不赞成使用（Deprecated）的类的接口/方法
  
• Java8 的默认方法为Java接口的变化 提供后悔药。

所以，封装就是单纯地形成类的接口，与其他的想法无关。Java 的“访问指示符”的概念，仅仅用于限制出/限定出有限的类的接口。当然，如果你的类中所有的东西都是public——都是接口，按照不修改类的接口这一红线，后果的确是：你对方法名、参数的修改与改进“动弹不得”。问题是，你为什么要修改方法名、参数——接口要素？修改方法的实现才是库创建者的通常的愿望。

5.1 包：库单元

1.【The reason for all this importing is to provide a mechanism to manage name spaces. 】这句话看起来怎么这么别扭。Java引入包(package)的主要原因，是为了划分命名空间；而import语句(引入/导入语句)，不过是一个偷懒的手段，此外没有任何的含义。

2.【迄今为止，本书的大多数例子都仅存在于单个文件中，而且设计成局部（本地）使用，没有同包名发生冲突（在这种情况下，类名置于“默认包”内）。这是一种有效的做法，而且考虑到问题的简化，本书剩下的部分也将尽可能地采用它。】我反对这一做法，我推荐使用BlueJ，我们的第一个例子就不在默认包中。默认包是个不好的东西，除非你使用控制台学习Java而且能够忍受麻烦的目录转换，那才用默认包。

5.1.1 创建独一无二的包名  环境变量CLASSPATH。【1. 自动编译 为导入的类首次创建一个对象时（或者访问一个类的static 成员时），编译器会在适当的目录里寻找同名
的.class 文件（所以如果创建类X 的一个对象，就应该是X.class）。若只发现X.class，它就是必须使用的那一个类。然而，如果它在相同的目录中还发现了一个X.java，编译器就会比较两个文件的日期标记。如果X.java 比X.class 新，就会自动编译X.java，生成一个最新的X.class。对于一个特定的类，或在与它同名的.java 文件中没有找到它，就会对那个类采取上述的处理。】哦？！

5.1.2 自定义工具库  1. CLASSPATH 的陷阱 

5.1.3 利用导入改变行为   看看怎么模拟“条件编译”、断言机制的。通过改变导入的package，使用两个包中同名的类。

5.1.4 包的停用  讲这个没有什么价值。

5.2 Java 访问指示符

5.2.1 “友好的”—— Vs. 《6.2.3 包级私有》

5.2.2 public：接口访问
5.2.3 private：不能接触  JVM对private方法的优化；private 构造器；
5.2.4 protected：“友好的一种  好在我在《2.1.1 里氏替换原则》就讲了继承；

5.3 接口与实现

本来以为他要讲接口与实现的分离(separation of interface and implementation)，原来还是信息隐藏(他的implementation hiding)、 encapsulation。以及类的接口和类的实现的分离——这不就是封装吗？而类的接口凭什么必须是public——【client programmers can’t do anything but send messages to the public interface】，通常protected被认为是接口。

后面都是些无关紧要的东西，比如类的结构，我喜欢的格式：

public class Xxxx{    <域声明>    <构造器，初始化块>    <方法定义>    <内部类、内部接口>}

【类的使用者可从上向下依次阅读】，拜托，类的使用者应该读的是JavaDoc而非源代码。

5.4 类访问

public class 

这一章给60分。