接口编程的好处

在项目中的意义： 
   在传统的项目开发过程中，由于客户的需求经常变化，如果不采用面向接口编程，那么我们必须不停改写现有的业务代码。改写代码可能产生新的BUG，而且改写代码还会影响到调用该业务的类，可能全都需要修改，影响系统本身的稳定性。而且为了将改写代码带来的影响最小，我们不得不屈服当前的系统状况来完成设计，代码质量和稳定性更低。当这种情况积累到一定程度时，系统就会出现不可预计的错误，代码凌乱，不易读懂，后接手的人无法读懂代码，系统的维护工作越来越重，最终可能导致项目失败。 
接口在项目就是一个业务逻辑，面向接口编程就是先把客户的业务提取出来，作为接口。业务具体实现通过该接口的实现类来完成。当客户需求变化时，只需编写该业务逻辑的新的实现类，通过更改配置文件(例如Spring框架)中该接口的实现类就可以完成需求，不需要改写现有代码，减少对系统的影响。 采用基于接口编程的项目，业务逻辑清晰，代码易懂，方便扩展，可维护性强。即使更换一批人员，新来的人依然可以快速上手。对于公司来说，意义更大。 

在Java中的意义： 
   Java本身也是一个不断完善的语言，他也在频繁的改动他的系统API来完善，他的API是一个庞大的体系，互相关联，如果不采用接口，而都是用实现类的话，那么API的改动就会给整个体系带来不稳定。而且如果改动API，那么就会有大量采用旧API的项目因无法正常运行，会损失大量客户。换句话说，JDK已经发布的API是一种承诺，一经发布就不能更改，即使原来API存在各种各样的问题（例如java.util.Properties类就是一个失败的例子）也必须保留，于是在Java里就出现了不建议使用的方法，但JDK依然提供该方法。而且Java语言本身是一个跨平台的语言，为了满足在各个平台下运行，就必须把各种操作做成接口，在编写各个平台下的实现类。 

比如：MngImpl实现层中调用Dao的接口，当系统的数据库发生变化，sql语句有不同，只需重新写一个oracle的实现类，再配置文件就可以

设计模式的体现： 
   在设计模式的原则里的开闭原则，其实就是要使用接口来实现对扩展开放，对修改关闭。在设计模式的其他原则里也有关于基于接口编程的原则，即依赖倒转的设计原则(DIP)----高层模块不应该依赖于底层模块。二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象(注：来自《敏捷软件开发--原则、模式与实践》Robert C.Martin著)。在使用面向接口的编程过程中，将具体逻辑与实现分开，减少了各个类之间的相互依赖，当各个类变化时，不需要对已经编写的系统进行改动，添加新的实现类就可以了，不在担心新改动的类对系统的其他模块造成影响。 


接口本质上就是由制定者来协调实现者和调用者之间的关系。 

所以通常说的“面向接口编程”可以理解为： 
只有实现者和调用者都遵循“面向接口编程”这个准则，制定者的协调目的才能达到。 
一个老生常谈的例子就是JDBC。 

优点： 
接口和实现分离了，适于团队的协作开发。 
主要为了实现松散耦合的系统，便于以后升级，扩展。

缺点： 
设计难了，在你没有写实现的时候，就得想好接口，接口一变，全部乱套，这就是所谓的设计比实现难。

 

 

总结：面向接口编程使代码逻辑更加清晰，不用被实现所掩盖，维护都变得心中有数。

 

===================================================================================

 

像J2EE中的API规范基本上都是接口，由各应用服务器来实现，比如：WebSphere按照这个接口实现自己的，WebLogic也按照这个接口实现自己的，作为开发者来说我们根本就不用去管谁是怎样实现的，只要按照J2EE的API来写就可以了，根本用不着导入它们的实现包，实际上具体的是由它们自身完成了。
接口说白了，也就是定死了一个框，具体的是糊红纸还是糊黑纸我们都用不着去管的，我们只要知道它是个框，提供了哪些方法就够了。
举个简单的JDBC的例子吧，比如有个BaseDao接口，现在有MySQLDao实现了一个（我们可以把具体的实现类配在配置文件中，再通过反射进行实例化），也就类似这样的：

BaseDao dao = (BaseDao)(Class.forName(Config.getDaoName()).newInstance());

其中Config.getDaoName()可以获得配置文件中的配置，比如是：com.bao.dao.impl.MySQLDao。

之后，那些人开始要烧钱了，要改用Oracle了，这样我们只要按BaseDao的定义，再实现一个OracleDao就可以了，再将配置文件中的配置改为：com.bao.dao.impl.OralceDao就可以了，而在已经写好的代码中，我们可以一行不改的进行了数据库移植，这个就是面向对象设计原则中的“开-闭原则”（对增加是开放的，对修改是封闭的）。但这只是理论上的，现实中很难做到的。

 

====================================================================================

比如说，你要注册一个用户，前面是业务逻辑，要调用数据访问层的save(user)方法。先写一个数据访问对象的接口

public interface IDAO{    void save(User user) throws UserNameExistException;}

jdbc的实现是

public class JDBCDAO implements IDAO{    public void save(User user) throws UserNameExistException{        .....        String sql = "insert into t_user values(?,?,?,?)";        ....        PreparedStatement pstm = conn.prepareStatement(sql);        pstm.setString(1,user.getName());        ....        pstm.executeUpdate();        ......    }}

Hibernate的实现是

public class HibernateDAO implements IDAO{    public void save(User user) throws UserNameExistException{        ......        session.save(user);        session.getTransaction().commit();        ....    }}

你的业务层UserService只要这么写

public class UserService{    public void register(String userName,String password,int age,....等等参数){        //假设现在用的是JDBC的实现        IDAO dao = new JDBCDAO();//当你需要替换实现的时候，只要把这个JDBCDAO换成HibernateDAO就可以了，其它代码不需要改。        User user = new User();        user.setName(userName);        ......        dao.save(user);    }}

=======================================================================

编程也是一门艺术，在C语言中灵活的使用指针是一门艺术，在面对对象的程序中，灵活的使用接口也是一门艺术。现在项目中，功能越来越复杂，只设计了完美的类，对于整个系统来说没有多大意义，现在的项目更注重各个功能模块的整合及可维护性，接口的设计就显得更为重要了。程序设计不再是设计类的具体实现，而是从整个项目出发，设计出可扩展性强的接口。当你发现越来越灵活的使用接口时，那么你就从程序员升级为架构师了。可惜我现在依然是一名程序员，正在像架构师努力。
在一些大型项目或者大型公司里，都是由架构师编写出系统接口，具体的实现类交给了程序员编写，公司越大这种情况越明显，所以在这些公司里做开发，我们可能都不知道编写出的系统是个什么样子，每天做的工作可能就是做“填空题”了。建议大家阅读敏《捷软件开发--原则、模式与实践》Robert C.Martin著这本书，那么对如何进行接口编程就会有一个新的认识了。