解释一下，为什么需要接口而不直接实现类。

嘿嘿，各位息怒。

我搞java开发的时候，你们还不知道在哪里呢？

业务逻辑的复杂是一回事儿，技术实现的复杂是另外一回事儿。
如果业务本来就足够复杂了，再加上复杂的技术实现，等于复杂*复杂，会做的更好？

再说了，一个接口会包含多个实现么？我想大部分时候一个接口都只有一个实现类吧？
复杂业务逻辑就必须搞个接口，证明自己？

为什么你们听到我的话会跳起来？
从心理上说，你们实在无法接受把复杂问题简单化处理，这样做技术太没面子了！都不好意思跟人打招呼，只是你们的思维惯势。
从技术上说，你们也就搞过java，技术的积淀浅薄。就连spring的这些好处，也都是别人吹给你听的！你们根本就不能真正明白spring为什么这么做，利弊都在哪里。你们跳不出java的圈子，所以根本就不能真正理解java。

知道么？
心理素质差+技术水平次，就是你们做出如此反应的根本原因。

实在抱歉啊！

赞同liusong1111！！
接口其实更多的用于抽象和规约，作为一种协议或是约定是很有用的。

在其它时候用接口大部分是在浪费代码。。
DAO只写一个实现类，又为什么要用接口呢？这话说得很对！！

很多时候定义接口的跟写实现类的并非同一人....

和项目大小有关，如果小项目就得不偿失了

呵呵，用资历来砸人可不是明智的做法。

其实在很多时候，我们总是在为一些未来可能根本不存在的需求而买单，很多人在谈论一些设计问题上的时候总是在说什么为了未来的扩展性、可维护性什么的，把系统搞得是超级复杂，一个简单的功能实现得庞大无比，然而事实上，我们的系统真会有这样的需求么？未雨绸缪？但也不可太过吧？

有时候回想一下，很多一些以前考虑的事情，实际上根本从来就没有发生过，但就是因为这些从未发生过的需求，让我们浪费了不知道多少时间，我们是否应该在未来可能性的需求以及当前开发成本两者之间做一个正确的选择？

接口其实更多的用于抽象和规约
比如协同工作期间，订立接口有助于双方相互间调用的规范。
同时也有助于自顶向下的思考。
在内部实现中，接口实现多态也有不少用处，不过也不是每一个地方都要用。
实现好了，需要的时候简单重构一下，就能获得接口的相关特性。

只有通过统一建模，明确地分析和抽象，细致的研讨之后的接口（比如java source中那些接口，我估计没一个定义个接口中的没一个方法都是大家在讨论中反复研讨才得出的结论），接口才能发挥出威力，否则自己随着需要随手写的接口可能用处不明显。

一切从实际出发.
不过对于大项目,面向接口编程的好处显而易见.

你不针对接口一样可以达到代码复用，逻辑层代码一样可以不改，我只要重写那些需要重写的类保留原有的类名和包名然后替换一下就行了。


这说得和没说一样，好处在哪里呢？能分享一下么？

如果开发类库使用接口偏重于接口的多态性，
但web开发中我看80%的接口的确也都没什么用，因为一切除了代码以外软件资源都在需求和设计文档里定死了，你很少要切换什么实现甚至没有切换实现，哪怕有直接把原来的干掉重写。
我看接口确实也就是个约定, 约定在文档中，约定在Team之间，约定在搭档之间，以至于双方实现的东西能直接拿来用。

在我的开发经历里 接口多数用的都很多余
一个接口一个实现类 何苦 吃饱了