本章概要
- 为什么需要内部类
- 闭包与回调
- 内部类与控制框架
- 继承内部类
- 内部类可以被重写么？
- 局部内部类
- 内部类标识符
为什么需要内部类
至此，我们已经看到了许多描述内部类的语法和语义，但是这并不能同答“为什么需要内部类”这个问题。那么，Java 设计者们为什么会如此费心地增加这项基本的语言特性呢？
一般说来，内部类继承自某个类或实现某个接口，内部类的代码操作创建它的外部类的对象。所以可以认为内部类提供了某种进入其外部类的窗口。
内部类必须要回答的一个问题是：如果只是需要一个对接口的引用，为什么不通过外部类实现那个接口呢？答案是：“如果这能满足需求，那么就应该这样做。”那么内部类实现一个接口与外部类实现这个接口有什么区别呢？答案是：后者不是总能享用到接口带来的方便，有时需要用到接口的实现。所以，使用内部类最吸引人的原因是：
每个内部类都能独立地继承自一个（接口的）实现，所以无论外部类是否已经继承了某个（接口的）实现，对于内部类都没有影响。
如果没有内部类提供的、可以继承多个具体的或抽象的类的能力，一些设计与编程问题就很难解决。从这个角度看，内部类使得多重继承的解决方案变得完整。接口解决了部分问题，而内部类有效地实现了“多重继承”。也就是说，内部类允许继承多个非接口类型（译注：类或抽象类）。
为了看到更多的细节，让我们考虑这样一种情形：即必须在一个类中以某种方式实现两个接口。由于接口的灵活性，你有两种选择；使用单一类，或者使用内部类：
// innerclasses/mui/MultiInterfaces.java
// Two ways a class can implement multiple interfaces
// {java innerclasses.mui.MultiInterfaces}
package innerclasses.mui;
interface A {
}
interface B {
}
class X implements A, B {
}
class Y implements A {
B makeB() {
// Anonymous inner class:
return new B() {
};
}
}
public class MultiInterfaces {
static void takesA(A a) {
}
static void takesB(B b) {
}
public static void main(String[] args) {
X x = new X();
Y y = new Y();
takesA(x);
takesA(y);
takesB(x);
takesB(y.makeB());
}
}
当然，这里假设在两种方式下的代码结构都确实有逻辑意义。然而遇到问题的时候，通常问题本身就能给出某些指引，告诉你是应该使用单一类，还是使用内部类。但如果没有任何其他限制，从实现的观点来看，前面的例子并没有什么区别，它们都能正常运作。
如果拥有的是抽象的类或具体的类，而不是接口，那就只能使用内部类才能实现多重继承：
// innerclasses/MultiImplementation.java
// For concrete or abstract classes, inner classes
// produce "multiple implementation inheritance"
// {java innerclasses.MultiImplementation}
package innerclasses;
class D {
}
abstract class E {
}
class Z extends D {
E makeE() {
return new E() {
};
}
}
public class MultiImplementation {
static void takesD(D d) {
}
static void takesE(E e) {
}
public static void main(String[] args) {
Z z = new Z();
takesD(z);
takesE(z.makeE());
}
}
如果不需要解决“多重继承”的问题，那么自然可以用别的方式编码，而不需要使用内部类。但如果使用内部类，还可以获得其他一些特性：
- 内部类可以有多个实例，每个实例都有自己的状态信息，并且与其外部类对象的信息相互独立。
- 在单个外部类中，可以让多个内部类以不同的方式实现同一个接口，或继承同一个类。
- 创建内部类对象的时刻并不依赖于外部类对象的创建
- 内部类并没有令人迷惑的"is-a”关系，它就是一个独立的实体。
举个例子，如果 Sequence.java 不使用内部类，就必须声明"Sequence 是一个 Selector"，对于某个特定的 Sequence 只能有一个 Selector，然而使用内部类很容易就能拥有另一个方法 reverseSelector()，用它来生成一个反方向遍历序列的 Selector，只有内部类才有这种灵活性。
闭包与回调
闭包（closure）是一个可调用的对象，它记录了一些信息，这些信息来自于创建它的作用域。通过这个定义，可以看出内部类是面向对象的闭包，因为它不仅包含外部类对象（创建内部类的作用域）的信息，还自动拥有一个指向此外部类对象的引用，在此作用域内，内部类有权操作所有的成员，包括 private 成员。
在 Java 8 之前，内部类是实现闭包的唯一方式。在 Java 8 中，我们可以使用 lambda 表达式来实现闭包行为，并且语法更加优雅和简洁，你将会在 函数式编程 这一章节中学习相关细节。尽管相对于内部类，你可能更喜欢使用 lambda 表达式实现闭包，但是你会看到并需要理解那些在 Java 8 之前通过内部类方式实现闭包的代码，因此仍然有必要来理解这种方式。
Java 最引人争议的问题之一就是，人们认为 Java 应该包含某种类似指针的机制，以允许回调（callback）。通过回调，对象能够携带一些信息，这些信息允许它在稍后的某个时刻调用初始的对象。稍后将会看到这是一个非常有用的概念。如果回调是通过指针实现的，那么就只能寄希望于程序员不会误用该指针。然而，读者应该已经了解到，Java 更小心仔细，所以没有在语言中包括指针。
通过内部类提供闭包的功能是优良的解决方案，它比指针更灵活、更安全。见下例：
// innerclasses/Callbacks.java
// Using inner classes for callbacks
// {java innerclasses.Callbacks}
package innerclasses;
interface Incrementable {
void increment();
}
// Very simple to just implement the interface:
class Callee1 implements Incrementable {
private int i = 0;
@Override
public void increment() {
i++;
System.out.println(i);
}
}
class MyIncrement {
public void increment() {
System.out.println("Other operation");
}
static void f(MyIncrement mi) {
mi.increment(); }
}
// If your class must implement increment() in
// some other way, you must use an inner class:
class Callee2 extends MyIncrement {
private int i = 0;
@Override
public void increment() {
super.increment();
i++;
System.out.println(i);
}
private class Closure implements Incrementable {
@Override
public void increment() {
// Specify outer-class method, otherwise
// you'll get an infinite recursion:
Callee2.this.increment();
}
}
Incrementable getCallbackReference() {
return new Closure();
}
}
class Caller {
private Incrementable callbackReference;
Caller(Incrementable cbh) {
callbackReference = cbh;
}
void go() {
callbackReference.increment(); }
}
public class Callbacks {
public static void main(String[] args) {
Callee1 c1 = new Callee1();
Callee2 c2 = new Callee2();
MyIncrement.f(c2);
Caller caller1 = new Caller(c1);
Caller caller2 =
new Caller(c2.getCallbackReference());
caller1.go();
caller1.go();
caller2.go();
caller2.go();
}
}
输出为：
这个例子进一步展示了外部类实现一个接口与内部类实现此接口之间的区别。就代码而言，Callee1 是更简单的解决方式。Callee2 继承自 MyIncrement，后者已经有了一个不同的 increment() 方法，并且与 Incrementable 接口期望的 increment() 方法完全不相关。所以如果 Callee2 继承了 MyIncrement，就不能为了 Incrementable 的用途而重写 increment() 方法，于是只能使用内部类独立地实现 Incrementable，还要注意，当创建了一个内部类时，并没有在外部类的接口中添加东西，也没有修改外部类的接口。
注意，在 Callee2 中除了 getCallbackReference() 以外，其他成员都是 private 的。要想建立与外部世界的任何连接，接口 Incrementable 都是必需的。在这里可以看到，interface 是如何允许接口与接口的实现完全独立的。
内部类 Closure 实现了 Incrementable，以提供一个返回 Callee2 的“钩子”（hook）-而且是一个安全的钩子。无论谁获得此 Incrementable 的引用，都只能调用 increment()，除此之外没有其他功能（不像指针那样，允许你做很多事情）。
Caller 的构造器需要一个 Incrementable 的引用作为参数（虽然可以在任意时刻捕获回调引用），然后在以后的某个时刻，Caller 对象可以使用此引用回调 Callee 类。
回调的价值在于它的灵活性-可以在运行时动态地决定需要调用什么方法。例如，在图形界面实现 GUI 功能的时候，到处都用到回调。
内部类与控制框架
在将要介绍的控制框架（control framework）中，可以看到更多使用内部类的具体例子。
应用程序框架（application framework）就是被设计用以解决某类特定问题的一个类或一组类。要运用某个应用程序框架，通常是继承一个或多个类，并重写某些方法。你在重写的方法中写的代码定制了该应用程序框架提供的通用解决方案，来解决你的具体问题。这是设计模式中_模板方法_的一个例子，模板方法包含算法的基本结构，而且会调用一个或多个可重写的方法来完成该算法的运算。设计模式总是将变化的事物与保持不变的事物分离开，在这个模式中，模板方法是保持不变的事物，而可重写的方法就是变化的事物。
控制框架是一类特殊的应用程序框架，它用来解决响应事件的需求。主要用来响应事件的系统被称作_事件驱动_系统。应用程序设计中常见的问题之一是图形用户接口（GUI），它几乎完全是事件驱动的系统。
要理解内部类是如何允许简单的创建过程以及如何使用控制框架的，请考虑这样一个控制框架，它的工作就是在事件“就绪ready()”的时候执行事件。虽然“就绪”可以指任何事，但在本例中是指基于时间触发的事件。下面是一个控制框架，它不包含具体的控制信息。那些信息是通过继承(当算法的 action() 部分被实现时)来提供的。
这里是描述了所有控制事件的接口。之所以用抽象类代替了真正的接口，是因为默认行为都是根据时间来执行控制的。也因此包含了一些具体实现：
// innerclasses/controller/Event.java
// The common methods for any control event
package innerclasses.controller;
import java.time.*; // Java 8 time classes
public abstract class Event {
private Instant eventTime;
protected final Duration delayTime;
public Event(long millisecondDelay) {
delayTime = Duration.ofMillis(millisecondDelay);
start();
}
public void start() {
// Allows restarting
eventTime = Instant.now().plus(delayTime);
}
public boolean ready() {
return Instant.now().isAfter(eventTime);
}
public abstract void action();
}
当希望运行 Event 并随后调用 start() 时，那么构造器就会捕获（从对象创建的时刻开始的）时间，此时间是这样得来的：start() 获取当前时间，然后加上一个延迟时间，这样生成触发事件的时间。start() 是一个独立的方法，而没有包含在构造器内，因为这样就可以在事件运行以后重新启动计时器，也就是能够重复使用 Event 对象。例如，如果想要重复一个事件，只需简单地在 action() 中调用 start() 方法。
ready() 告诉你何时可以运行 action() 方法了。当然，可以在派生类中重写 ready() 方法，使得 Event 能够基于时间以外的其他因素而触发。
下面的文件包含了一个用来管理并触发事件的实际控制框架。Event 对象被保存在 List<Event> 类型（读作“Event 的列表”）的容器对象中，容器会在 集合 中详细介绍。目前读者只需要知道 add() 方法用来将一个 Event 添加到 List 的尾端，size() 方法用来得到 List 中元素的个数，foreach 语法用来连续获取 List 中的 Event，remove() 方法用来从 List 中移除指定的 Event。
import java.util.*;
public class Controller {
// A class from java.util to hold Event objects:
private List<Event> eventList = new ArrayList<>();
public void addEvent(Event c) {
eventList.add(c);
}
public void run() {
while (eventList.size() > 0)
// Make a copy so you're not modifying the list
// while you're selecting the elements in it:
{
for (Event e : new ArrayList<>(eventList)) {
if (e.ready()) {
System.out.println(e);
e.action();
eventList.remove(e);
}
}
}
}
}
run() 方法循环遍历 eventList，寻找就绪的（ready()）、要运行的 Event 对象。对找到的每一个就绪的（ready()）事件，使用对象的 toString() 打印其信息，调用其 action() 方法，然后从列表中移除此 Event。
注意，在目前的设计中你并不知道 Event 到底做了什么。这正是此设计的关键所在—"使变化的事物与不变的事物相互分离”。用我的话说，“变化向量”就是各种不同的 Event 对象所具有的不同行为，而你通过创建不同的 Event 子类来表现不同的行为。
这正是内部类要做的事情，内部类允许：
- 控制框架的完整实现是由单个的类创建的，从而使得实现的细节被封装了起来。内部类用来表示解决问题所必需的各种不同的
action()。 - 内部类能够很容易地访问外部类的任意成员，所以可以避免这种实现变得笨拙。如果没有这种能力，代码将变得令人讨厌，以至于你肯定会选择别的方法。
考虑此控制框架的一个特定实现，如控制温室的运作：控制灯光、水、温度调节器的开关，以及响铃和重新启动系统，每个行为都是完全不同的。控制框架的设计使得分离这些不同的代码变得非常容易。使用内部类，可以在单一的类里面产生对同一个基类 Event 的多种派生版本。对于温室系统的每一种行为，都继承创建一个新的 Event 内部类，并在要实现的 action() 中编写控制代码。
作为典型的应用程序框架，GreenhouseControls 类继承自 Controller：
// innerclasses/GreenhouseControls.java
// This produces a specific application of the
// control system, all in a single class. Inner
// classes allow you to encapsulate different
// functionality for each type of event.
import innerclasses.controller.*;
public class GreenhouseControls extends Controller {
private boolean light = false;
public class LightOn extends Event {
public LightOn(long delayTime) {
super(delayTime);
}
@Override
public void action() {
// Put hardware control code here to
// physically turn on the light.
light = true;
}
@Override
public String toString() {
return "Light is on";
}
}
public class LightOff extends Event {
public LightOff(long delayTime) {
super(delayTime);
}
@Override
public void action() {
// Put hardware control code here to
// physically turn off the light.
light = false;
}
@Override
public String toString() {
return "Light is off";
}
}
private boolean water = false;
public class WaterOn extends Event {
public WaterOn(long delayTime) {
super(delayTime);
}
@Override
public void action() {
// Put hardware control code here.
water = true;
}
@Override
public String toString() {
return "Greenhouse water is on";
}
}
public class WaterOff extends Event {
public WaterOff(long delayTime) {
super(delayTime);
}
@Override
public void action() {
// Put hardware control code here.
water = false;
}
@Override
public String toString() {
return "Greenhouse water is off";
}
}
private String thermostat = "Day";
public class ThermostatNight extends Event {
public ThermostatNight(long delayTime) {
super(delayTime);
}
@Override
public void action() {
// Put hardware control code here.
thermostat = "Night";
}
@Override
public String toString() {
return "Thermostat on night setting";
}
}
public class ThermostatDay extends Event {
public ThermostatDay(long delayTime) {
super(delayTime);
}
@Override
public void action() {
// Put hardware control code here.
thermostat = "Day";
}
@Override
public String toString() {
return "Thermostat on day setting";
}
}
// An example of an action() that inserts a
// new one of itself into the event list:
public class Bell extends Event {
public Bell(long delayTime) {
super(delayTime);
}
@Override
public void action() {
addEvent(new Bell(delayTime.toMillis()));
}
@Override
public String toString() {
return "Bing!";
}
}
public class Restart extends Event {
private Event[] eventList;
public
Restart(long delayTime, Event[] eventList) {
super(delayTime);
this.eventList = eventList;
for(Event e : eventList)
addEvent(e);
}
@Override
public void action() {
for(Event e : eventList) {
e.start(); // Rerun each event
addEvent(e);
}
start(); // Rerun this Event
addEvent(this);
}
@Override
public String toString() {
return "Restarting system";
}
}
public static class Terminate extends Event {
public Terminate(long delayTime) {
super(delayTime);
}
@Override
public void action() {
System.exit(0); }
@Override
public String toString() {
return "Terminating";
}
}
}
注意，light，water 和 thermostat 都属于外部类 GreenhouseControls，而这些内部类能够自由地访问那些字段，无需限定条件或特殊许可。而且，action() 方法通常都涉及对某种硬件的控制。
大多数 Event 类看起来都很相似，但是 Bell 和 Restart 则比较特别。Bell 控制响铃，然后在事件列表中增加一个 Bell 对象，于是过一会儿它可以再次响铃。读者可能注意到了内部类是多么像多重继承：Bell 和 Restart 有 Event 的所有方法，并且似乎也拥有外部类 GreenhouseContrlos 的所有方法。
一个由 Event 对象组成的数组被递交给 Restart，该数组要加到控制器上。由于 Restart() 也是一个 Event 对象，所以同样可以将 Restart 对象添加到 Restart.action() 中，以使系统能够有规律地重新启动自己。
下面的类通过创建一个 GreenhouseControls 对象，并添加各种不同的 Event 对象来配置该系统，这是 命令 设计模式的一个例子—eventList 中的每个对象都被封装成对象的请求：
// innerclasses/GreenhouseController.java
// Configure and execute the greenhouse system
import innerclasses.controller.*;
public class GreenhouseController {
public static void main(String[] args) {
GreenhouseControls gc = new GreenhouseControls();
// Instead of using code, you could parse
// configuration information from a text file:
gc.addEvent(gc.new Bell(900));
Event[] eventList = {
gc.new ThermostatNight(0),
gc.new LightOn(200),
gc.new LightOff(400),
gc.new WaterOn(600),
gc.new WaterOff(800),
gc.new ThermostatDay(1400)
};
gc.addEvent(gc.new Restart(2000, eventList));
gc.addEvent(new GreenhouseControls.Terminate(5000));
gc.run();
}
}
输出为：
这个类的作用是初始化系统，所以它添加了所有相应的事件。Restart 事件反复运行，而且它每次都会将 eventList 加载到 GreenhouseControls 对象中。如果提供了命令行参数，系统会以它作为毫秒数，决定什么时候终止程序（这是测试程序时使用的）。
当然，更灵活的方法是避免对事件进行硬编码。
这个例子应该使读者更了解内部类的价值了，特别是在控制框架中使用内部类的时候。
继承内部类
因为内部类的构造器必须连接到指向其外部类对象的引用，所以在继承内部类的时候，事情会变得有点复杂。问题在于，那个指向外部类对象的“秘密的”引用必须被初始化，而在派生类中不再存在可连接的默认对象。要解决这个问题，必须使用特殊的语法来明确说清它们之间的关联：
// innerclasses/InheritInner.java
// Inheriting an inner class
class WithInner {
class Inner {
}
}
public class InheritInner extends WithInner.Inner {
//- InheritInner() {} // Won't compile
InheritInner(WithInner wi) {
wi.super();
}
public static void main(String[] args) {
WithInner wi = new WithInner();
InheritInner ii = new InheritInner(wi);
}
}
可以看到，InheritInner 只继承自内部类，而不是外部类。但是当要生成一个构造器时，默认的构造器并不算好，而且不能只是传递一个指向外部类对象的引用。此外，必须在构造器内使用如下语法：
enclosingClassReference.super();
这样才提供了必要的引用，然后程序才能编译通过。
内部类可以被重写么？
如果创建了一个内部类，然后继承其外部类并重新定义此内部类时，会发生什么呢？也就是说，内部类可以被重写吗？这看起来似乎是个很有用的思想，但是“重写”内部类就好像它是外部类的一个方法，其实并不起什么作用：
// innerclasses/BigEgg.java
// An inner class cannot be overridden like a method
class Egg {
private Yolk y;
protected class Yolk {
public Yolk() {
System.out.println("Egg.Yolk()");
}
}
Egg() {
System.out.println("New Egg()");
y = new Yolk();
}
}
public class BigEgg extends Egg {
public class Yolk {
public Yolk() {
System.out.println("BigEgg.Yolk()");
}
}
public static void main(String[] args) {
new BigEgg();
}
}
输出为：
New Egg()
Egg.Yolk()
默认的无参构造器是编译器自动生成的，这里是调用基类的默认构造器。你可能认为既然创建了 BigEgg 的对象，那么所使用的应该是“重写后”的 Yolk 版本，但从输出中可以看到实际情况并不是这样的。
这个例子说明，当继承了某个外部类的时候，内部类并没有发生什么特别神奇的变化。这两个内部类是完全独立的两个实体，各自在自己的命名空间内。当然，明确地继承某个内部类也是可以的：
// innerclasses/BigEgg2.java
// Proper inheritance of an inner class
class Egg2 {
protected class Yolk {
public Yolk() {
System.out.println("Egg2.Yolk()");
}
public void f() {
System.out.println("Egg2.Yolk.f()");
}
}
private Yolk y = new Yolk();
Egg2() {
System.out.println("New Egg2()"); }
public void insertYolk(Yolk yy) {
y = yy; }
public void g() {
y.f(); }
}
public class BigEgg2 extends Egg2 {
public class Yolk extends Egg2.Yolk {
public Yolk() {
System.out.println("BigEgg2.Yolk()");
}
@Override
public void f() {
System.out.println("BigEgg2.Yolk.f()");
}
}
public BigEgg2() {
insertYolk(new Yolk()); }
public static void main(String[] args) {
Egg2 e2 = new BigEgg2();
e2.g();
}
}
输出为：
现在 BigEgg2.Yolk 通过 extends Egg2.Yolk 明确地继承了此内部类，并且重写了其中的方法。insertYolk() 方法允许 BigEgg2 将它自己的 Yolk 对象向上转型为 Egg2 中的引用 y。所以当 g() 调用 y.f() 时，重写后的新版的 f() 被执行。第二次调用 Egg2.Yolk()，结果是 BigEgg2.Yolk 的构造器调用了其基类的构造器。可以看到在调用 g() 的时候，新版的 f() 被调用了。
局部内部类
前面提到过，可以在代码块里创建内部类，典型的方式是在一个方法体的里面创建。局部内部类不能有访问说明符，因为它不是外部类的一部分；但是它可以访问当前代码块内的常量，以及此外部类的所有成员。下面的例子对局部内部类与匿名内部类的创建进行了比较。
interface Counter {
int next();
}
public class LocalInnerClass {
private int count = 0;
Counter getCounter(final String name) {
// A local inner class:
class LocalCounter implements Counter {
LocalCounter() {
// Local inner class can have a constructor
System.out.println("LocalCounter()");
}
@Override
public int next() {
System.out.print(name); // Access local final
return count++;
}
}
return new LocalCounter();
}
// Repeat, but with an anonymous inner class:
Counter getCounter2(final String name) {
return new Counter() {
// Anonymous inner class cannot have a named
// constructor, only an instance initializer:
{
System.out.println("Counter()");
}
@Override
public int next() {
System.out.print(name); // Access local final
return count++;
}
};
}
public static void main(String[] args) {
LocalInnerClass lic = new LocalInnerClass();
Counter
c1 = lic.getCounter("Local inner "),
c2 = lic.getCounter2("Anonymous inner ");
for (int i = 0; i < 5; i++) {
System.out.println(c1.next());
}
for (int i = 0; i < 5; i++) {
System.out.println(c2.next());
}
}
}
输出为：
Counter 返回的是序列中的下一个值。我们分别使用局部内部类和匿名内部类实现了这个功能，它们具有相同的行为和能力，既然局部内部类的名字在方法外是不可见的，那为什么我们仍然使用局部内部类而不是匿名内部类呢？唯一的理由是，我们需要一个已命名的构造器，或者需要重载构造器，而匿名内部类只能使用实例初始化。
所以使用局部内部类而不使用匿名内部类的另一个理由就是，需要不止一个该内部类的对象。
内部类标识符
由于编译后每个类都会产生一个 .class 文件，其中包含了如何创建该类型的对象的全部信息（此信息产生一个"meta-class"，叫做 Class 对象）。
你可能猜到了，内部类也必须生成一个 .class 文件以包含它们的 Class 对象信息。这些类文件的命名有严格的规则：外部类的名字，加上 “$” ，再加上内部类的名字。例如，LocalInnerClass.java 生成的 .class 文件包括：
Counter.class
LocalInnerClass$1.class
LocalInnerClass$1LocalCounter.class
LocalInnerClass.class
如果内部类是匿名的，编译器会简单地产生一个数字作为其标识符。如果内部类是嵌套在别的内部类之中，只需直接将它们的名字加在其外部类标识符与 “$” 的后面。
虽然这种命名格式简单而直接，但它还是很健壮的，足以应对绝大多数情况。因为这是 Java 的标准命名方式，所以产生的文件自动都是平台无关的。（注意，为了保证你的内部类能起作用，Java 编译器会尽可能地转换它们。）