基于接口编程VS基于实现编程

fhjxp同学在看完我的Struts2.0+Spring+Hibernate的在线音乐系统的代码时：
fhjxp 写道

引用

看了一下源码，问一下，dao，service定义每个都定一个接口有什么用啊？有什么好处？

基于接口而不是类编程，这样Service层依赖于dao层的接口而不是实现，可以方便的替换dao的实现。基于接口 编程提供了可插拔的松耦合的编程方式。Spring倡导基于接口编程的方式，这是一种良好的编程习惯，在Spring中使 用接口是自然的，被鼓励的。
fhjxp 写道：

引用

你的回答里面我只看到一个理由：方便替换实现。为什么要松耦合、面向接口、好习惯还是为了这个。
真的方便了么？
1,首先说90%以上的项目，都不存在另外作多套Dao，Service需要进行切换，我接触过到的项目（开发时间近三年）都没有遇到过这个情况，偏偏每个项目都要搞了接口，不管开发还是维护都没有得到什么好处。

2,如果某个service方法要修改具体实现，不管有接口还是没有接口都需要同样的修改代码。如果还需要修改方法的名称或参数，同时还得修改接口类，得改两处，反而麻烦了。

1、我曾经参加过一个项目，原来使用Hibernate,从这个项目派生出一个项目要用JPA,有了DAO接口就可以方便替换了，否则，你在每个Service中找使用的HibernateDAO,然后改成现在的JPA实现的DAO，这是一个烦琐而易出错的事情，这就是依赖于具体实现的害处。
　　接口作为一种契约，其他使用你代码的人只需要知道你接口中提供的方法，就可以使用你的代码了，而接口通常是方法的最小子集（要暴露给用户使用的部分）。如果你只有实现类，往往会让使用你代码的人陷于细节，自己查找你到底暴露那些方法给我用。维护方面，如果你的实现需要很大改动的时候，有了接口别人在修改你代码的时候，就会知道我只要实现了你定义的接口的功能就ok了，其他的细节和我无关。
２、你所说的得改两处，是因为接口没有定义好，改动两处当然是不可避免的。如果你没有接口，别人要修改的话，他都不知道他的改动对其他部分的影响有多大，因为他很可能不知道，你要暴露什么，其他部分依赖于哪些方法。
３、基于实现类违反了面向对象的设计原则：OCP、LSP、DIP
在ThisWorld的帖子中：
ThisWorld写道：

引用

就为了OO倡导的接口跟实现分离就用IoC？不稳定的接口怎么解决？为什么不等到重构的时候再用？

接口基本上应该是稳定的，当然随着对需求的进一步理解，可能开始抽象的不够，引起接口的变动。不过这种情况下，一般只是在接口中添加内容，对其他部分影响不大。如果是在需要合并接口或其他的方式引起的接口变动，这样可能影响的范围会很大，所以开始就应该仔细设计接口。
但如果不使用IoC,接口和实现分离也是应该倡导的一个好的编程方式，如果你开始所有的都是基于类编程的，等你对需求了解深入了，项目完成大半了，再试图重构出接口，困难会非常大（本来能重构的一个等级的，而这些方法的命名因为不一致而使重构变得困难甚至不可能），除非你在设计每个类的时候就考虑，将来要和某某类抽象出接口（如果你是遇到能抽象出接口的几个类就重构出接口，那么将和开始就使用接口类似，产生不稳定的接口，甚至更糟，你看的可能太局部了，而开始就仔细设计接口，许多时候会设计出高质量的接口）。
其实接口作为一种协议、规范，大家在写代码的时候就会遵循这个规范去写实现类，如果开始没有了这个规范，就会乱做一团。
所以我感觉关键是在开始就要仔细的设计接口。

评论

1 楼 yongtree 2008-03-27  

嗯，基于接口编程的确很重要。但是紧紧是基于接口还是不行，编码依然很硬。spring这样的框架的确给了我们启示，将接口和反射结合起来实现IoC。