在匆忙之际理清消除实现继续和面向接口编程这样两个大题目可不是一件轻易的事情，尤其考虑到自身的熟悉水平。坦白的说，这又是一篇“炒冷饭”的文章，但这“冷饭”又确实不好炒。因此，在阅读了这篇文章之后，你可要批判地接受(拒尽)我的观点，尽管我的观点也是来自于别人的观点。

继续是面向对象中很重要的概念。假如考虑到Java语言特性，继续分为两种：接口继续和实现继续。这只是技术层面的题目，即便C++中不存在接口的概念，但它的虚基类实际上也相当于接口。对于OO的初学者来说，他们很希看自己的程序中出现大量的继续，由于这样看起来很OO。但滥用继续会带来很多题目，尽管有时候我们又不得不使用继续解决题目。

相比于接口继续，实现继续的题目要更多，它会带来更多的耦合题目。但接口继续也是有题目的，这是继续本身的题目。实现继续的很多题目出于其自身实现上，因此这里重点讨论实现继续的题目。

举个例子(这个例子实在太老套了)。我要实现一个Stack类，我想当然地选择Stack类继续于ArrayList类(你也可以以为我很想OO些或者出于本性的懒惰);现在又有了新的需求，需要实现一个线程安全的Stack，我又定义了一个ConcurrentStack类继续于Stack并覆盖了Stack中的部分代码。

由于Stack继续于ArrayList，Stack不得不对外暴露出ArrayList所有的public方法，即便其中的某些方法对它可能是不需要的;甚至更糟的是，可能其中的某些方法能改变Stack的状态，而Stack对这些改变并不知情，这就会造成Stack的逻辑错误。

假如我要在ArrayList中添加新的方法，这个方法就有可能在逻辑上破坏它的派生类Stack、

ConcurrentStack。因此在基类(父类)添加方法(修改代码)时，必须检查这些修改是否会对派生类产生影响;假如产生影响的话，就不得不对派生类做进一步的修改。假如类的继续体系不是一个人完成的，或者是修改别人的代码的情况下，很可能由于继续产生难以觉察的BUG。

题目还是有的。我们有时会见到这样的基类，它的一些方法只是抛出异常，这意味着假如派生类支持这个方法就重写它，否则就如父类一样抛出异常表明其不支持这个方法的调用。我们也能见到它的一个变种，父类的方法是抽象的，但不是所有的子类都支持这个方法，不支持的方法就以抛出异常的方式表明态度。这种做法是很不友好和很不安全的，它们只能在运行时被“侥幸捕捉”，而很多漏网的异常方法可能会在某一天忽然出现，让人不知所措。

引起上面题目的很重要的原因便是基类和派生类之间的耦合。往往只是对基类做了小小的改动，却不得不重构它们的所有的派生类，这就是臭名昭著的“脆弱的基类”题目。由于类之间的关系是存在的，因此耦合是不可避免的甚至是必要的。但在做OO设计时，当碰到如基类和派生类之间的强耦合关系，我们就要思量思量，是否一定需要继续呢?是否会有其他的更优雅的替换方案呢?假如一定要学究的话，你会在很多书中会看到这样的原则：假如两个类之间是IS-A关系，那么就使用继续;假如两个类之间是Has-A的关系，那么就使用委派。很多时候这条原则是适用的，但IS-A并不能做为使用继续的尽对理由。有时为了消除耦合带来的题目，使用委派等方法会更好地封装实现细节。继续有时会对外及向下暴露太多的信息，在GOF的设计模式中，有很多模式的目的就是为了消除继续。

关于何时采用继续，一个重要的原则是确定方法是否能够共享。比如DAO ，可以将通用的CRUD 方法定在一个抽象DAO

中，具体的DAO 都派生自这个抽象类。严格的说，抽象DAO 和派生的DAO 实现并不具有IS -A

关系，我们只是为了避免重复的方法定义和实现而作出了这一技术上的选择。可以说，使用接口还是抽象类的原则是，假如多个派生类的方法内容没有共同的地方，就用接口作为抽象;假如

多个派生类

的方法含有共同的地方，就用抽象类作为抽象。当这一原则不适用于接口继续，假如出现接口继续，就会相应地有实现继续(基类更多的是抽象类)。

现在说说面向接口编程。在众多的灵敏方法中，面向接口编程总是被大师们反复的夸大。面向接口编程，实际上是面向抽象编程，将抽象概念和具体实现相隔离。这一原则使得我们拥有了更高层次的抽象模型，在面对不断变更的需求时，只要抽象模型做的好，修改代码就要轻易的多。但面向接口编程不意味着非得一个接口对应一个类，过多的不必要的接口也可能带来更多的工作量和维护上的困难。

相比于继续，OO中多态的概念要更重要。一个接口可以对应多个实现类，对于声明为接口类型的方法参数、类的字段，它们要比实现类更易于扩展、稳定，这也是多态的优点。假如我以实现类作为方法参数定义了一个方法void

doSomething(ArrayList list)，但假如领导哪天觉得

ArrayList不如LinkedList更好用，我将不得不将方法重构为void doSomething(LinkedList

list)，相应地要在所有调用此方法的地方修改参数类型(很遗憾地，我连对象创建也是采用ArrayList list = new

ArrayList()方式，这将大大增加我的修改工作量)。假如领导又觉得用list存储数据不如set好的话，我将再一次重构方法，但这一次我变聪明了，我将方法定义为void

doSomething(Set set)，创建对象的方式改为Set set = new

HashSet()。但这样仍不够，假如领导又要求将set改回list怎么办?所以我应该将方法重构为void

doSomething(Collection collection)，

Collection的抽象程度最高，更易于替换具体的实现类。即便需要List或者Set固有的特性，我也可以做向下类型转换解决题目，尽管这样做并不安全。

面向接口编程最重要的价值在于隐躲实现，将抽象的实现细节封装起来而不对外开放，封装这对于Java EE

中的分层设计和框架设计尤其重要。但即便在编程时使用了接口，我们也需要将接口和实现对应起来，这就引出如何创建对象的题目。在创建型设计模式中，单例、工厂方法(模板方法)、抽象工厂等模式都是很好的解决办法。现在流行的控制反转(也叫依靠注进)模式是以声明的方式将抽象与实现连接起来，这既减少了单调的工厂类也更易于单元测试。

做个总结吧。尽管我竭力批驳继续的不好鼓吹接口的好，但这并不是尽对的。滥用继续、滥用接口都会带来题目。做Java

EE开发的很多朋友抱怨DAO、Service中一个接口一个类的实现方式，尽管它们似乎看起来已成为业界的最佳实践之一。也许排除掉接口会使程序更“瘦”一些，但“瘦”并一定就“好”，需要根据项目的具体情况而定。关于继续和接口的最佳实践，各位看官还是需要自身的经验积累和总结了。