我对针对接口编程的浅解

首先，使用接口编程是为了提高程序的可维护性和可伸缩性。如果你在一个类里使用组合调用另一个类时，你直接使用另一个具体的类，这样的话你就不这个类写死了，以后假如业务逻辑变化时，你就必须修改原代码。你如果写的是一个接口，当业务逻辑变化时你只需写一个新的类让他实现这个接口。
      第二，你还要用类似spring这样的东西，实现松耦合，利用配置文件修改程序。比如要完成一个登录功能：
           我先写dao层，其中用到了4个类，
    DaoBase.java,用来得到user对象
    package com.ssh2demo.dao;

    import com.ssh2demo.domain.User;

    public abstract class DaoBase {
   
       private User user;

       public User getUser() {
        return user;
       }

        public void setUser(User user) {
        this.user = user;
        }
  
    }
    IUserDao.java,一个接口，用来封装登录的方法
    public interface IUserDao {
       public void insertUser();

       public boolean getUserByName(String name);//如果返回true代表登录成功
              }
    IUserDao的实现类UserDaoImp.java
    package com.ssh2demo.dao;

    import com.ssh2demo.domain.User;

    public class UserDaoImp extends DaoBase implements IUserDao{
    //..插入一个user
        User user = new User();
        public void insertUser(){
            user.setAge(23);
            user.setName("hth");
            user.setPassword("123456");
        }
  
        public boolean getUserByName(String name){
            insertUser();
            if(user.getName().equals(name))
                return true;
            else
                return false;
        }
    }

    UserDaoDeco.java这个类继承了UserDaoImp，用来向spring文件里注入
    <bean id="userDaoDeco" class="com.ssh2demo.dao.UserDaoDeco"></bean>
    <bean id="userServiceImp" class="com.ssh2demo.service.UserServiceImp">
        <property name="userDaoDeco">//此处其实这步的属性可以直接放接口，注入的类放实现类就                             //可以
            <ref bean="userDaoDeco"/>
        </property>
    </bean>
    UserDaoDeco.java
    package com.ssh2demo.dao;

    import com.ssh2demo.dao.UserDaoImp;

    public class UserDaoDeco extends UserDaoImp{

    }
    然后写service层，service层用了一个工厂类和工厂接口，用来管理service类，这样写方便了在action里我只要注入工厂类就可以了，所有的service我都可以通过工厂获得
    <bean id="loginAction" class="com.ssh2demo.struts2.LoginAction" singleton="false">
        <property name="service">//此处放一个接口，直接让action不关心类的具体实现，实现了松耦合
                          //使程序易于改动，做到了新加而不是修改。
            <ref bean="serviceFactory"/>
        </property>
    </bean>

评论

109 楼 anky_end 2010-02-04  

iaimstar 写道

抛出异常的爱 写道

3.在需求讨论会上一个个业务代表手写出一条条sql给客户看，之后客户指着一条五百多米长的sql说这就是我想要的。

艹，老抛还是那么搞笑

笑死我了

大就是美，多炮塔？

108 楼 iaimstar 2010-02-04  

抛出异常的爱 写道

3.在需求讨论会上一个个业务代表手写出一条条sql给客户看，之后客户指着一条五百多米长的sql说这就是我想要的。

艹，老抛还是那么搞笑

笑死我了

107 楼 anky_end 2010-02-04  

抛出异常的爱 写道

引用

站在珠穆朗玛的顶峰 队员对队长说 您一路上让我背着的救生圈 一次也没有用到 它的存在就是为了折磨我 应该在下山之前扔掉它

那就去了吧.留着留着就生出祸害了.

anky_end 写道

我的想法是，多个接口，往往你调试过程就多个麻烦。

当然接口的好处可以搜索到的资料也够多，只不过往往未必比的上包里面多了这么个。class文件，在调试时候另外寻找实现类给你带来的麻烦多。

系统级别的设计使用接口，还是很有必要的。因为系统设计升级换代的几率不低；而业务逻辑设计，更换实现类的可能性并不大，往往是直接修改原先的实现类罢了。

1.用测试不用debug
2 ctrl+t
3.在需求讨论会上一个个业务代表手写出一条条sql给客户看，之后客户指着一条五百多米长的sql说这就是我想要的。

^_^
说错。大概意思您也能理解，以前可以直接点击服务类名进入，现在多一个查找过程。
ctrl+t啥的俺也知道，不过总归是麻烦。

俺的看法自觉已经表述的比较清楚了，当变更少时候，不用接口更方便些，别的不说，包里面少几个java看起来都舒服些。这个度要自己把握了。。

106 楼 抛出异常的爱 2010-02-03  

引用

站在珠穆朗玛的顶峰 队员对队长说 您一路上让我背着的救生圈 一次也没有用到 它的存在就是为了折磨我 应该在下山之前扔掉它

