关于三层结构中用接口的优点是什么?

Question

一般做一个删除什么的操作,都是下面的流程
在Jsp页面点删除按扭,后
先去控制层（Controller层）-->业务逻辑层（Business层）-->DB层(DAO层)例如:一个删除的功能,伪代码如下
Class Controller  extends HttpServlet
{
public void service(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
.................................
.................................
.................................
//根据提交内容,去Business层的删除方法
.................................
.................................
.................................

}
}我经常看这里有两种做法一种是:直接 写 Business 类.然后调用DAO
Class Business
{
public void delete(pageParameter _pageParameter)
{
new DAO().delete(_pageParameter);
}
}Class DAO
{
public int delete(pageParameter _pageParameter){
retrun JdbcTemplet.queryForList("delete Table where id = "+_pageParameter.getId())
}
}第二种:是写一个接口,然后写一个实现,然后调用DAO
public interface IBusiness
{
  public void delete(pageParameter _pageParameter);
}Class Business  implements IBusiness
{
public void delete(pageParameter _pageParameter)
{
new DAO().delete(_pageParameter);
}
}Class DAO
{
public int delete(pageParameter _pageParameter){
retrun JdbcTemplet.queryForList("delete Table where id = "+_pageParameter.getId())
}
}
我现在用ajax + spring 开发,经常看别人用第二种方式写!
把一个页面上业务先都写入接口.然后在继承实现.
实在不知道有什么好处!给我感觉都是多写一个接口,实在不知道好处在那里....知道的能说说吗?

Answer 1

对测试非常有利
你的同事可能用到你的这个功能，它可以完全不用等你把代码完成才能使用，可以自己先实现一个虚假的实现类。
比如class Business implements IBusiness {
  public void delete(pageParameter _pageParameter) {
    return true; // 可以虚假的测试成每次都成功，或者作规则返回false
  }
}

Answer 2

哇，你的delete竟然不返回值。
class Business implements IBusiness {
  public void delete(pageParameter _pageParameter) {
    return;
  }
}

Answer 3

你已经5个三角了，相信你挺过很多真对接口编程的好处，
但听归听，具体给你带来了什么好处可能还感触不多这类问接口作用的问题很多，即使有过几年工作经验的人仍然不明白
提个建议，你可以看看《head_first 设计模式解析》，里面说的比我明白
不过更重要的是你要多练，多找感觉

Answer 4

可以替换吧，
接口约定实现的一些方法，具体的类去实现这些接口
spring可以注入各个属性，这样每个类都不会依赖了
代码中声明的全是接口类型，和实现类没有关系

Answer 5

这就是 面向接口编程了。。
建议楼主看看 设计模式 之类的书
如：阎宏 的 《java与模式》 

Answer 6

最大的好处就是灵活性。
如果你想持久化数据，可以用DAO， 不想持久化 可以用XML，
但他们提供的接口都是一样的，只是实现不同罢了～

Answer 7

面向接口编程模式：上层组件不应该依赖下层组件，而是组件都必须依赖于抽象。你那DAO层也应该再分离成IDAO抽象层和真实的DAO层吧？！俺是菜鸟，说错了表拿转拍偶。

Answer 8

To 海绵宝宝，你讲的第一句话来自于 敏捷开发的IDP原则，而IDP原则本身的争议就很大。而且它所讲的上层和下层的关系，并非这里所指的层。
从实际的开发来说，分层的好处如 老紫竹 说的，但是不一定完全要那么刻板。
但是楼主作为一个框架的设计者，就应该严格恪守分层的原则。

Answer 9

class Business implements IBusiness { 
    public void delete(pageParameter _pageParameter) {
        // 一般不会在方法中new的，采用成员变量方式，使用Spring来注入实现类
        new DAO().delete(_pageParameter);
    }
} interface IDAO {
    public int delete(pageParameter _pageParameter);
}
class DAO implement IDAO extends JdbcTemplet { 
    public int delete(pageParameter _pageParameter) { 
        retrun queryForList("delete Table where id="+_pageParameter.getId());
    } 
}如果再做得好一点的话，可以采用泛型将基本的CRUD操作只要写一次就可以了，其他的DAO继承一下，这样可以每个DAO少写四个操作。

Answer 10

我的理解是   这么做的好处 就是 可以 降低 层与层之间的耦合度,没有任何依赖, 一旦出了问题也可以很块定位是哪里出现的错误,方便后期的系统维护和扩展.  c/s 一定会用的 , 如果是 我现在搞的 报表系统就没那么强烈了, 因为报表系统有很多相似的页面,所以我就只写了一个页面 其他全拿 xml 画,  所以作用没那么明显.

Answer 11

分层，松耦合，带来灵活性。
比如，用了interface之后，别的同事不用等你开发完再继续，他可以和你并行工作，缩短工期。
随时可以更换实现；
随时可以用动态代理，实现AOP。

Answer 12

降低耦合度，不依赖于具体的实现。假如有一天你的删除方法里业务逻辑变了，不用改动原来的代码。再写一个类实现那个接口。在XML改一下注入的类就可以了

Answer 13

学习了，Mark，我也一直被这个问题困扰着。
原来是这么回事，我也一直使用第一种方法。。