有人问Java之父Jams Gosling：“如果你重新构造Java，你想改变什么？”。“我想抛弃class”他回答。笑声平息后，他解释“真正的问题不是由于class本身，而是继承关系(extends)，更好的选择是接口关系(implements)。”

   现在，越来越多的人在振臂疾呼extends的缺点，在《Java设计模式》一书中详细阐述了怎样用接口继承代替实现继承。那么这是为什么呢？面向对象编程的几个特征之一就是继承，时至如今，设计者们为什么又像躲避瘟疫一样躲蔽extends呢？归根结底还是一个[耦合]问题。继承使得子类紧密依赖于父类，继而整个结构失去了灵活性、父类无法自由修改。

   耦合就是程序的一部分对于另一部分的依赖。虽 然我们不可能消除耦合，但是要尽最大可能降低耦合。没有哪个程序是不包含依赖关系的，即便在IoC中，也同样存在依赖，只不过是依赖转移到配置中而已。然 而一个优秀的程序的耦合度往往是远远低于一个糟糕的程序的。这个道理谁都明白，但在实际应用中，往往我们被迫于日程压力，而不再关心是否松耦合，更多的关 注业务。但最终的结果往往是恰恰相反，我们越是牺牲程序结构来赶进度，越是出现日程滞后。

   继 承使结构失去灵活性，使用具体类名将你固定到特定的实现，给底层的改变增加了不必要的困难。在敏捷开发中，核心是并行的设计和开发的概念。在详细设计程序 前，我们就着手开始编程。这不同于传统开发形式（设计完成后才开始编码）。并行开发的核心是主张灵活性，我们必须以某种方式来保证程序结构的灵活性，以满 足不断变更的需求。在这种形势下，使用接口的优势很明显，而采用继承的弊端也很明显。

   在继承体系中，修改基类将是一件非常棘手的事情，因为派生类是紧密依赖于基类的，基类的任何改动都用可能让派生类功能丧失或错乱。我们无法通过简单的方式来判断基类的变化是否安全，也就不得不重新测试所有派生类。而且，在修改基类的时候，我们必须意识到任何一个对于基础类的简单变化都可能导致整个程序不可操作。