那就去了吧.留着留着就生出祸害了.

anky_end 写道

我的想法是，多个接口，往往你调试过程就多个麻烦。

当然接口的好处可以搜索到的资料也够多，只不过往往未必比的上包里面多了这么个。class文件，在调试时候另外寻找实现类给你带来的麻烦多。

系统级别的设计使用接口，还是很有必要的。因为系统设计升级换代的几率不低；而业务逻辑设计，更换实现类的可能性并不大，往往是直接修改原先的实现类罢了。

1.用测试不用debug
2 ctrl+t
3.在需求讨论会上一个个业务代表手写出一条条sql给客户看，之后客户指着一条五百多米长的sql说这就是我想要的。

105 楼 anky_end 2010-02-03  

我的想法是，多个接口，往往你调试过程就多个麻烦。

当然接口的好处可以搜索到的资料也够多，只不过往往未必比的上包里面多了这么个。class文件，在调试时候另外寻找实现类给你带来的麻烦多。

系统级别的设计使用接口，还是很有必要的。因为系统设计升级换代的几率不低；而业务逻辑设计，更换实现类的可能性并不大，往往是直接修改原先的实现类罢了。

104 楼 anky_end 2010-02-03  

我也认为，不需要无谓的接口，特别是业务逻辑上的。

在系统设计这个级别，java的接口就是个很好的示例：例如，map，list。

但是这种情况也可以使用接口：
多人协作，比如a写action，jsp，b写service，dao，这时候需要事先定义一个接口进行协作，分头开发。
如果是一人包打天下的这种，在技术上可以直接在实现类上先写好空方法（俺说的已经算是细节的做法了。。）

我的看法是，像每个业务逻辑定义一个接口这种做法，并不是完全必要的。这样后期修改你还得通过配置文件去寻找实现类（特别是使用spring，当然好处就是，如果替换实现类工作量也少。）

具体业务逻辑上，是否使用接口，我倾向80%情况是不必要的。如果是对外提供服务的方法，最好要有接口，作为一种规范。

103 楼 aiyoo521 2010-02-03  

<div class="quote_title">抛出异常的爱 写道</div><div class="quote_div"><div class="quote_title">aiyoo521 写道</div>
<div class="quote_div">
<p>我想挺一下楼主。看了大概6页回帖，发现正反两方的分歧越来越大（时间有点久了，有点挖坟的感觉）。</p>
<p>楼主所说的是“<span style="color: #ff0000;">不需要无谓的接口</span>”。</p>
<p>而大家反驳的大多数是“<span style="color: #ff0000;">必须要有接口</span>”。</p>
<p>本身两种观点就是矛盾的了，越往后走，分歧越大，真的希望双方仔细分析，理解一下对方的话，而不是句句以“I don't think so”开始。</p>
<p> </p>
<p>关于挺楼主的原因，是缘于目前我参与的一个项目。</p>
<p>这个项目的EJB层中有这么两个包：cn.xxx.xxx.ejb.intf.bizz和cn.xxx.xxx.ejb.impl.bizz</p>
<p>两个包中的文件完全是一一对应的。其中intf中的文件以Service结尾，impl中的则以ServiceBean结尾。</p>
<p>而整个项目中，这类"双子座"存在着3对。</p>
<p>在我看来，这就是多余。</p>
<p>每次修改代码，都要先修改intf，再改impl。只是机械的改，没有目的的改。</p>
<p> </p>
<p>也正因为如此，我来到网上疯狂的搜索"接口"的价值。几个小时之后来到这个帖子，见到楼主。</p>
<p>我认为，在我所讲的这个实际例子中，intf包是完全没有存在价值的。</p>
<p>因为无论是扩展还是可维护性，好像根本看不到什么优势。</p>
<p>反倒是修改代码时花了双倍的时间。</p>
<p> </p>
<p>而真正用到接口的地方，也有，但是不多。</p>
<p>比如说抽象类xxBaseBean，里面实现了log管理和事务管理，这是有价值的接口。</p>
<p> </p>
<p>几个小时之后，我小心翼翼的总结出了如上自己对接口编程的认识。</p>
<p>并决定否定那种遇事必接、无接无类的形式主义。</p>
</div>
<p>站在时间曲线的尽头</p>
<p>航员对船长说</p>
<p>您一路上让我维护的灯塔</p>
<p>一个也没有用到</p>
<p>它们的存在就是为了折磨我</p>
<p>应该在回去的路上拆除它们.</p>
<p> </p>
<p> </p></div><br/>站在珠穆朗玛的顶峰
队员对队长说
您一路上让我背着的救生圈
一次也没有用到
它的存在就是为了折磨我
应该在下山之前扔掉它

102 楼 抛出异常的爱 2010-02-03  

