对于接口越来越迷茫

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

架构层：
接口用得很广泛，理论上，一个成熟架构暴露给应用层使用的，都是接口，比如：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实现类。

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