Thinking in Java 4th chap6笔记-访问权限控制

Thinking in Java 4th chap6笔记-访问权限控制

 1. 重构 -即重新代码，以使得它更可读，更易理解，且更具可维护性。
     这对类库而言，尤为重要。该类库的消费者必须依赖他所使用的那部分类库，并且能够知道如果类库出现了新版本，他们并不需要修改代码。从另一个方面来说，类库的开发者必须有权限进行修改和改进，并确保客户端代码并不会因为这些改动而受到影响。
     --->Java提供了访问权限修饰词，以供类库开发人员向客户端程序员指明哪些是可用的，哪些是不可用的；
     --->构件类库->捆绑到一个内聚的类库单元->package
2.由于名字之间的潜在冲突，在java中对 名字空间 进行完全控制并为每个类创建惟一的标识符组合就成了非常重要的事情
3. Java源代码文件-编译单元，每个编译单元只能有一个public类 ，如果该编译单元还有额外的类的话，包之外的世界是无法看到这些类，因为他们不是public类，而且他们重要用来为public类提供支持。
4. Java解释器的运行过程：
     找出环境变量CLASSPATH，CLASSPATH包括一个或多个目录，用作查找.class文件的根目录；从根目录开始，解释器获取包的名称并将每个句点替换成斜杠，已从CLASSPATH根中产生一个路径名称；得到的路径会与CLASSPATH中不同项链接，解释器就在这些目录中查找与你所创建的类名相关的class文件。(解释器还会查找某些涉及解释器所在位置的标准目录)
 注：使用jar会有一些不同；必须在类路径中将jar的实际名称写清楚，而不仅是指明它所在位置的目录。[本人觉得因为jar是一个归档文件，里面有许多class文件，所以查找某个相关的类时，必须要指明该类在哪个jar包]
5. import static :静态导入
6. C条件编译：
    该功能允许你不必更改任何代码，就能够切换开关并产生不同的行为。Java去掉此功能的原因是因为C在绝大多数情况下使用该功能是解决跨平台问题的,即程序的不同代码是根据不同的平台来编译的；由于java自身可以自动跨越不同的平台，因此该功能对java是没有必要的。 
 然而条件编译还有一些其他用途，如调试；调试过程在开发中是开启的，而在发布的产品中是禁用的；可以通过修改被导入的package方法来达到这一目的，修改的方法是将你程序用到的代码从调试版改为发布版。这一技术可以适用于任何种类的条件代码。--用import改变行为
     1.新建一个com.landon.debug的package，放入一个Debug类(工具类，工具方法，方法有实现)。如果我们想使用这个类进行调试，则可以import static com.landon.debug.Debug
     2.当我们准备发行版本时，就需要清除原来的Debug机制；为此我们只需要在一个不同的package中创建一个同样的Debug类，而该类中的方法同debug package中的Debug类方法原型相同，只不过没有方法是空实现而已。然后再修改之前的import语句，import static com.landon.release.Debug.
7.不要错误的认为Java总是将当前目录视作是查找行为的起点之一。如果你的CLASSPATH中少了一个"."作为路径之一的话，Java就不会查找那里。
8.访问权限的控制常被称为具体实现的隐藏。把数据和方法包装进类中，以及具体实现的隐藏，常共同被称作是封装。其结果是一个同时带有特征和行为的数据类型。
 出于两个重要的原因，访问权限控制将权限的边界划在了数据类型的内部。
     1.要设定客户端程序员可以使用和不可以使用的界限。可以在结构中建立自己的内部机制，而不必担心客户端程序员会偶然的将内部机制当做是他们可以使用接口的一部分。
     2.接口和具体实现进行分离。如果结构是用于一组程序之中，而客户端程序员除了可以向接口发送信息之外什么也不可以做的话，那么就可以随意更改所有不是public的东西（例如有包访问权限，protected,private的成员）而不会破坏客户端代码。
9.虽然不是很常用，但编译单元内不带public类也是可能的。在这种情况下，可以随意对文件命名，尽管随意命名会使得人们在阅读和维护代码时产生混淆。
10.事实上，一个内部类可以是private或者protected的。
11.static成员内部可以调用private构造器->单例设计模式
12.一定要记住：相同目录下的所有不具有明确package声明的文件，都被视作是该目录下默认包的一部分；另外，注意包访问权限（如果没有为类访问权限指定一个访问修饰符，就会默认得到包访问权限），如果该类的某个成员是public的话，则客户端程序员依旧可以调用该static成员，尽管他们不能生成该类的对象。[最后面这一条有待考证，我测试是没有通过，eclipse在其他包下面根本找不到包访问权限的类，所以编译错误，也就不能调用public static成员]
13.控制对成员的访问权限有两个原因：
    第一是为了使用户不要碰触那些他们不该碰触的部分。这些部分对于类的内部操作是必须的，但是他们并不属于客户端程序员接口的一部分。因此将方法和域指定为private，对客户端程序员而言是一种服务。因为这样他们可以清楚的看到什么对他们重要，什么是他们可以忽略的，这样简化了他们对类的理解。
     第二，也是最重要的原因。是为了让类库设计者可以更改类的内部工作方式，而不必担心这样会对客户端程序员产生重大的影响。例如最初可能以某种方式创建一个类，然后发现如果更改程序结构，可以大大提高运行速度。如果接口和实现可以被明确的隔离和加以保护，就可以达到这一目的，而不必强制客户端程序员重新编写代码。访问权限控制可以确保不会有任何客户端程序员依赖于某个类的底层实现的任何部分。
 类的公共接口是用户真正能够看到的，所以这一部分是分析和设计的过程中决定该类是否正确的最重要的部分。如果在最初无法创建出正确的接口，那么只要不删除任何客户端程序员在他们的程序中已经用到的东西，就可以在以后添加更多的方法。
      注意 ：访问权限控制专注于类库创建者和该类库的外部使用者之前的关系，这种关系也是一种通信方式。然而在许多情况下并非如此，例如你编写了自己的所有代码或者你在一个组员聚集在一起的项目工作，所有的东西都放在同一个包中。这种情况是另外一种的不同的通讯方式， 所以严格的遵循访问权限控制并不一定是最佳选择。