为什么Java中继承多数是有害的

大多数好的设计者象躲避瘟疫一样来避免使用实现继续(extends 关系)。实际上80%的代码应该完全用interfaces写，而不是通过extends。“Java设计模式”一书具体阐述了怎样用接口继续代替实现继续。这篇文章描述设计者为什么会这么作。

　　Extends是有害的；也许对于Charles Manson这个级别的不是，但是足够糟糕的它应该在任何可能的时候被避开。“JAVA设计模式”一书花了很大的部分讨论用interface继续代替实现继续。

　　好的设计者在他的代码中，大部分用interface，而不是具体的基类。本文讨论为什么设计者会这样选择，并且也介绍一些基于interface的编程基础。

　　接口（Interface）和类（Class）?

　　一次，我参加一个Java用户组的会议。在会议中，Jams Gosling（Java之父）做发起人讲话。在那令人难忘的Q&A部分中，有人问他：“假如你重新构造Java，你想改变什么？”。“我想抛弃classes”他回答。在笑声平息后，它解释说，真正的问题不是由于class本身，而是实现继续(extends) 关系。接口继续（implements关系）是更好的。你应该尽可能的避免实现继续。

　　失去了灵活性

　　为什么你应该避免实现继续呢？第一个问题是明确的使用具体类名将你固定到特定的实现，给底层的改变增加了不必要的困难。

　　在当前的灵敏编程方法中，核心是并行的设计和开发的概念。在你具体设计程序前，你开始编程。这个技术不同于传统方法的形式----传统的方式是设计应该在编码开始前完成----但是许多成功的项目已经证实你能够更快速的开发高质量代码，相对于传统的按部就班的方法。但是在并行开发的核心是主张灵活性。你不得不以某一种方式写你的代码以至于最新发现的需求能够尽可能没有痛苦的合并到已有的代码中。

　　胜于实现你也许需要的特征，你只需实现你明确需要的特征，而且适度的对变化的包容。假如你没有这种灵活，并行的开发，那简直不可能。

　　对于Inteface的编程是灵活结构的核心。为了说明为什么，让我们看一下当使用它们的时候，会发生什么。考虑下面的代码：

f()
{
　LinkedList list = new LinkedList();
　//...
　g( list );
}

g( LinkedList list )
{
　list.add( ... );
　g2( list )
}
　　假设一个对于快速查询的需求被提出，以至于这个LinkedList不能够解决。你需要用HashSet来代替它。在已有代码中，变化不能够局部化，因为你不仅仅需要修改f()也需要修改g()（它带有LinkedList参数），并且还有g()把列表传递给的任何代码。象下面这样重写代码:

f()
{
　Collection list = new LinkedList();
　//...
　g( list );
}

g( Collection list )
{
　list.add( ... );
　g2( list )
}
　　这样修改Linked list成hash，可能只是简单的用new HashSet()代替new LinkedList()。就这样。没有其他的需要修改的地方。

　　作为另一个例子，比较下面两段代码：

f()
{
　Collection c = new HashSet();
　//...
　g( c );
}

g( Collection c )
{
　for( Iterator i = c.iterator(); i.hasNext() )
　　do_something_with( i.next() );
}
　　和

f2()
{
　Collection c = new HashSet();
　//...
　g2( c.iterator() );
}

g2( Iterator i )
{
　while( i.hasNext() )
　　do_something_with( i.next() );
}
　　g2()方法现在能够遍历Collection的派生，就像你能够从Map中得到的键值对。事实上，你能够写iterator，它产生数据，代替遍历一个Collection。你能够写iterator，它从测试的框架或者文件中得到信息。这会有巨大的灵活性。

　　耦合

　　对于实现继续，一个更加要害的问题是耦合---令人烦躁的依靠，就是那种程序的一部分对于另一部分的依靠。全局变量提供经典的例子，证实为什么强耦合会引起麻烦。例如，假如你改变全局变量的类型，那么所有用到这个变量的函数也许都被影响，所以所有这些代码都要被检查，变更和重新测试。而且，所有用到这个变量的函数通过这个变量相互耦合。也就是，假如一个变量值在难以使用的时候被改变，一个函数也许就不正确的影响了另一个函数的行为。这个问题显著的隐藏于多线程的程序。

　　作为一个设计者，你应该努力最小化耦合关系。你不能一并消除耦合，因为从一个类的对象到另一个类的对象的方法调用是一个松耦合的形式。你不可能有一个程序，它没有任何的耦合。然而，你能够通过遵守OO规则，最小化一定的耦合（最重要的是，一个对象的实现应该完全隐藏于使用他的对象）。例如，一个对象的实例变量（不是常量的成员域），应该总是private。我意思是某段时期的，无例外的，不断的。（你能够偶然有效地使用protected方法，但是protected实例变量是可憎的事）同样的原因你应该不用get/set函数---他们对于是一个域公用只是使人感到过于复杂的方式（尽管返回修饰的对象而不是基本类型值的访问函数是在某些情况下是由原因的，那种情况下，返回的对象类是一个在设计时的要害抽象）。

　　这里，我不是书生气。在我自己的工作中，我发现一个直接的相互关系在我OO方法的严格之间，快速代码开发和轻易的代码实现。无论什么时候我违反中心的OO原则，如实现隐藏，我结果重写那个代码（一般因为代码是不可调试的）。我没有时间重写代码，所以我遵循那些规则。我关心的完全实用?我对干净的原因没有爱好。