区分良好设计与不佳设计的最重要因素是，组件是否将其内部数据与实现细节隐藏起来。一个良好的设计应当隐藏所有的实现细节，将其API和实现清晰的分离开。然后组件只能通过API进行交流，而对彼此的实现细节一无所知。这就是所谓的信息隐藏或者封装，是软件设计的最基本原则。
信息隐藏非常重要，主要的原因是，它能够将组成一个系统的各个组件解耦开来，是各个组件能够独立进行开发、测试、优化、使用或者修改，这能够极大幅度提高软件开发的效率，因为各个组件能够同时进行开发。信息隐藏也减轻了维护的负担，因为组件能够被更快地理解和调试或者更换组件，而不用担心损害到其他组件。虽然信息隐藏不能直接创造良好的性能，但是它能进行有效的性能调整：一旦系统完成并且分析确定哪些组件导致了性能问题（参见Item67），就可能优化或者直接替换这些组件，而不用担心对其他组件造成影响。最后，信息隐藏能够降低构建大型系统的风险，因为即使系统不能正常工作，它的各个组件也可能被证明是成功可用的。
Java提供了很多机制来帮助信息隐藏。访问控制机制指定了类、接口和成员的可见性，类和成员的可见性取决于其声明的位置，以及声明中的访问控制符（private,protect和public），正确使用这些操作符对信息隐藏至关重要。
大拇指规则（经验法则）很简单：尽量使类和成员对外界保持不可见性，也就是说能用private修饰的绝不使用protect或者public来修饰。
对于顶层（非嵌套的）类和接口来说，只有两种可能的可访问级别：包级私有和public，你可以在声明类和接口的时候使用public修饰符，这样它们就是对所有类都可见的，否则是包级私有的。包级私有类通常作为实现的一部分，你可以修改、替换或者在后续版本中删掉它，而不必担心会对现有使用者造成影响，而public的类一旦声明了，你就有义务永远维护它，以保持兼容性，所以应该小心地设计一个public的类或者接口，因为一旦设计不好，后续的维护将会十分艰难。
如果一个包级私有的类仅仅被一个类使用，那么可以将其作为使用者的嵌套内部类，这让其可见性从同一个包下的所有类降低到了一个类。但是减少不必要的public类的可访问性要比包级私有的顶级类更重要：因为public类是API的一部分，包级私有类是实现的一部分。
对于成员 (属性、方法、嵌套类和嵌套接口)，有四种可能的访问级别:
-
private:只能在声明它的顶级类中访问 -
package-private:成员可以从被声明的包中的任何类中访问。如果没有指定访问修饰符，则包级私有是默认访问级别，当然接口除外，接口的默认访问级别是public -
protected:成员可以从被声明的类的子类中访问(受一些限制，JLS，6.6.2)，以及它声明的包中的任何类。 -
public:能在任何地方被访问
在谨慎设计你的类API之后，你应该考虑使其他任何成员的可见性为private，只有当同一个包中的其他类真正需要访问另一个类的成员时，你才应该删除private修饰符，然后使用默认的包级私有访问级别。如果你经常这么干，那么你应该重新反思你的系统设计。因为通常来说，私有成员和包级私有成员是实现的一部分，不应该影响到API。不过，如果类实现了Serializable（参考Item86和87）接口，则这些属性可以对API暴露。
对于public类的成员，当其可访问级别从private改为protected，可访问性将大大提高，protected成员是API的一部分，必须永远提供维护支持。
有一个关键的规则限制了你减少方法访问性的能力，如果一个方法覆盖了超类的方法，那么它在子类中的访问级别不能低于在父类中的访问级别。这确保了子类的实例在父类实例可用的地方都是可用的。如果违反了此规则，编译器将在尝试编译子类时生成错误消息，此规则的一个特例是，如果类实现了某个接口，那么该类中所有属于该接口的方法都应该是public的。另外，不能为了方便测试，而将类成员的可见性从private或者包级私有提高到更高级别的可见性，这会导致许多麻烦事情，因为你可能暴露了不该暴露的实现细节。
public类的实例属性很少被公开。如果一个实例属性是非final的，那么将它声明为public会令你失去限制它的值的能力，这意味着你放弃了使该属性成为不可变量的能力，同时你也失去了在这个属性被修改时做一些操作的能力，因此，暴露了可变属性的类不是线程安全的。
同样的建议也适用于静态属性，但有一个例外。假设常量是类抽象的一个组成部分，您可以通过public static final公开常量。按照惯例，此类字段的名称由大写字母组成，单词之间用下划线分隔(Item68)。这些字段必须包含原始值或对不可变对象的引用(Item17)，这一点至关重要。包含对可变对象的引用的字段具有非final字段的所有缺点。虽然不能修改引用，但可以修改被引用的对象-这将导致灾难性的后果。
注意，非零长度数组总是可变的，因此类不应该拥有public static final成员或者一个返回这种数据类型的方法。因为客户端代码将能够修改数组中的数组，常常导致安全漏洞：
// Potential security hole!
public static final Thing[] VALUES = { ... };
一些 IDE 生成的getter方法返回对私有数组属性的引用，导致了这个问题。 有两种方法可以解决这个问题。 你可以使public数组私有并添加一个公共的不可变列表:
private static final Thing[] PRIVATE_VALUES = { ... };
public static final List<Thing> VALUES =
Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));
或者，你也可以令数组私有，并且提供一个方法返回此数组的一份拷贝。
Java9中的模块系统带来了两种隐式的访问级别，模块包含一组包，如同一个包包含一组类一般。模块可以通过模块声明中的导出(export)声明显式地导出某些包 (这是 module-info.java 的源文件中包含的约定)。模块中的未导出包的公共和受保护成员在模块之外是不可访问的;在模块中，可访问性不受导出(export)声明的影响。使用模块系统允许你在模块之间共享类，而不让它们对整个系统可见。在未导出的包 中，公共和受保护的公共类的成员会产生两个隐式访问级别，这是普通公共和受保护级别的内部类似的情况。这种需求一般比较少见，因为可以通过重新安排包中的类来达到同样的目的。这两个基于模块的访问级别仅仅是建议性的，除非有迫切需要，否则最好避免使用。
总之，应该尽量减少类成员的可访问性。在精心设计一个拥有最小public性的API后，你应该防止任何散乱的类、接口或者成员成为API的一部分。除了public static final之外，public类不应该拥有public属，并且需要确保public static final引用的是不可变对象。
网友评论