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

看了这里的一些帖子和很多地方的帖子，很多人都在问为什么非要interface或者abstract class，然后还要在写一个实现类，而其实，我就市要做一个很简单的功能！？

对，如果你制作一个简单的功能，我同意你可以直接使用spring hibernate等框架来写，他们本身的好处也是干这个的。

但是，中国人有句老话，叫做杞人忧天，很多的时候，你有没有内心问自己，这个系统，我设计的，如果老板要改动，我可以在很短的时间内做到改变么？

当你问自己这个问题的时候，你就已经把直接写实现类的做法怀疑了。

面向接口的原则，不是只出现在程序员或者说IT界，接口设计是人类对一个问题或者一个物体的概括理解能力的表现。我们日常生活中处处有接口。

在我作一个简单的说明之前，我要补充以下，系统框架中，除了层的概念，还有一个叫做boundary,每一个layer（层）是由不同的boundary（box）组成。

举例一二三，比如，简单的说，发电厂就是实现类(implementation class)，每个发电厂都是独立的boundary，而发电厂就是统称为一个layer，也许还不明白，比如，我们平时说，发电厂，没人关心你家的电来自于那个发电厂，而关心的是你家的插座有没有电，所以三项插座，二项插座至十发电厂给用户的最终接口。发电厂之间也是通过一个特殊的工业接口来互相访问，所以，这也是为什么说，有时候有的发电厂在夏天负担过重，就可以把负担分给其他的电场供应。反过来，如果让老百姓天天关心的是发电厂，而不是插座，那你觉得这样的城市电力设计是不是很糟糕呢？

在举个例子，比如果.....，嗯，好，就说汽车，汽车都见过吧，四个轮子，一个方向盘，但是，你们有没有发现，有时候你们的汽车上面的音响系统坏掉或者要升级的时候，只需要取下中间面板上面的那个独立的音响播放器，然后买一个新的，由汽车维修给你们撞上就可以了，不管是飞利浦，boss还是简单的radio的和卡带的，你们从来不会在买一个汽车音响的时候关心他能不能安在汽车上，而是可以完全关心颜色，款式，品牌这些问题上，如果，反过来设计，每一个汽车品牌都直接实现自己的独立设计，不遵循工业接口，那你觉得这样的汽车音响会有很多选择么？

最后在举一个我们每天息息相关的例子，门，每天人们通过不同的门，进入或者走出不同的地方，而门就是那个地方或者建筑物的接口，如果说，我们反过来，每个大厦或者建筑物都直接应用自己喜欢的实现进出的方式，那你们觉得每天的生活会不会有点太麻烦？

我举例子只是来简单的解释一下，接口不是一个繁琐的过程，而是每个工业，甚至是每天生活中，我们必须应用到的东西，所以，如果看待现在的文明社会用程序员的方式的话，那么就是一种接口世界，现实生活中很多人叫做标准或者协议，由看得见摸得找的，也有看不见摸不着的接口。

很多人可能想对我举的例子进行进一步的反驳，其实没有必要，如果你要跟我探讨每一个例子来映射程序中的接口问题，那就是在抬杠，抬杠很浪费时间，所以，我不会跟你探讨例子的问题，那就是个例子，而这个例子是每天确实发生的，使用的。

希望能解释明白一点在程序设计中接口编程的优势所在。

接口编程的直接好处就是：实现多态……同一个接口，却可以调用不同的底层实现……

比如说：定义了一个Dao接口，但接口实现类却有多个（如采用JDBC或Hibernate实现）。调用的时候，只需使用同一个Dao接口类型的变量，就可以调用到不同底层实现的接口实现类（相当于屏蔽了底层实现，直接使用即可）。

接口是定义行为，抽象类是实现公共行为的，具体类是实现具体行为的

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

除非只写一个功能的类。否则都有写接口的必要。

除非是逻辑复杂的应用，否则都不需要搞一个接口什么的。
试问，现在80%的web应用中，有几个真的有非要接口不行的？

如同spring的依赖注入，学术价值远高于实用价值。

java本身是不错的，就是因为这些劳什子不实用的玩意，被搞的一团糟。

啊,原来作web应用是没有逻辑的.....那写软件干什么?

ls的ls，你做过web应用？你用过spring？

楼上的这位可能对Spring是个啥还没弄清楚就在这里胡邹了！所谓的逻辑何来复杂？何来简单？我看是你从根本上没有一个对于设计以及java编程的深刻认识，才会发表这样的言论。只要是严格按照设计的思路按照面向对象的概念来写东西，不用想一定是按照接口编程的思想来实现。
顺便再踩一脚，假如你所经历的应用都按照你的思路开发的话，两个字：垃圾！

从概念的角度，"接口其实更多的用于抽象和规约"，这句话十分正确。
从实现的角度，java的interface重点在于辅助静态实体的建模，即楼主说的汽车、发电厂，用"接口"去描述它抽象的组成部分和行为协作。
然而，如果用它“变相”的去做执行流程的建模，就太笨了。这时，应该在函数签名上做文章，请参考C#是怎么做的。
如果用实体建模的优势去掩盖流程建模的劣势，不是掩耳盗铃吗？对于web开发，那些DAO只写一个实现类，又为什么要用接口呢？除了前面的理由，跟底层的支持不足也有关。

"复杂逻辑"和"没有逻辑"是不一样的，看来某些人自己就不讲逻辑。