<div class="quote_title">aiyoo521 写道</div>
<div class="quote_div">
<p>我想挺一下楼主。看了大概6页回帖，发现正反两方的分歧越来越大（时间有点久了，有点挖坟的感觉）。</p>
<p>楼主所说的是“<span style="color: #ff0000;">不需要无谓的接口</span>”。</p>
<p>而大家反驳的大多数是“<span style="color: #ff0000;">必须要有接口</span>”。</p>
<p>本身两种观点就是矛盾的了，越往后走，分歧越大，真的希望双方仔细分析，理解一下对方的话，而不是句句以“I don't think so”开始。</p>
<p> </p>
<p>关于挺楼主的原因，是缘于目前我参与的一个项目。</p>
<p>这个项目的EJB层中有这么两个包：cn.xxx.xxx.ejb.intf.bizz和cn.xxx.xxx.ejb.impl.bizz</p>
<p>两个包中的文件完全是一一对应的。其中intf中的文件以Service结尾，impl中的则以ServiceBean结尾。</p>
<p>而整个项目中，这类"双子座"存在着3对。</p>
<p>在我看来，这就是多余。</p>
<p>每次修改代码，都要先修改intf，再改impl。只是机械的改，没有目的的改。</p>
<p> </p>
<p>也正因为如此，我来到网上疯狂的搜索"接口"的价值。几个小时之后来到这个帖子，见到楼主。</p>
<p>我认为，在我所讲的这个实际例子中，intf包是完全没有存在价值的。</p>
<p>因为无论是扩展还是可维护性，好像根本看不到什么优势。</p>
<p>反倒是修改代码时花了双倍的时间。</p>
<p> </p>
<p>而真正用到接口的地方，也有，但是不多。</p>
<p>比如说抽象类xxBaseBean，里面实现了log管理和事务管理，这是有价值的接口。</p>
<p> </p>
<p>几个小时之后，我小心翼翼的总结出了如上自己对接口编程的认识。</p>
<p>并决定否定那种遇事必接、无接无类的形式主义。</p>
</div>
<p>站在时间曲线的尽头</p>
<p>航员对船长说</p>
<p>您一路上让我维护的灯塔</p>
<p>一个也没有用到</p>
<p>它们的存在就是为了折磨我</p>
<p>应该在回去的路上拆除它们.</p>
<p> </p>
<p> </p>

101 楼 aiyoo521 2010-02-03  

<p>我想挺一下楼主。看了大概6页回帖，发现正反两方的分歧越来越大（时间有点久了，有点挖坟的感觉）。</p>
<p>楼主所说的是“<span style="color: #ff0000;">不需要无谓的接口</span>”。</p>
<p>而大家反驳的大多数是“<span style="color: #ff0000;">必须要有接口</span>”。</p>
<p>本身两种观点就是矛盾的了，越往后走，分歧越大，真的希望双方仔细分析，理解一下对方的话，而不是句句以“I don't think so”开始。</p>
<p> </p>
<p>关于挺楼主的原因，是缘于目前我参与的一个项目。</p>
<p>这个项目的EJB层中有这么两个包：cn.xxx.xxx.ejb.intf.bizz和cn.xxx.xxx.ejb.impl.bizz</p>
<p>两个包中的文件完全是一一对应的。其中intf中的文件以Service结尾，impl中的则以ServiceBean结尾。</p>
<p>而整个项目中，这类"双子座"存在着3对。</p>
<p>在我看来，这就是多余。</p>
<p>每次修改代码，都要先修改intf，再改impl。只是机械的改，没有目的的改。</p>
<p> </p>
<p>也正因为如此，我来到网上疯狂的搜索"接口"的价值。几个小时之后来到这个帖子，见到楼主。</p>
<p>我认为，在我所讲的这个实际例子中，intf包是完全没有存在价值的。</p>
<p>因为无论是扩展还是可维护性，好像根本看不到什么优势。</p>
<p>反倒是修改代码时花了双倍的时间。</p>
<p> </p>
<p>而真正用到接口的地方，也有，但是不多。</p>
<p>比如说抽象类xxBaseBean，里面实现了log管理和事务管理，这是有价值的接口。</p>
<p> </p>
<p>几个小时之后，我小心翼翼的总结出了如上自己对接口编程的认识。</p>
<p>并决定否定那种遇事必接、无接无类的形式主义。</p>

100 楼 lovejavaei 2009-05-12  

接口是为了实现分工和重用产生的，分工和重用需要规范，所以接口实际上是代码级的规范。实现分工和重用还可以用反射来做到，但是需要文档级的规范，在开发的时候，代码级的规范明显比文档级的规范要好。没有规范一样可以生产产品，有了规范不一定效率就高，规范的遵循时可以灵活把握的。

99 楼 pojo333 2009-05-12  

