关于Java访问权限的一些思考与总结

  这篇博客主要用来介绍Java中的访问权限。
  大致有以下内容：

• 引入访问控制权限
• 对于访问权限成型的一些思考
• Java访问权限关键字介绍
• 一些需要注意的小问题

引入访问控制权限的需求

  我们都知道，一个通用类库(如：JDK)开发出来的目的是让普通开发者重用以节省开发时间与精力，但是类库的设计不可能在刚开始就尽善尽美，在类库被使用的过程中，总能发现很多由于设计不当所出现的问题，这时，类库开发者就需要对类库进行重构。
  重构就意味着改变，然而类库的消费者（客户端程序员）却需要一种保证：类库的更新不能影响基于类库实现的程序的正常使用。
  一般这种问题都被抛给了类库开发者，也就是说类库开发者必须做到：1.有权限对类库进行重构；2.确保客户代码不会类库的重构而受到影响。
  有很多方式可以解决这个问题，大致思路都差不多，无外乎是限制用户的访问(隐藏关键实现)。这种情况下，开发者获得了足够的自由度，只需保证不改变用户可以访问到的部分即可随意重构；而客户也可以放心的使用类库而无须担心类库改变影响到自己的应用。
  Java这门语言在设计的时候吸收了很多前人的经验，它在语言层面上为这种需求提供了支持，这就是访问修饰符的由来。

对于访问权限成型的一些思考

  在设计时很容易想到使用二分，即将访问权限分为可以访问与不能访问两种，也就是public与private。如果域被public修饰，说明这个部分可以被任何人访问到；如果域被private修饰，则除了当前类其他人都不能访问。但这样分的话产生的副作用太大，被private修饰的域连类库开发者本身所写的其它的类也无法访问。
  我们都知道，为了方便管理源代码，Java引入了包(package)进行命名空间的管理。在这个基础上，引入包访问权限与protected就理所当然了。对于具有包访问权限访问权限的域，只有同一个包内的类可以访问；对于具有protected访问权限的域，只有此域所在类的子类或与此类在同一个包内的类可以访问。这样就划分了较为清楚的界限。
  一般来说，用户自己写的类会被划分到自己特有的包中，这种情况下，这套访问权限控制机制可以正常使用。但是，并不是所有的用户都会遵守规则，用户恶意利用规则的情况时有发生，因此用户还是可能访问到类库开发者隐藏的部分实现。对于这种情况有什么解决方法么？
  个人认为：这个问题根本不是问题….因为权限控制实际上是一种约定（也可以理解为类库开发者的声明），这种约定的内涵是：如果客户遵守约定（Java的访问权限控制机制），就可以得到自己的应用不会因为类库更新而不兼容的保证（类库向下兼容）。在用户自己违反了约定的情况下，他的权益就无法也无需得到保证。实际上对于类库开发者来说唯一的约束是那些自己公开的或者事实公开的API，至于用户如何使用类库反而不是他们关心的。

Java访问权限关键字介绍

下面是Java中访问控制关键字的详细介绍。

关键字 含义 类内部 本包 子类 外部包 public 公有的 √ √ √ √ protected 受保护的 √ √ √ × 缺省 包访问权限 √ √ × × private 私有的 √ × × ×

一些需要注意的小问题

1. Java的权限控制并非只停留在编译期间。
   
   • 要注意，访问权限会反映在编译生成的字节码文件中，因此即使是运行时通过网络动态加载class的文件，在运行时仍然会受到访问权限的影响。
2. 关于类的访问修饰符。
   
   • 每个编译单元（类文件）都仅能有一个public class ，且必须保证public class的名称（包含大小写）必须和其类文件同名，否则编译失败。
   • 对于一个非内部类来说，因为它直属于包而不属于任何一个类，所以只有包访问权限与公有权限对它来说才有意义。
     也就是说，只能用public或者默认权限来修饰非内部类。
   • 对于一个内部类来说，它直属于一个类，因此四种权限都可以对其起作用。