Effective Java 3rd 条目15 最小化类和成员的可访问性

区分良好设计与不良设计的组件的最重要的因素是,这个组件对其他组件隐藏它的内部数据和其他实现细节的程度。一个设计良好的组件隐藏了它的所有实现细节,干净地把它的API从它的实现中分离。然后组件仅仅可以通过它们的API通讯,而且不知道它们彼此的内部运作。这个概念,叫信息隐藏(information hiding)或者封装(encapsulation),是软件设计的一个基础原则[Parnas72]。

信息隐藏在许多方面是重要的,大多数起源于这个事实:它解耦(decouples)了组成系统的组件,让它们可以开发、测试、优化、使用、理解和隔离修改。这加快了系统开发,因为组件可以并行地开发。它减轻了维护的负担,因为组件可以更快地理解、调试或者不要担心危害其他组件地替代。虽然信息隐藏和它本身并不能带来好的性能,但是它使得性能调优有效率:一旦一个系统完成了,性能分析决定了哪个组件造成了性能问题(条目67),这些组件可以没有影响其他组件正确的情形下优化。信息隐藏增加了软件复用,因为没有紧耦合的组件,除了它们被开发的情形下,常常证明在其他情形下是有用的。最后,信息隐藏减少了构建大系统的危险性,因为单个组件可以证明是成功的,即使系统并没有。

Java有协助信息隐藏的许多工具。访问控制(access control)机制[JLS, 6.6] 规定了类、接口和成员的访问性(accessibility)。实体的访问性由下面两者决定:它的声明位置和在声明时呈现哪个(如果有)访问标识符(private、protected和public)。这些修饰符正常使用对于信息隐藏是必要的。

经验法则是简单的:使得每个类或者成员尽量不可访问。换句话说,使用与你编写软件的正常功能一致的尽可能低的访问等级。

对于顶层的(非嵌套的)类和接口,有两个可能的访问等级:包私有的(package-private)公开的(public)。如果你声明了一个公开修饰符的顶层类或者接口,它是公开的;否则,它是包私有的。如果顶层的类或者接口是包私有的,它应该是这样。通过使得它是包私有的,你可以使得它是实现的一部分,而不是可以导出的API,而且你可以修改它、替代它,或者在下一部的发布中移除它,而不用担心已经存在的客户端。如果你使得它是公开的,那么你有义务为了维护兼容性而永久支持它。

如果是包私有的顶层类或者接口仅仅由一个类使用,考虑把顶层类变成是使用它的唯一类的私有静态嵌套类(条目24)。这减少了它的包里面的所有类对使用它的那个类的访问。但是相对于包私有的顶层类,减少一个不必要的公开类的访问重要得多:公开类是包的API,而包私有的顶层类已经是它实现的一部分。

对于成员(域、方法、嵌套类和嵌套接口),有四种可能的访问等级,以增加访问性顺序列出如下:

  • 私有的(private) -- 成员仅仅可以从在声明它的顶层类里访问

  • 包私有的(package-private) -- 成员可以从在声明它的包里面的任何类访问。技术上被认为是默认的访问。如果没有指定访问修饰符(除了接口成员,它默认是公开的),这是你得到的访问等级。

  • 受保护的(protected) -- 成员可以从声明它的类的子类访问(受到一些限制[JLS, 6.6.2]),而且可以从声明它的包里面的任何类访问。

  • 公开的(public) -- 成员可以从任何地方访问。

在小心地设计你的类的公开API之后,你第一反应应该是使得所有其他的成员是私有的。只有在同一个包里面的另外一个类真正需要访问一个成员,你才应该移除私有修饰符而使得这个成员是包私有的。如果你发现自己经常这么做,你应该重新检测系统的设计,看看从另一个类解耦比较好的类是否需要另外一个分解。也就是说,私有的和包私有的成员是类实现的一部分,而通常不会影响它的导出API。然而,如果类实现了系列化(Serializable)(条目86和87),这些域可能泄漏到导出的API。

对于公开类的成员,当访问等级从包私有到受保护时,访问性的急剧增加将会发生。访问的对象是类导出API的一部分,而且必须永远支持。而且,一个导出类的受保护的成员代表着实现细节的一个公开承诺(条目19)。受保护成员的需求是相等少见的。

有个重要的规则是,限制你的能力来减少方法的访问性。如果一个方法覆写了一个超类,在子类中它不能有比超类中更严格的访问等级[JLS, 8.4.8.3]。这是必要的,保证子类实例在超类实例可用的地方都可以使用(里氏代换原则(Liskov substitution principle),参考条目15)。如果你违反了这个规则,那么当你试着编译子类时编译器将会产生一个错误信息。这个规则的特例是,如果类实现了一个接口,所有接口中的类方法在类中必须声明为公开的。

