一、接口中的域
因为你放入接口中的任何域都自动是static和final的，所以接口就成为了一种很便捷的用来创建常量组的工具。在java SE5之前，这是产生于C或C++中的enum（枚举类型）具有相同效果的类型的唯一途径。因此在java SE5之前的代码中你会看到下面这样的代码：
public interface Months {
int JANUARY = 1, FEBRUARY = 2, MARCH = 3, APRIL = 4, MAY = 5, JUNE = 6, JULY = 7, AUGUST = 8, SEPTEMBER = 9,
OCTOBER = 10, NOVEMBER = 11, DECEMBER = 12;
}请注意，java中标识具有常量初始化值的static final时，会使用大写字母的风格（在一个标识符中用下划线来分隔多个单词）。接口中的域自动是public的，所以没有显式地指明这一点。
有了java SE5，你就可以使用更加强大而灵活的enum关键字，因此，使用接口来群组常量已经显得没有什么意义了。
二、初始化接口中的域
在接口中定义的域不能是“空final”，但是可以被非常量表达式初始化。例如：
import java.util.Random;
public interface RandVals {
Random r = new Random();
int RANDOM_INT = r.nextInt(10);
long RANDOM_LONG = r.nextLong() * 10;
float RANDOM_FLOAT = r.nextFloat() * 10;
double RANDOM_DOUBLE = r.nextDouble() * 10;
}既然域是static的，它们就可以在类第一次被加载时初始化，这发生在任何域首次被访问时，这里给出一个简单的测试：
public class TestRandVals {
public static void main(String[] args) {
System.out.println(RandVals.RANDOM_INT);
System.out.println(RandVals.RANDOM_LONG);
System.out.println(RandVals.RANDOM_FLOAT);
System.out.println(RandVals.RANDOM_DOUBLE);
}
}当然，这些域不是接口的一部分，它们的值被存储在该接口的静态存储区域内。
三、嵌套接口
接口可以嵌套在类或其他接口中。这揭示了许多非常有趣的特性：
class A {
interface B {
void f();
}
public class BImpl implements B {
@Override
public void f() {
}
}
private class BImpl2 implements B {
@Override
public void f() {
}
}
public interface C {
void f();
}
class CImpl implements C {
@Override
public void f() {
}
}
private class CImpl2 implements C {
@Override
public void f() {
}
}
private interface D {
void f();
}
private class DImpl implements D {
@Override
public void f() {
}
}
public class DImpl2 implements D {
@Override
public void f() {
}
}
public D getD() {
return new DImpl2();
}
private D dRef;
public void receiveD(D d) {
dRef = d;
dRef.f();
}
}
interface E {
interface G {
void f();
}
public interface H {
void f();
}
void g();
// The interface member type I can only be public
// private interface I {}
}
/**
* 嵌套接口
*/
public class NestingInterfaces {
public class BImpl implements A.B {
@Override
public void f() {
}
}
class CImpl implements A.C {
@Override
public void f() {
}
}
// class DImpl implements A.D{
// @Override
// public void f() {
// }
// }
class EImpl implements E {
@Override
public void g() {
}
}
class EGImpl implements E.G {
@Override
public void f() {
}
}
class EImpl2 implements E {
@Override
public void g() {
}
class EG implements E.G {
@Override
public void f() {
}
}
}
public static void main(String[] args) {
A a = new A();
// A.D ad=a.getD();
// A.DImpl2 di2 = a.getD();
// a.getD().f();
A a2 = new A();
a2.receiveD(a.getD());
}
}在类中嵌套接口的语法是相当显而易见的，就像非嵌套接口一样，可以拥有public和“包访问”两种可视性。
作为一种新添加的方式，接口也可以被实现为private的，就像在A.D中所看到的（相同的语法既适用于嵌套接口，也适用于嵌套类）。那么private的嵌套接口能带来什么好处呢？你可能会猜想，它只能够被实现为DImpl中的一个private内部类，但是A.DImpl2展示了它同样可以被实现为public类。但是，A.DIml2只能被其自身所使用。你无法说它实现了一个private接口D。因此，实现一个private接口只是一种方式，它可以强制该接口中的方法定义不要添加任何类型信息（也就是说，不允许向上转型）。
getD()方法使我们陷入了一个进退两难的境地，这个问题与private接口相关：它是一个返回对private接口的引用的public方法。你对这个方法的返回值能做些什么呢？在main()中，可以看到数次尝试使用返回值的行为都失败了。只有一种方式可成功，那就是将返回值交给有权使用它的对象。在本例中，是另一个A通过receiveD()方法来实现的。
接口E说明接口彼此之间也可以嵌套。然而，作用于接口的各种规则，特别是所有的接口元素都必须是public的，在此都会被严格执行。因此，嵌套在另一个接口中的接口自动就是public的，而不能声明为private。
NestingInterfaces展示了嵌套接口的各种实现方式。特别要注意的是，当实现某个接口时，并不需要实现嵌套在其内部的任何接口。而且，private接口不能在定义它的类之外被实现。
添加这些特性的最初原因可能是出于对严格的语法一致性的考虑，但是我总认为，一旦你了解了某种特性，就总能够找到它的用武之地。
四、接口与工厂
接口是实现多重继承的途径，而生成遵循某个接口的对象的典型方式就是工厂方法设计模式。这与直接调用构造器不同，我们在工厂对象上调用的是创建方法，而该工厂对象将生成接口的某个实现的对象。理论上，通过这种方式，我们的代码将完全与接口的实现分离，这就使得我们可以透明地将某个实现替换为另一个实现。下面的实例展示了工厂方法的结构：
interface Service {
void method1();
void method2();
}
interface ServiceFactory {
Service getService();
}
class Implementation1 implements Service {
Implementation1() {
}
@Override
public void method1() {
System.out.println("Implementation1 method1");
}
@Override
public void method2() {
System.out.println("Implementation1 method2");
}
}
class Implementation1Factory implements ServiceFactory {
@Override
public Service getService() {
return new Implementation1();
}
}
class Implementation2 implements Service {
Implementation2() {
}
@Override
public void method1() {
System.out.println("Implementation2 method1");
}
@Override
public void method2() {
System.out.println("Implementation2 method2");
}
}
class Implementation2Factory implements ServiceFactory {
@Override
public Service getService() {
return new Implementation2();
}
}
public class Factories {
public static void serviceConsumer(ServiceFactory fact) {
Service s = fact.getService();
s.method1();
s.method2();
}
public static void main(String[] args) {
serviceConsumer(new Implementation1Factory());
serviceConsumer(new Implementation2Factory());
}
}如果不是用工厂方法，你的代码就必须在某处指定将要创建的Service的确切类型，以便调用合适的构造器。
为什么我们想要添加这种额外级别的间接性呢？一个常见的原因是想要创建框架：假设你正在创建一个对弈游戏系统，例如，在相同的棋盘上下国际象棋和西洋跳棋：
interface Game {
boolean move();
}
interface GameFactory {
Game getGame();
}
/**
* 西洋跳棋
*/
class Checkers implements Game {
private int moves = 0;
private static final int MOVES = 3;
@Override
public boolean move() {
System.out.println("Checkers move " + moves);
return ++moves != MOVES;
}
}
class CheckersFactory implements GameFactory {
@Override
public Game getGame() {
return new Checkers();
}
}
/**
* 国际象棋
*/
class Chess implements Game {
private int moves = 0;
private static final int MOVES = 4;
@Override
public boolean move() {
System.out.println("Chess move " + moves);
return ++moves != MOVES;
}
}
class ChessFactory implements GameFactory {
@Override
public Game getGame() {
return new Chess();
}
}
public class Games {
public static void playGame(GameFactory factory) {
Game s = factory.getGame();
while (s.move())
;
}
public static void main(String[] args) {
playGame(new CheckersFactory());
playGame(new ChessFactory());
}
}如果Games类表示一段复杂的代码，那么这种方式就允许你在不同类型的游戏中复用这段代码。你可以在想象一些能够从这个模式中受益的更加精巧的游戏。
五、总结
“确定接口是理想选择，因而应该总是选择接口而不是具体的类。”这其实是一种引诱。当然，对于创建类，几乎在任何时刻，都可以替代为创建一个接口和一个工厂。
许多人都掉进了这种诱惑的陷阱，只要有可能就去创建接口和工厂。这种逻辑看起来好像是因为需要使用不同的具体实现，因此总是应该添加这种抽象性。这实际上已经变成了一种草率的设计优化。
任何抽象性都应该是应真正的需求而产生的。当必需时，你应该重构接口而不是到处添加额外级别的间接性，并由此带来的额外的复杂性。这种额外的复杂性非常显著，如果你让某人去处理这种复杂性，只是因为你意识到由于以防万一而添加了新接口，而没有其他更有说服力的原因，那么好吧，如果我碰上了这种事，那么就会质疑此人所作的所有设计了。
恰当的原则应该是优先选择类而不是接口。从类开始，如果接口的必需性变得非常明确，那么就进行重构。接口是一种重要的工具，但是它们容易被滥用。
如果本文对您有很大的帮助，还请点赞关注一下。
