接口的作用
对于系统架构来说,应该是:没有啥可以去掉的了,这时最精简.
如果是没有啥可以加的了,那就太臃肿了.
接口这东西纯粹是学术上存在的,硬塞给实际工作人员,实际上接口应该只存在在文档里面,而不应该存在在代码之中.
有接口这种代码层面的工具不用，偏用人肉去保证这些接口，不累么？接口错了有编译错误提示，文档错了？有人肉提示？如果代码能让人清楚，很多时候就不用写文档；
接口绝不是哪门子“学术上存在的”，相反，是一种工程上的、很具有现实意义的工具——方便编码的人，没人规定接口要怎么怎么用，只要你想得出它的用处，那就能那样用；
如果几个人并行开发同一块儿功能，先把接口给画出来，交流好谁谁谁负责哪几个方法，然后各自整；别人还没有实现的，你添点假代码继续整；到后来别人更新了替换掉假代码就是了；
还有什么用，那估计就是老生常谈了，什么测试、mocking、解耦、设计模式、自顶向下等等等；
还是那句话，你能想到怎么用，那就可以怎么用；也许项目做完了&&不用你维护你会怀疑接口没啥用，但过程中是很有用的。
但是楼主说如果一个类实现的功能变了，要重新写一个类实现用接口会比较方便，就我认为这样子没有太大的方便，我也可以不用改原来的类，我直接重写一个类，跟原来的类一样的，不就可以达到与接口相同的意思了吗？
这位大大的意思是不是连servlet容器的代码也要跟着改？
因为在有servlet接口的时候，不管servlet的实现是谁写的，我servlet容器起码知道它一定是个Servlet，但你不用这个 Servlet接口的话，那我就只能知道他是个object了，如果它还是段java代码的话。object的话，getServletConfig方法 哪里来？它有没有这个方法？
要是再犟一点也行，我偏不用接口，反正只要它是java，那就有一个公共的“接口”：java.lang.Object；有没有getServletConfig方法我偏这么判断：
Object.getMethods() 看里面有没有getServletConfig方法；
if 有
调用
else
报错
那也行，人肉啊人肉，如果能...我就不多说了
其实楼主说得挺好的，本来DI跟接口或抽象类这种泛化过的东西结合起来才能有作用，不是那么流行spring么？？如果就一个具体的类，你注入进 去跟直接new一个有什么区别？当然如果说我还是犟得很，偏要用具体类的引用来进行注入，以后要改实现的时候直接extends这个类就是了——那也可以 （这个类跟个接口有什么区别？接口本是概念上的东西，语言层面提供了个方便的工具，然后你不用...）
还记得有一次面试面试官问我spring是什么，我说就是通过一堆接口来管理类，实现松耦合。然后问我接口有什么用，我，，，一脸茫然。。。然后想了想说，因为要用spring，所以要用接口，然后他继续追问我为什么要用spring,我说大家都在用，我不用就落伍了。哈哈。
========以上来自Javaeye论坛 http://www.iteye.com/post/957921?page=2================
其实框架这种东西本来就是可用可不用的，不用框架可以说照样能实现同样的功能，只不过框架提供了一些好的实现，封装了一些好的方法，可以直接调用，让我们更加注重业务逻辑，而不用每个人都去做技术总监，每个人都去写底层，谁来写业务，而底层往往是可以重用的，软件的核心还是靠业务层，因为业务层基本上可重用性很少，需求决定了业务的不同。也许从个人职业规划角度讲我们应该追求技术，追求一些更深层的东西，但是从公司业务上来讲，更注重的是不是应该是结果？而不是实现结果的细节？试问如果没有需求，没有业务的存在，技术再牛由有什么用？发现电的人固然伟大，但如果没有人结合实际发明很多应用，就没什么鸟不起的了。
再说了，对于一个刚从学校出来的人，成天研究这些深层的技术好处固然有，但我还不如多学一些应用，至少我不只是纸上谈兵，能够达到BOSS想要的结果，这也正是现在BOSS为什么这么重视我的原因，因为我能帮他实现他想要的，他并不关心我采用了什么技术，他要的，只是结果。
我觉得技术这种东西非一日之功，只有在应用中去理解，去积累才有意思，一下子就想成为什么什么牛人，也许这种牛人确实存在，但缺乏实际的项目经验，光会纸上谈兵，有什么用？
===========================回到正题，接口的作用===================
如果再让我来回答：
1.接口是对行为的抽象，可以定义多个类分别实现不同的行为。
2.多人同时开发时，可以让团队成员的开发独立最后通过统一调用接口而提高协同效率。
3.在设计的时候，接口可以让我们思路清晰，而且可以加上注释让人更容易理解，而不用关心具体实现的类【如果有N个类就麻烦了】。