为了方便测试你的代码,你可能倾向于让一个类、接口或者成员有比原本需要的更多访问性。这在某种程度是可以的。为了测试让一个公开类的私有成员成为包私有的,这是可接受的,但是再提高可访问性是不可接受的。换句话说,为了方便测试,让一个类、接口或者成员成为一个包导出API一部分,这是不可接受的。幸运的是,我们也没必要,因为测试可以作为需要测试包的一部分而运行,所以可以访问它的包私有元素。

公开类的实例方法应该很少是公开的(条目16)。如果一个实例域是非final的或者是一个可变对象的引用,让它成为公开的,那么你放弃了限制存储在域中的值的能力。这意味着,这你放弃了实现这个域成为不变类的能力。而且,当类改变的时候,你放弃了采取任何行动的能力,所以有公开可变域的类通常不是线程安全的。即使一个域是final而且引用了一个可变对象,让它成为公开的,你就放弃了切换到一个新内部数据呈现(这个域不存在)的灵活性。

同样的建议可以应用到静态域,但是有一个例外。你可以通过公开静态final域来暴露常量,假设这些常量是组成这个类提供的抽象的不可分割的一部分。按照惯例,这些域有大写字符的名字,单词用下划线分割(条目68)。这些域要么包含原始值,要么包含对不可变对象的引用(条目17)。一个包含可变对象引用的域,有非final域的所有缺点。虽然这个引用不可能改变,但是被引用的对象可以修改--有灾难性的结果。

注意到,非零长度的队列总是可变的,所以一个类有一个公开静态final队列域或者有返回这种域的访问子(accessor)是错误的**。如果一个类有这样的域或者访问子,那么客户端可以修改队列的内容。下面是一个安全漏洞的常见来源:

// 潜在的安全漏洞!
public static final Thing[] VALUES = { ... };

注意这个事实,一些IDE产生返回一个私有队列域的引用,恰恰导致了这个问题。有两个方法解决这个问题。你可以让公开队列成为私有的而且添加一个公开不可变列表:

private static final Thing[] PRIVATE_VALUES = { ... }; 
public static final List VALUES = 
    Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));

或者,你可以让队列成为私有,而且添加一个返回私有队列拷贝的公开方法:

private static final Thing[] PRIVATE_VALUES = { ... }; 
public static final Thing[] values() { 
    return PRIVATE_VALUES.clone(); 
}

为了从这些备选方案选择,想想客户端可能对结果做什么。哪个返回类型更方便?哪个将有更好的性能?

在Java9中,有两个额外的隐含访问等级引入为模块系统(module system)的一部分。一个模块是一组包,就像包是一组类。一个模块通过在它的模块声明(module declaration)(通常包含在一个叫做module-info.java的源文件)中导出声明(export declaration),可以显式地导出它的有些包。模块里未导出包的公开和受保护成员在模块外面是不可访问的;在模块里面,访问性是不受导出声明影响的。使用模块系统让你可以在模块里面的包之间分享类,而没有让它们对于整个世界可见。在未导出包里面的公开类的公开和受保护成员,导致了两个隐含的访问等级,它们可类比于正常公开和受保护等级。这种分享的需求是相当少见的,而且常常可能通过重新安排包里面的类来解决。

不像四个主要的访问等级,这两个基于模块的等级是建议性质的。如果你在你的应用的类途径而不是它的模块途径上放置一个模块的JAR文件,那么这个模块的包恢复到它们的非模块化行为:包的公开类的所有公开和受保护成员有它们的正常访问性,而不管包是否有这个模块导出[Reinhold, 1.2]。新引入的访问等级被严格执行的地方,是JDK本身:Java库中的非导出包在它们的模块外是真正不可访问的。

对于一个典型的Java程序员,不只是由模块提供的访问保护是功能有限的,而且在本质上是建议性质的;为了利用它,你必须把你的包分组到模块中,使得它们的所有依赖在模块声明是明显的,重新安排你的源码树,而且采取特别的行动:在你的模块里面容纳对非模块化包的任何引用[Reinhold, 3]。现在就说模块在JDK本身之外是否能广泛使用还为时过早。同时,除非你有一个迫切的需求,似乎最好是避免它们。

总之,你应该尽可能减少(明智地)对程序元素的访问性。在仔细设计一个最小限度公开API后,你应该阻止散落的任何类、接口或者成员成为API的一部分。除了作为常量的公开静态final域,公开类不应该有公开域。确保由公开静态final域引用的类是不可变的。

你可能感兴趣的:(Effective Java 3rd 条目15 最小化类和成员的可访问性)