在匆忙之际理清消除实现继承和面向接口编程这样两个大问题可不是一件容易的事情尤其考虑到自身的认识水平坦白的说这又是一篇炒冷饭的文章但这冷饭又确实不好炒因此在阅读了这篇文章之后你可要批判地接受（拒绝）我的观点尽管我的观点也是来自于别人的观点
继承是面向对象中很重要的概念如果考虑到Java语言特性继承分为两种接口继承和实现继承这只是技术层面的问题即便C++中不存在接口的概念但它的虚基类实际上也相当于接口对于OO的初学者来说他们很希望自己的程序中出现大量的继承因为这样看起来很OO但滥用继承会带来很多问题尽管有时候我们又不得不使用继承解决问题
相比于接口继承实现继承的问题要更多它会带来更多的耦合问题但接口继承也是有问题的这是继承本身的问题实现继承的很多问题出于其自身实现上因此这里重点讨论实现继承的问题
举个例子（这个例子实在太老套了）我要实现一个Stack类我想当然地选择Stack类继承于ArrayList类（你也可以认为我很想OO些或者出于本性的懒惰）现在又有了新的需求需要实现一个线程安全的Stack我又定义了一个ConcurrentStack类继承于Stack并覆盖了Stack中的部分代码
因为Stack继承于ArrayListStack不得不对外暴露出ArrayList所有的public方法即便其中的某些方法对它可能是不需要的甚至更糟的是可能其中的某些方法能改变Stack的状态而Stack对这些改变并不知情这就会造成Stack的逻辑错误
如果我要在ArrayList中添加新的方法这个方法就有可能在逻辑上破坏它的派生类Stack ConcurrentStack因此在基类（父类）添加方法（修改代码）时必须检查这些修改是否会对派生类产生影响如果产生影响的话就不得不对派生类做进一步的修改如果类的继承体系不是一个人完成的或者是修改别人的代码的情况下很可能因为继承产生难以觉察的BUG
问题还是有的我们有时会见到这样的基类它的一些方法只是抛出异常这意味着如果派生类支持这个方法就重写它否则就如父类一样抛出异常表明其不支持这个方法的调用我们也能见到它的一个变种父类的方法是抽象的但不是所有的子类都支持这个方法不支持的方法就以抛出异常的方式表明立场这种做法是很不友好和很不安全的它们只能在运行时被侥幸捕捉而很多漏网的异常方法可能会在某一天突然出现让人不知所措
引起上面问题的很重要的原因便是基类和派生类之间的耦合往往只是对基类做了小小的改动却不得不重构它们的所有的派生类这就是臭名昭着的脆弱的基类问题由于类之间的关系是存在的因此耦合是不可避免的甚至是必要的但在做OO设计时当遇到如基类和派生类之间的强耦合关系我们就要思量思量是否一定需要继承呢？是否会有其他的更优雅的替代方案呢？如果一定要学究的话你会在很多书中会看到这样的原则如果两个类之间是ISA关系那么就使用继承如果两个类之间是HasA的关系那么就使用委派很多时候这条原则是适用的但ISA并不能做为使用继承的绝对理由有时为了消除耦合带来的问题使用委派等方法会更好地封装实现细节继承有时会对外及向下暴露太多的信息在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开发的很多朋友抱怨DAOService中一个接口一个类的实现方式尽管它们似乎看起来已成为业界的最佳实践之一也许排除掉接口会使程序更瘦一些但瘦并一定就好需要根据项目的具体情况而定关于继承和接口的最佳实践各位看官还是需要自身的经验积累和总结了