接口是一种基于行为的抽象吗？
还是只是一系列的方法协议封装与抽象无关 ... ...

98 楼 neora 2009-04-25  

对于强类型的语言，应该有个Interface关键词，有了这个关键词，使的语言从类型上“强”上加“强”，将约定的检查提升到设计时；
对弱类型语言来说，interface实际存在与概念上，而事实上在runtime也存在对约定的检查过程。

97 楼 43385607 2009-04-25  

我觉得既然你现在一直都不能理解，那就不要用，等到真正遇到麻烦的时候再回来考虑

96 楼 risemanjavaeye 2009-04-24  

<div class="quote_title">抛出异常的爱 写道</div>
<div class="quote_div">
<div class="quote_title">risemanjavaeye 写道</div>
<div class="quote_div">个人感觉，接口&gt;interface,接口是抽象，interface只是实现抽象的一种方式，如果你的业务逻辑中没有抽象，当然就没有必要在你的程序中体现抽象，其实你也没法真正体现出来，因为本来就没有抽象。你怎么去设计一个抽象出来？当然，任何事物都可以去做抽象，但并不是任何事物从任何角度都可以进行抽象</div>
<br>抽象就是把乎不会变的部分抽出来 <br><br>比如:人有名子有性别 ,你可以抽出来. <br>但有没有工作...你没必要抽像出来. <br>有没有手...想抽就抽不想抽就不抽. <br>你不必为特例去改变的抽象. <br>遇到没有手的,就用hacker方式.... <br><br><br>稳定的需求放入接口, <br>不稳定的需求分解成稳定的需求 <br>放入其它接口.....</div>
<p>大哥，不太明白你的意思啊，呵呵</p>
<p> </p>

95 楼 抛出异常的爱 2009-04-23  

risemanjavaeye 写道

个人感觉，接口>interface,接口是抽象，interface只是实现抽象的一种方式，如果你的业务逻辑中没有抽象，当然就没有必要在你的程序中体现抽象，其实你也没法真正体现出来，因为本来就没有抽象。你怎么去设计一个抽象出来？当然，任何事物都可以去做抽象，但并不是任何事物从任何角度都可以进行抽象

抽象就是把乎不会变的部分抽出来

比如:人有名子有性别 ,你可以抽出来.
但有没有工作...你没必要抽像出来.
有没有手...想抽就抽不想抽就不抽.
你不必为特例去改变的抽象.
遇到没有手的,就用hacker方式....


稳定的需求放入接口,
不稳定的需求分解成稳定的需求
放入其它接口.....

94 楼 risemanjavaeye 2009-04-23  

个人感觉，接口>interface,接口是抽象，interface只是实现抽象的一种方式，如果你的业务逻辑中没有抽象，当然就没有必要在你的程序中体现抽象，其实你也没法真正体现出来，因为本来就没有抽象。你怎么去设计一个抽象出来？当然，任何事物都可以去做抽象，但并不是任何事物从任何角度都可以进行抽象

93 楼 yuxie 2009-04-23  

energykey 写道

只是new的时候我可以直接new接口，而不是实现类，神不知，鬼不觉，呵呵。

这个new接口比较强

92 楼 eimhee 2009-04-23  

学习！！！！！

91 楼 energykey 2009-04-23  

接口肯定是有用的，以前我也只是随波逐流，看了前面的朋友说的受益匪浅。这个得看需求了，一般的项目用接口有点多余，不过从架构上来讲，理论上来讲用接口的好，但从效率上来讲不一定好。像我现在在做维护，项目是标准的SSH，每次维护或新增一个功能都要dao-定义接口
daoimpl-实现接口
service-定义接口
serviceimpl-实现接口
有可能引入新的dao，spring得新增相关配置。

是有些麻烦的，说实话感觉不到有什么好处，只是new的时候我可以直接new接口，而不是实现类，神不知，鬼不觉，呵呵。

但我觉得前面的朋友说的还是有些道理的，比如接口就是一种规范，可以限制实现类，不符合规范就不能编译通过，还有多人协同开发时也确实有用。

某楼朋友说，国内基本上都没有2次开发，我非常同意这个观点，这也是现在这么多人去做.net的原因，.net追求的就是快速开发，事实上有几个项目会做2次开发？当然也许有，这个就得看项目的需求了。

90 楼 yuerthe9 2009-04-15  

<p>接口的使用级别是框架级的，其思想效果明显高于抽象类，当然语法效果也不是一个级别。</p>
<p> </p>
<p>对于可以简单实现、变化较小或没有变化的地方，一味的使用高层次的语法元素是扯淡。但并不是说接口没用，而是没有把它放到合适的场合。很多人应该都使用hibernate、spring等，在这些框架中大量使用了接口，如果不使用接口我不知道可不可以实现，但是有一点可以知道——我们身处的不是OOA/OOD时代。</p>