[转]Java在Interface方面的缺陷

转自： http://blog.csdn.net/alexjames_83/archive/2005/04/14/347726.aspx

OO设计中有一个重要原则：结构（mechanism）与策略（Policy）分离。Interface是实践这一原则的重要途径。

从概念上将，Interface用来扮演使用者与实现者之间的契约（contract）。我们使用Interface来定义一组Abstract Operation（method）的集合，用实现类实现这些Interface，调用者通过访问这些Interface的实现类所提供的相应服务。调用者并不关心接口是由谁实现的，它看到的只有Interface本身。

                         Contract
|-----------| Realize |-------------|       
|  Class A  |-------->| Interface A | Access |------|
|-----------|         |-------------|<-------|Caller|
                      |+Operation1()|        |------|
|-----------| Realize |+Operation2()|
|  Class B  |-------->|-------------|
|-----------|

在定义Interface Specification的时候一定要基于上述Interface的意义来进行。而Java的Interface设计就存在着缺陷。

在Java中，一个Class可以从另外一个Class继承，同时可以实现多个Interface。所以，一个Method既可以从base class那里继承过来，也可以是要实现的Interface Method。而Java的Method Signature由Method Name和Parameter List组成。这就意味着Java无从区分来自于Class继承体系的method和Interface实现体系的method。这会造成很大的困惑。

例如，我们从Vendor A和Vendor B处各购买了一套Java包，我们不妨称之为Package A和Package B。在Package A中，有一套Container的继承

体系，在Package B中有一套通过实现IContainer构成的一套Container体系。如下图所示：

(见附件)

现在我们想增加一个新的容器类PowerVector，对于它，我们即想让其相容与Package A的Container架构，又想让其相容于Package B的Container体系。于是，我们让PowerVector从Vector类继承，同时让其实现IContainer。正如图中所画的那样。

这是一个再自然不过的方法。但问题是，PowerVector从Vector（Container）继承了size方法，同时要实现IContainer的size方法。这个来自两个供应商的两套体系价构的方法在Java中有着完全相同的签名，但却包含完全不同的含义。在Package A的Container体系中，size方法用来查询Container的容量（capability）；在Package B中，size方法却被用来计算Container所存放的Item的数量。

而使用Java，由于size方法的签名完全相同，所以在PowerVector中，你只有两种选择，继承或改写（override）Vector的size方法。如果是继承，那么通过IContainer的size方法就得到了错误的结果。如果为了迎合IContainer而改写，则通过Package A的Container体系来访问size方法时，同样是错误的。

你或许会说：这个很简单，把其中一套体系的size方法改变签名不就行了吗？这是一个没有动脑的建议。想想看，由于Package A和Package B来自于两个不同的供应商，它们在开发各自的Package时，根本不会考虑别人是否会如何命名。而在自己的体系中，已经有大量的类在使用自己体系的定义。修改任何一个都会很麻烦。更何况，你拿到的很有可能是编译后的包，根本就无从改起。

如果你是个Java高手，你或许可以通过一些特殊的架构或方法解决掉这个问题。但那些方法都不是最自然的方法。而一个设计充分的语言，应该让设计师或程序员能够用最自然的方法表现自己的意图。

我们上面所给出的例子并不是一个特殊的情况。而是一种经常会出现的case。只所以Java设计出现了这样的问题，是因为Java语言的设计师根本没有深刻理解在这一问题上的OO思想。

这是因为，虽然Java仅仅允许但继承，但却允许实现多个接口，那么一个Class所拥有的Operation(Method)就会来自于多条线。而每一条线都有可能由不同的人，不同的公司来设计，虽然对于Class或Interface的签名，由于Sun建议了Package的命名规则，所以，可以避免签名冲突，但对于method的签名，按照Java的method signature规则，产生冲突的可能性是很大的。而相同签名的method，很有可能具有很大差异的含义。

从本质上说，当如果一个Class继承了另外一个Class，同时实现了一个或多个Interface，或者，仅仅实现了多个接口时，如果这些Interface和Class具有相同签名的method（按照Java的签名原则），这些method应该被看作具有不同签名的method。应该对其分别看待。比如：

// 下面的代码即不是Java code也不是C++ code，而是一种伪code
public class Base{
  public int foo() { return 0; }
}

public interface IFoo{
  int foo();
}

public class Derived extends Base implements IFoo
{
  // 还存在着一个继承自Base的foo method
  int IFoo::foo() { return 10; } //需要指明这是IFoo的foo mothed的实现
}

这样，如果我们有这样一段code,

Derived derived = new Derived;
derived.foo(); // 调用的是Base::foo
IFoo ifoo = (IFoo)derived;
ifoo.foo(); // 调用的是Base::IFoo::foo

