内部类和上溯造型

核心提示：迄今为止，内部类看起来仍然没什么非凡的地方，内部类和上溯造型，究竟，用它实现隐藏显得有些大题小做，注重Contents不必成为一个抽象类，在这儿也可以使用一个普通类，java已经有一个非常优秀的隐藏机制——只答应类成为“友好的”（只在一个包内可见），而不是把它创建成一个内部类

　　迄今为止，内部类看起来仍然没什么非凡的地方。究竟，用它实现隐藏显得有些大题小做。java已经有一个非常优秀的隐藏机制——只答应类成为“友好的”（只在一个包内可见），而不是把它创建成一个内部类。
　　
　　然而，当我们预备上溯造型到一个基础类（非凡是到一个接口）的时候，内部类就开始发挥其要害作用（从用于实现的对象生成一个接口句柄具有与上溯造型至一个基础类相同的效果）。这是由于内部类随后可完全进入不可见或不可用状态——对任何人都将如此。所以我们可以非常方便地隐藏实施细节。我们得到的全部回报就是一个基础类或者接口的句柄，而且甚至有可能不知道准确的类型。就象下面这样：
　　
　　//: Parcel3.java
　　// Returning a handle to an inner class
　　package c07.parcel3;
　　
　　abstract class Contents {
　　　abstract public int value();
　　}
　　
　　interface Destination {
　　　String readLabel();
　　}
　　
　　public class Parcel3 {
　　　PRivate class PContents extends Contents {
　　　　private int i = 11;
　　　　public int value() { return i; }
　　　}
　　　protected class PDestination
　　　　　implements Destination {
　　　　private String label;
　　　　private PDestination(String whereTo) {
　　　　　label = whereTo;
　　　　}
　　　　public String readLabel() { return label; }
　　　}
　　　public Destination dest(String s) {
　　　　return new PDestination(s);
　　　}
　　　public Contents cont() {
　　　　return new PContents();
　　　}
　　}
　　
　　class Test {
　　　public static void main(String[] args) {
　　　　Parcel3 p = new Parcel3();
　　　　Contents c = p.cont();
　　　　Destination d = p.dest("Tanzania");
　　　　// Illegal -- can't access private class:
　　　　//! Parcel3.PContents c = p.new PContents();
　　　}
　　} ///:~
　　
　　现在，Contents和Destination代表可由客户程序员使用的接口（记住接口会将自己的所有成员都变成public属性）。为方便起见，它们置于单独一个文件里，但原始的Contents和Destination在它们自己的文件中是相互public的。
　　
　　在Parcel3中，一些新东西已经加入：内部类PContents被设为private，所以除了Parcel3之外，其他任何东西都不能访问它。PDestination被设为protected，所以除了Parcel3，Parcel3包内的类（因为protected也为包赋予了访问权；也就是说，protected也是“友好的”），以及Parcel3的继续者之外，其他任何东西都不能访问PDestination。这意味着客户程序员对这些成员的熟悉与访问将会受到限制。事实上，我们甚至不能下溯造型到一个private内部类（或者一个protected内部类，除非自己本身便是一个继续者），因为我们不能访问名字，就象在classTest里看到的那样。所以，利用private内部类，类设计人员可完全禁止其他人依靠类型编码，并可将具体的实施细节完全隐藏起来。除此以外，从客户程序员的角度来看，一个接口的范围没有意义的，因为他们不能访问不属于公共接口类的任何额外方法。这样一来，Java编译器也有机会生成效率更高的代码。
　　
　　普通（非内部）类不可设为private或protected——只答应public或者“友好的”。
　　
　　注重Contents不必成为一个抽象类。在这儿也可以使用一个普通类，但这种设计最典型的起点依然是一个“接口”。