怎么控制好代码的权力

授权使用这些资源， 需要遵循“最小授权”的原则。

所授予的权力， 能够让应用程序完成对应的任务就行， 不要授予多余的权力。 为了方便， 我们可以把“最小授权”这个概念拆分成如下的两个部
分来理解：

• 最小权力的设计
• 最小限度的授予

最小权力的设计
其实， 不管使用什么编程语言， 我们编写的代码都会涉及到代码权力的设计。 最常见的设计， 就
是代码的访问控制权限的设计。
一段代码访问应用程序接口的过程， 一般需要至少两个步骤， 第一步是加载类库， 第二步是调用
接口。 这两个步骤， 都需要设计好访问控制权限。

模块的访问权限
下面的例子， 就是一个Java模块的权限设计（module-info.java） 。 这个权限设计， 定义了一个example.coding模块。 这个模块允许外部代码使用它提供的com.example.coding内部接口。
module example.coding {
exports com.example.coding;
}
这个模块可能还包含其他的接口， 比如位于com.example.implement包内的代码。 由于模块的定
义没有允许外部代码使用除了com.example.coding包空间以外的接口， 那么
com.example.implement包内的接口， 即便是public接口， 外部代码也不能直接访问了。
这个模块被加载时， 它可以接受的访问控制权限也就相应地确定了。
我们在设计一个模块时， 需要尽量把命名空间设计好， 开放的接口放在一个开放的包里； 内部接
口或者代码实现， 放在封闭的包里。 把开放的部分和封闭的部分， 分割开来。 这样我们就设计了
一道安全的边界， 开放包里的代码， 经过精心设计和耐心打磨， 处理好潜在的安全问题。 而封闭
包里的代码编写就少了很多安全的顾虑， 可以让编写更有效率。
这样的设计， 也使得这个模块和外部的接触面更小。 接触面越小， 代码的安全问题就越少， 代码
的接口就越容易管理。
模块化是JDK9引入的一个新特性。
在JDK9之前， 有很多声明为public的内部类， 比如com.sun.net.internal包里的类。 虽然这些内
部的类声明为public， 但是它们的真实意图往往是方便内部不同包内的接口共享， 而不是开放给
外部的应用程序使用。 所以， Java的文档会一再强调， 应用程序不要使用内部类， 即使这些类声
明为public。 因为这些内部类可能随时被改变， 随时被删除。 另外， 内部类一般也没有规范的文
档， 实