区分良好设计与不佳设计的最重要因素是,组件是否将其内部数据与实现细节隐藏起来。一个良好的设计应当隐藏所有的实现细节,将其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
引用的是不可变对象。
网友评论