在Java领域,分层与解耦是我们追求的完美目标,这个过程中,Java接口似乎发挥了它作用,Dao层,Service层,每个类都要与一个接口相对应。这样确定能够降低实现类与调用之间耦合度,但这种作用却微不足道,几乎可以忽略,试想想,一个Java接口作以下定义:public interface UserDao { public List<User> query(String sex,int age);}倘若哪一天,你类User类中哪个参数的类型要修改时,又或者你要增加查询条件的参数个数时,这样你得改多少个地方?Dao层的接口,Dao层的实现类,Service层的接口,Service层的实现类,还有就是Action中的代码,可谓“牵一毛而动全身”啊.倘若不用接口的话,会大大减轻我们的负担。
前一段时间,我用Struts2+Hibernate3+Spring整合开发的一个系统过程中,就深受接口修改之苦!
权衡一下,接口,究竟带给我们什么好处?它带给我们的好处大还是坏处大?

解决方案 »

  1.   

    只在你觉得用接口确实对你提供帮助时才用   像这些企业应用用的这些一个类一个接口  基本就是2b用法 闲的
    当然公司有破规范什么的那就只能写上多个相似的类中有相同的功能函数用接口才是有意义的
    比如 集合类   collection Iterator等接口
    当然还有其他情况
      
      

  2.   

    1楼是一厢情愿,而且话没说完,尽可能考虑不要改动接口的话可以这样:
    query(QueryObj qo);
    QueryObj是vo,内涵属性:String sex,int age...这样需求变动时只改这个qo和接口实现类。6楼正解,大部分B/S企业应用都是项目而已,根本没必要这解耦那解耦的。
      

  3.   

    public List<User> query(User user);