《第4章 类和接口》
类和接口是Java语言的核心,本章包含的一些指导原则,可以帮助你更好地设计出更加有用、健壮、灵活的类和接口。
【第12条】使类和成员的可访问能力最小化
要想区别一个设计良好的模块与一个设计不好的模块,最重要的因素是,这个模块对于外部的其它模块而言,是否隐藏了内部的数据和其他的实现细节。换句话说,就是模块的设计者是否对其进行了良好的封装。
经验表明,你应该尽可能地使每一个类或成员不被外界访问。也就是说,在保证与该模块相关的程序能够正确运行的前提下,尽可能使用最低可能的访问级别。那些一上来不加思索就统统 public 的做法显然是要着重声讨的。
对于顶层的(非嵌套的)类和接口,它们只有2种访问级别:包级私有(package-private)和公有(public)。如果选择了包级私有,那么它只是这个包的实现的一部分,而不是该包对外提供服务的API的一部分。在以后的版本中,你可以对它进行修改、替换甚至删除,而无需担心会伤害到现有的使用者。而如果选择的公有的,你就有义务永远支持它,以保持兼容性。
对于成员(域和方法),访问级别共为4种:
● 私有的(private)——只有该成员的顶层类中才能访问
● 包级私有(package-private)——本包内任何类都可访问
● 保护的(protected)——本包内的任何类和所在类的子类都可以访问
● 公有的(public)——任何地方都可以访问
私有、保护、公有 是几乎所有人都知道的,但是包级私有取不敢这么说。再有一点就是保护的,一来说“所在类的子类都可以访问”是尽人皆知的,但和包级私有一样“本包内任何类都可访问”这一点同样不敢说是尽人皆知。
也正是这个“包级私有”得以让我们既可以按功能分解为不同的类,又可以不对外部开发访问权限。其实就我个人来说,如果能有一个“反import”,用以写明只对谁谁谁可访问才好呢,这样就不必把这样的一些类都拘泥于同一个包内了。
那么“包级私有”的修饰符是什么呢?其实什么都不写就是包级私有,如:
class PackagePrivateClass {
String name;
.....
}
看到这样的代码,如果是来自“高手”的,你大可不必去担心“这家伙是不是偷懒,或者疏忽漏掉了修饰符?”。但是,如果这段代码是来自“基层”的,我还是建议你最好多问个问什么。
最后,有一个小知识,或者叫小结论:具有公有的静态final数组域几乎总是错误的。注意这句话共有4个定语——公有的、静态的、final的、数组。
// 这可以肯定是错误的
public static final Type[] VALUES = { ... };
// 应该改成这样
private static final Type[] PRIVATE_VALUES = { ... };
public static final List VALUE = Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));
// 或者这样写(可能损失一点性能),前提是Type实现了克隆接口,而且你不反感克隆
private static final Type[] PRIVATE_VALUES = { ... };
public static final Type[] values() {
return (Type[]) PRIVATE_VALUES.clone();
}
总结一下,你应该总是尽量降低可访问性,否则你就有义务对你开放出去的东西负责到底。
看完这一条,我要做的是,重新审视一下我的 xxxx.util.support 包,这个包中的类都是用来对 util 里的类做支持的(幕后英雄)。根据本条的“精神”,我取消了 util.support包,转而把这些支持类都放入 util 包里,做成了包级私有类,这样这些support类就仅仅对util中的类负责了,在外部就看不到它们了,我就没有义务使它们永远保持兼容了。
另外,还有一点就是在util包中找到那些仅仅是为Framework中某些类服务的工具类,这些类的设计目的就不是给Framework的使用者用的,所以同样地把它们转移到被调用者的包里,做成包级私有(好在没有同时对两个及以上包提供服务的util类)。util包中只保留那些目的是给外部使用者服务的类。
【Effective Java 学习笔记】系列连载专题请见:
http://tonylian.iteye.com/categories/64208