很多DAO组件都设计了一堆接口，但是感觉完全没有作用，这到底是不是过度设计？
最近看了不少java ee项目，很多用ssh的项目，在DAO部分都是这么弄的，针对一张表，首先定义一个实体映射类（比如useinfo），然后定义一个操作接口类(比如IUseinfoDAO)，然后用一个类继承这个接口（UseInfoDAO），最后，在实际应用中，他们在需要用到操作类的地方都是先定义一个接口对象，然后从上下文或者spring自动注入的方式，把实际的操作类对象UseInfoDAO生成并赋值给IUseinfoDAO接口，然后再去CRUD。

于是像这样的结构每个表都至少对应两个操作文件，但是这个过程中，感觉接口类就是个脱了裤子放屁的，一点没有复用，每个操作接口只对应一个子操作类别，针对一个表进行操作，你不太可能继承出两个操作类来，那这么看压根就不需要这个接口，直接上操作类也说的通，那么这里为啥要这么设计？
------解决方案--------------------
你还真说对了，，每个实现类加了dao接口显得有些臃肿，每次都要两边改动，增加不少维护量，，我上个项目就去掉了，，，spring直接注入给了实现类  就好了。。

但是 这样子就违背了dao模式的规范原则，接口的好处就是换一个实现类，改一下配置，不用重新编译，然后就可以直接用了，，  但是不用也可以只替换下class文件也一样。。这就看你自己了。。
------解决方案--------------------
一般情况下，每个DAO中都有增删改查方法，所以都抽出来父类接口，继承之后，自己的接口里可以什么都不写，而你有了自己定义的方法，就到自己的接口中去加两个，也很方便。

至于用接口还是用实现，有些框架比较老，还没用到Spring，自己实现的动态代理，那么必须要接口，后面你说的直接上实现类，起码是有了spring和cglib之后。

直接用实现类还有一个很大的问题，接口很多是给外部程序远程使用的，比如EJB里的remote，如果你的实现类代码改了呢？再给人家打个包，让人家重新部署？使用接口+实现类，只要方法返回值类型和参数类型不变，实现随便你怎么改。