对于接口越来越迷茫

关于接口的时候，我一般是分为两层来对待：架构层 和 应用层。

架构层：
接口用得很广泛，理论上，一个成熟架构暴露给应用层使用的，都是接口，比如：2001年，你使用如下代码实现发送短信：

com.chinaunicom.sms.SmsSender sender = SenderFactory.getDefaultSender();
Result result = sender.send("13999999999","Just a test.");

上面代码中，com.chinaunicom.sms.SmsSender是一个接口，在2001年，它的实现类是：GeorgeSmsSenderImpl

到了2012年，com.chinaunicom.sms.SmsSender接口的实现类已经变了三次，现在的实现类是：
AndySmsSenderImpl，但是对于应用层的使用者而言，他们发送短信仍然使用：

com.chinaunicom.sms.SmsSender sender = SenderFactory.getDefaultSender();
Result result = sender.send("13999999999","Just a test.");

应用层使用者的代码完全不用变，这就是接口的好处。

所以，在价构成，要尽量使用接口，理论上，架构层暴露给应用层使用的，应该全是接口。

应用层：
在应用层，接口能不用就不用，代码越简单越好，像楼主举例说的Service、Dao，完全没有必要定义接口，除非你每个Service都有不同的实现类，如果一个Service就是完成一种特定的业务，在可预见的未来也不会有其他实现方式，那样的话，如果你非得给每个Service定义一个接口，只是在自找麻烦。

在我的系统中，每个Service只继承一个通用的基础父类，不用实现任何接口；
对于DAO，则使用如下方式使用DAO来完成数据库访问：

HelloWorld bean = dao.getOne(HelloWorld.class,SqlParam.add("id",100));

至于dao这个变量是怎么来的，应用层使用者完全不用关心，只管放心在Service类或者控制器中，甚至在jsp中使用这个变量即可，更不用费劲地去定义什么Dao接口，写什么Dao实现类。

所以，在应用层，使用者写得代码越少越好，代码越简单越好，接口能不用就不用。

有些事情就像看A，看的人很爽、做的人却未必。

新项目要采用S2SH,结合上次的经验，我感觉不出接口给我带来多大的好处

摘一段：

对于接口的作用，在一些小的项目上，很难看出其发挥的优势。这就使一些经常的做小项目的开发人员，做时间久了就感觉不到它有什么好的，有时候写起来还麻烦，干脆不用了。其实，在一些大项目上，接口的作用是发挥地相当的明显的。

比如：如果你开发业务逻辑代码，当你好不容易的实现了它全部的功能，突然用户需求要改，你在修改你代码的同时，调用你代码的其它人也会改，如果代码关联性强的话，会有很多人都要改动代码，这样一来二去，程序会变得相当的不稳定，而且可能还会出现更多的新Bug,所有人都可能会陷入混乱。
但如果使用接口的话，在你使用它之前，就要想好它要实现的全部功能（接口实际上就是将功能的封装）。确定下这个接口后，如果用户需求变了，你只要重新写它的实现类，而其它人只会调用你的接口，他不管你是怎么实现的，它只需要接口提供的功能。这样，很可能只需要把你的代码修改就可以了，其他人什么都不用做。
同时：这样做的话，使得开发人员能够分工明确，只要确定下来接口了，就可以同时进行开发，提高开发效率。
另外，使用接口还有使用方便，可读性强，结构清晰等优点。


要说项目小也不算小，除了最后的同时我真的没觉得有什么好处，有时候说需求改变只改实现就可以，但是如果没有接口也可以直接改里面的代码来实现，只要调用方法不变即可。

还请高人能用简易的例子说说实际中接口的好处
拜谢

有些事情就像看A，看的人很爽、做的人却未必。