另外一个例子：
public interface IFoo1{
  int foo();
}

public interface IFoo2{
  int foo();
}

public class Foo implements IFoo1, IFoo2
{
  //需要分别指明IFoo1和IFoo2的foo mothed实现
  int IFoo1::foo() { return 0; }
  int IFoo2::foo() { return 10; }
}

Foo obj = new Foo;
IFoo1 foo1 = (IFoo1)obj;
foo1.foo(); // 调用的是Foo::IFoo1::foo
IFoo2 foo2 = (IFoo1)obj;
foo2.foo(); // 调用的是Foo::IFoo2::foo

对于这种解决方案，随之产生的一个问题是，如果我们在一个class内实现了一个Interface，而我们基于这个class的引用来访问这个class的instance时，我们如何访问这些interface methods?

我对答案就是：不允许访问，因为，这些方法的存在是因为这个class实现了方法所在的接口，这些方法的实现定义了契约履行的行为，也就是说他们是契约被执行过程的一部分。既然接口是调用者和服务提供者之间的契约，那么访问它们的途径当然也应该通过接口。这是完全符合Interface的语义的。如果你真想访问这些interface method，可以把它们包装为class method。

由于接口允许扩展其它接口，就会产生这样的问题：

public interface IFooBase{
  int foo();
}

public interface IFoo1 extends IFooBase{
  void draw();
}

public interface IFoo2 extends IFooBase{
  void move();
}

public class Foo implements IFoo1, IFoo2 { ... }

这种情况下，IFoo1和IFoo2都从IFooBase那继承了foo方法，如果我们在class Foo中分别为这两个foo进行实现，就会存在问题，比如：

Foo obj = new Foo;
IFooBase foo0 = (IFoo1) obj;
foo0.foo(); //???到底调用的哪个实现？？

所以，对于这种情况，我们必须规定，如果两个或多个接口都扩展了某个接口，并且随后这些接口被同一个Class实现的时候，你不能分别为其实现，而是要直接指定base interface的方法实现。以上例为例，其实现应该为：

public class Foo implements IFoo1, IFoo2 {
  int IFooBase::foo() { return 0; }
  void IFoo1::draw() { ... }
  void IFoo2::move() { ... }
}

对于这种情况，还有一种表现形式：

public class Base implements IFoo1{
  int IFoo1::foo() { return 0; } // 这里，我们只需要指定IFoo1即可
  void IFoo1::draw() { ... }
}

public class Derived extends Base implements IFoo2{
  void IFoo2::move() { ... }
  // 对于IFoo2::foo()，由于在Base中已经实现，
  // 我们可以继承其实现，也可以改写它。
  // 但在改写的时候，我们使用什么名字呢？
  // IFoo1::foo()? IFoo2::foo()? 还是IFooBase::foo()
}

这种情况下，随意指定范围会引起很大的困惑。为了避免这种问题，我们可以做出这样的规定：当我们在实现一个接口的时候，对于每一个method，我们都指定其定义所在的Interface，而不是扩展后的Interface。按照这个规定，我们上例的实现应该为：

public class Base implements IFoo1{
  int IFooBase::foo() { return 0; } // 这里，我们必须指定IFooBase
  void IFoo1::draw() { ... }
}

public class Derived extends Base implements IFoo2{
  void IFoo2::move() { ... }
  // 对于IFooBase::foo()，由于在Base中已经实现，
  // 我们可以继承其实现，也可以改写它。
  // 但在改写的时候，我们仍然必须使用IFooBase::foo()
}

上述的一切就形成了一个完整的Interface解决方案，按照这种方案，设计师及程序员就可以自然、直观、正确的使用接口进行OO的架构设计。同时也期望Java能够在未来的版本中解决掉这个缺陷。

评论

2 楼 dylan0514sina.cn 2013-04-02  

andylo25 写道

个人觉得java的设计师应该考虑到了这些情况，因为这个现象或者说bug很明显，不可能没发现，但是为什么不去“修复”,个人觉得是一个取舍的问题，操作简单，代码清晰，约定是java的一个比较明显的特点。是否为了一个低概率出现甚至可以通过其他方式避免的情况致使代码像C++一样“难看”，这是有待商榷的。因为这种（IFooBase::foo()）写法很不符合java的风格。

同意

1 楼 andylo25 2012-12-10  

个人觉得java的设计师应该考虑到了这些情况，因为这个现象或者说bug很明显，不可能没发现，但是为什么不去“修复”,个人觉得是一个取舍的问题，操作简单，代码清晰，约定是java的一个比较明显的特点。是否为了一个低概率出现甚至可以通过其他方式避免的情况致使代码像C++一样“难看”，这是有待商榷的。因为这种（IFooBase::foo()）写法很不符合java的风格。