什么是接口编程

面向接口编程(很经典..转载的)

2008-07-17 20:50

在匆忙之际理清消除实现继承和面向接口编程这样两个大问题可不是一件容易的事情，尤其考虑到自身的认识水平。坦白的说，这又是一篇“炒冷饭”的文章，但这“冷饭”又确实不好炒。 因此，在阅读了这篇文章之后，你可要批判地接受(拒绝)我的观点，尽管我的观点也是来自于别人的观点。 继承是面向对象中很重要的概念。如果考虑到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中一个接口一个类的实现方式，尽管它们似乎看起来已成为业界的最佳实践之一。也许排除掉接口会使程序更“瘦”一些，但“瘦”并一定就“好”，需要根据项目的具体情况而定。关于继承和接口的最佳实践，各位看官还是需要自身的经验积累和总结了。     一马平川 19:58:54 接口是对类的抽象 一马平川 20:00:47 我如果直接跟你说接口编程，你一定不理解，或者说很难理解，因为接口本身是很抽象的东西，现在我举例跟你说 一马平川 20:01:38 电源插座就是接口 一马平川 20:01:45 比方说 一马平川 20:02:01 插座有两孔的 一马平川 20:02:04 有三孔的 一马平川 20:02:18 不同的插头需要不同的插座 一马平川 20:02:36 接口就描述了能适应的插头范围 一马平川 20:03:04 现在有一种插座是三孔的，但既可以插三孔的，也可插两孔的，知道么？ 一马平川 20:03:43 那么，我们可以说，这个插座设计的好 一马平川 20:03:57 因为他能适用更广的范围 浮尘 20:05:10 嗯。   一马平川 20:04:20 ，当然，这个范围不能超出电源插座这个概念 一马平川 20:04:55 如果是用来插笔，做笔筒用，那也不适合 一马平川 20:05:45 如果电源插座不但能适用两孔和三孔的插头，还能适用笔的话，那么我们可以肯定的说，这个接口设计的太差了   一马平川 20:06:41 因为接口（插座）的设计应该是对某一类事物的抽象   一马平川 20:07:39 而且，接口（插座）实现以后，实现该接口的类（插头）必须符合接口的定义（插座和插口匹配）， 一马平川 20:07:52 而且需要完全符合 一马平川 20:08:02 一点不符合都不行 一马平川 20:08:19 所以实现某个接口的类，必须从写接口中定义的所有方法 一马平川 20:09:08 如果你觉得该方法不需要实现，你可以留空 一马平川 20:09:13 但必须重写 一马平川 20:09:53 接口只定义了方法的原型，即参数和方法名以及返回值，集成接口的类需要实现它 一马平川 20:10:51 看我这句话： 一马平川 20:08:18 而且，接口（插座）实现以后，实现该接口的类（插头）必须符合接口的定义（插座和插口匹配）， 一马平川 20:11:55 其实，你会发现插座生产出来后，如果某电器的插头和插座不匹配，那么就无法使用该电器了 一马平川 20:16:28 实际上，你在设计一个接口的时候，很难想到要怎么去设计，尽管你知道集成这个接口的类是怎么样的 一马平川 20:17:27 就像如果你开一个工厂生产插线板，你在不知道电器，或不完全知道电器的插头如何设计的时候，你是很难生产出能用的插线板的 一马平川 20:18:03 那么，如何设计插线板呢？或者说如何设计接口呢？ 一马平川 20:18:39 先看看插线板厂商是如何生产的吧 一马平川 20:19:50 某天，有人生产一个电器是4个孔的，那就用不了了 一马平川 20:21:12 这时候，插线板厂商为了生产出一种插线板，能适用于目前的大部分电器，也能适用于将来的电器，他找到了一个机构 一马平川 20:21:43 机构是专门指定规则的，专门制定协议的 一马平川 20:22:28 机构叫来了大部分的重要电器厂商的头头，和插线板老板一起开了个会 一马平川 20:22:44 大家为了共同的利益，决定了一份协议 一马平川 20:24:15 协议是这样的：电器厂商以后生产的电器的插头，只能生产三孔的，但为了兼容目前市场上已有的电器，也能生产两孔的，但是尽量生产三孔的。而且孔的大小和之间的距离有明确的规定 一马平川 20:25:00 插线板厂商的插线板也只能有两孔的和三孔的，而且孔的大小和之间的距离也必须按照协议来生产 一马平川 20:25:10 于是问题解决了， 一马平川 20:25:53 而且插线板厂商老板很聪明，他发现可以生产出既可以插两孔，又可以插三孔的插口，于是他的插线板大卖，他发财了 一马平川 20:26:47 优秀的接口设计，给他带来了大大的好处，但他很聪明，他没忘记如果没有规范协议的机构，一切都是空白 一马平川 20:30:00 再补充几句吧，不然你还是难以理解 一马平川 20:31:32 当你想设计一个接口的时候，你最好先写几个将要继承这个几口的类，写几个只有框架而无实际内容的类，看看他们之间的共性，找到写接口的点，这就正如找电器老板来开会 一马平川 20:32:56 写接口的时候，你需要在之前对接口进行说明，说明接口的适用范围，以及继承该接口的注意事项，这就好比请机构来制定协议规范 一马平川 20:34:12 有了这些以后，你的接口在被使用的时候就不会错用，在写继承该接口的类的时候，也会按照规范完全的匹配接口。 一马平川 20:36:07 最后一句话，即使你理解了我今晚所讲的每一句话，你还是不会写接口，因为你需要实践，实践才会出真知。最后这句话才是至理名言，我说的基本都是空话（在你学会了写接口后）。   第一次写接口时，第一个感觉就是，写接口跟没写一样。定义一个接口，马上去写实现类！其实此时就是用着面向过程的思路写程序，然后挂了个羊头，说起来怎么也有个接口了！ 今天看了一位老兄写的对于接口的心得体会，真是太有同感了！ 不要为了接口而接口，当你把自己不当做是个程序员来思考时，就能把用人的思想来思考了，你不会写程序，就不会考虑细节的实现了！此时你所关注的问题就是比较抽象的了，你看这不正符合面向对象的原则吗？当年张三丰教张无忌打太极就是要把招式全忘了，你要定义接口前就先忘了自己是个程序员吧！   当然不可能有100%的抽象，最终你还是要回到实现细节上来的，可此时你已是学会了太极的张无忌了！