再次讨论一下项目中是否该使用接口

Question

小弟4年半的java开发经验，以前做项目时，基本上也都用spring，众所周知，做spring的项目都是要写Dao,Service,DaoImpl,ServiceImpl的，打的旗号也一直说是好扩展。不过以我的经验而言，感觉实在没必要这样写，直接写实现类就可以了。现在公司有个小项目，我带着2个同事开发，我想在这个项目中就不面向接口了，不过同事中有人不同意，说将来没法扩展了，想来听听大家的意见。
我的看法是，如果我们要去爬珠峰，那么我们肯定要准备一套装备；如果我们只是要去爬香山，穿着拖鞋、短裤就够了。

Answer 1

有同事问我，人家spring、hibernate什么的都用接口，你凭什么不用接口。我的看法是，那些框架是做给程序员用的，每个程序员的需求都不一样可能会有不同的实现，而我们的项目就是做给终端用户的，是纯粹的业务系统，不可能一个接口会有多个不同的实现

Answer 2

回想一下自己的开发生涯，遇见过从asp+sqlserver转向java+oracle的，遇见过整个项目全部推翻，从头开发的，就是没遇见过替换daoImpl和serviceImpl就完事的项目

Answer 3

这个就好像在说不用Eclipse,用记事本也能写程序...这种讨论没有必要了吧,为什么用接口,为什么要把声明和实现分离,为什么框架要给你设计出Repository,Service,Controller层,为什么会有Ioc和AOP这种东西...
你说你做了4年半的开发了,如果这样还在问这些外行问题的话,只能说你只是一个简单的体力工作者,做了这么多年开发了也应思考下到底什么才是开发工作了....而不是永远做一个打字员...

Answer 4

更加偏向框架一类的代码，应该用接口。偏向具体业务的代码，建议不要千篇一律，总结出一定规律，再抽象也没问题。话说JDK1中，只有java.util.Vector，而且还没有java.util.List。到了JDK1.2才有的Java Collection Framework，有了java.util.List/ArrayList/LinkedList，Vector这时候才实现的List接口。

Answer 5

接口为什么要用？为什么不用？有木有人考虑过？用了好处在什么地方？不用的原因是什么？看到有人说：别人用了你为什么不用，那我想反问，别人用了我凭什么就要用？我和LZ工作年限差不多，目前觉得，在Web应用里，为了接口而接口，为了抽象而抽象实在没什么太大意义分的都是3层或者4层，使用的技术框架也趋于稳定，又都是页面->Action->Service->DAO一条线下来的一次响应在业务熟悉的情况下，用或者不用确实感觉不出什么差别来。

Answer 6

是的，做WEB开发一直做下来，确实能体会到抽象的好处的项目不会太多

Answer 7

你觉得有用就用
非觉得没用那就不用...很简单的一个例子,你们肯定也天天用到的
Iterator接口
自己想想看为什么遍历集合体都实现这个接口
如果没有Iterator接口的情况
可能hashMap有个iteratorMap函数
可能arrayList有个findInArray函数
可能linkedList有个each函数
可能你接触的每个集合体的遍历函数都是不一样的,难道这样你还认为无所谓吗?不再回复了....实在感觉讨论这个东西没啥意义

Answer 8

总算有人说到本质了抽象方法抽象的是同一类行为的不同做法。 这样对于使用方来说，他只要知道有人给我做了一件什么事就可以了但是，具体怎么做的，不需要关心。再回到楼主的问题，同一类行为的不同做法需要抽象方法，而大多数情况下，我们写的Service和DAO需要一类行为提供多种不同实现方式的吗？显然很少需要。

Answer 9

不同人就这个问题会有不同的考虑，总体来看。是有必要使用接口的。编写软件时候，不能仅仅考虑当时编程的便利性，更多要考虑程序以后的发展。我们都在讲软件的扩展性，那么为什么软件有必要有扩展性？那是因为，使用我们软件的客户总是会提出新的要求。这对软件来说，就需要不断开发新的功能。如果你软件的系统结构不够良好，扩展就会变得困难，修改或增加代码时，容易引起其他相关代码的异常。这种现象太常见了。软件本身很难达到所谓的开闭原则，即对扩展开放，对修改关闭。并不是说接口就能保证系统的扩展性，只是因素之一。接口主要是描述行为的，一旦我们想要改变原先设计的行为（如实现的业务规则），那么如果面向接口，则很容易实现开闭原则，从而对于其他相关的模块不会产生影响。因此，无论是从软件的扩展性，还是从质量保证方面来说，都是建议面向接口编程的。
记得Spring的教程里面有个很形象的例子，笔记本有USB接口，我们copy数据通过此接口出去，至于copy到什么地方，是取决于连接到此USB的设备，可能是U盘，也可能是移动硬盘。在此不再深入叙述了。

Answer 10

这样的小项目我也做过，dao\service只留实现类是会更好维护、更清晰、工作量更小。当然只要能保证该系统在下一次大的升级前都在既定框架内微调，运行良好，就可以说明系统的扩展性设计是OK的了。扩展与调整是影响工作量的，要表述好现在及将来的工作量总和是最低的，他们应该是可以接受的，谁那么傻总想写多点类和代码呢？接口设计也是设计模式中的一部分，虽然优美，但做一些用不到得的预留设计仍然会显得很Stupid，毕竟有时候人对于美的追求都是自发的。呵呵···
你对于已遇到的开发和维护的困难，用实现类去代替接口设计算是利用了反模式的理念，是不错的实践诶。

Answer 11

接口可以提高代码的重用性？第一次听说.........面向对象大师Grady  也曾经说过:"我从不认为面向对象的目的是为了复用.........."
感兴趣的同学可以去搜搜大师完整的原话。抽象的目的是变与不变的分离，不在乎项目的大小不变的部分依赖变化的部分（或者易变的部分）时必然要进行抽象，也就是所说的，对抽象依赖，而不对具体实现类依赖。所以，个人观点是，需要灵活运用。上来就所有DAO和Service都写个接口然后去实现的方式，个人不赞同。

Answer 12

接口是为了以后的扩展？好吧，这种说法有一定的理论依据但是，实际上，我们一个项目上线之后，在对项目进行调整的时候，扩展的情况有多少？10%？20%？80？从我工作这些年来看，一次都没有。项目有大小，小的大概7-8个人做3-4个月的小型项目，也就几百万的大的项目30+人做一年，在四千万左右。我遇到的最大的问题是，需求调研不清楚或者说，用户根本不知道自己的业务是怎么样的流转方式，甚至数据流向都不知道。扩展？我还真没有遇到过。好吧，从扩展的角度讲，确实，接口需要，因为这样做有机会利用代理或者装饰模式，从而实现所谓的对修改关闭，对扩展开放。对此，我不反对，但是，我反对所有的DAO和Service都要去实现接口，这就涉及到业务分析人员和业务设计人员的工作责任心问题了。你是做分析设计的，那么你一定会知道在什么地方易变，考虑以后的所谓扩展，其他地方根本不会变，比如一个findById方法你需要写接口吗？这些东西都写了接口，如果是下面的代码人员在详细设计时做的，只能说，拘泥不化，不知变通，为了用接口而用接口。如果是分析人员给出的，那就是分析人员偷懒图省事，根本没去分析业务，没做深入的业务调查和交流。所以，我目前在工作里的工作方法是业务分析文档到了我这里，我只给出分析类，就不再做了，然后给出列表，列出需求讨论时已经发现的业务实现方式容易发生变化的地方。剩下的其他人去设计了。我做的只是阐述业务实现方式，以及个别地方的代码走读。做设计评审的时候，根据我的列表，以及我们组人员对需求的理解，评判下设计是否可行是否有更优的余地，也就完了。如果有项目经理给我的文档里，所有DAO都有接口，我会取消评审，让他们继续去修改。

Answer 13

楼上说的有一定道理。
不过我确实感到了接口带来的压力，
1、事实上，每次我都是先写实现，然后再去定义接口的，所以感到是为了接口而接口
2、有时想看代码时，随手一点，经常会跳到接口中，感到很恼火，愈发感觉接口的多余就事论事的说，针对你说的“协同工作的时候，你可以先定义接口，其他人员就可以继续工作了，而不需要你非要完成所有实”这个问题，同事也提过，不过我想如果你事先想清楚要实现哪些方法，你也可以在实现类中定义出来，返回Null也是一样，不会影响别人的工作