我想，有很多朋友和我一样，肯定也发现了这个问题，为什么J2EE应用中，接口的使用量远远超过抽象类？记得在学校时，Java教材专门用了好几页来讲两者的区别，老师也抽出几节课的时间，和我们着重讲解接口和抽象类。看似懂了的我，实际却并不懂，就像这里提出的问题。
其实，无论对于接口，或者是抽象类，都是要求子类将本类中定义的方法实现，区别也仅仅是接口要求全部实现，抽象类中的非抽象方法不一定要重写。对于接口使用远超过抽象类的问题，网上有很多的解释。为了代码的重用？我觉得不是重点。为了更好的扩展性，太抽象了，和抽象类的定义一样让人无从捉摸。因为接口可以多重继承，这个解释太通俗了，很多刚入门的开发者，不能完全明白。
我的看法，接口使用多于抽象类，确实是因为接口可以多重继承，便于项目后期的维护和扩展。
贴一段网上搜的很好的知识点：
抽象类和接口之间的区别：
共性：它们都是不断抽取出来的抽象非概念
区别：
1、抽象类只能被单继承、接口可以被多实现，避免了单继承的局限性。
2、抽象类中可以定义抽象方法，和非抽象方法，它可以用于定义体系的基本共性的内容。接口中只能定义抽象方法，它主要用于对象的功能的扩展。
3、抽象类是继承关系，是is a关系，接口是实现关系是like a关系。
4、抽象类中的成员修饰符都是自定义的，接口中的修饰符都是固定的。
记住：不要把接口狭义的理解为interface,应该理解广义些，就是对外提供的规则，凡是对外暴露的都可以是接口。
下面比较一下两者的具体语法区别：
1.抽象类可以有构造方法，接口中不能有构造方法。
2.抽象类中可以有普通成员变量，接口中没有普通成员变量
3.抽象类中可以包含非抽象的普通方法，接口中的所有方法必须都是抽象的，不能有非抽象的普通方法。
4. 抽象类中的抽象方法的访问类型可以是public，protected和（默认类型,虽然eclipse下不报错，但应该也不行），但接口中的抽象方法只能是public类型的，并且默认即为public abstract类型。
5. 抽象类中可以包含静态方法，接口中不能包含静态方法
6. 抽象类和接口中都可以包含静态成员变量，抽象类中的静态成员变量的访问类型可以任意，但接口中定义的变量只能是public static final类型，并且默认即为public static final类型。
7. 一个类可以实现多个接口，但只能继承一个抽象类。
下面接着再说说两者在应用上的区别：
接口更多的是在系统架构设计方法发挥作用，主要用于定义模块之间的通信契约。而抽象类在代码实现方面发挥作用，可以实现代码的重用，例如，模板方法设计模式是抽象类的一个典型应用，假设某个项目的所有Servlet类都要用相同的方式进行权限判断、记录访问日志和处理异常，那么就可以定义一个抽象的基类，让所有的Servlet都继承这个抽象基类，在抽象基类的service方法中完成权限判断、记录访问日志和处理异常的代码，在各个子类中只是完成各自的业务逻辑代码
(这应该是最全最细的答案了)
最后是我的理解，ps:这其中有未蒙面的网友的智慧
比如公司系统中，有系统管理员，普通员工，主管，组长，经理等
这些角色都有登陆，修改密码这些共同的行为，这些行为规范可以被统一的命名，如Login和UpdatePassword，
那么，我们可以将这些方法抽到抽象类中，作为抽象方法，等待子类具体实现。当然各角色的身份不一样，所以实际上执行这些行为的步骤可能不一样，例如数据表的不同，则需要不同的子类去实现不同的代码，这就是抽象类比普通类作为基类被继承的其中一个优点。而实际上login操作，对于各类角色是一样的，那么，可以作为非抽象方法被继承，这就体现了抽象类在代码实现方面的优点，可以实现代码的重用。
实际上你也可以不用抽象类，直接在每个子类定义相应的行为也可以，如MemberLogin、AdminLogin等，但如果是在中大型软件里，基于命名规范化，后续扩展和维护考虑，可能用抽象类好些，统一用Login，这样后面的人看到这个就基本了解情况了，对吧。
再来说接口，打比方说，现在有A查看公司人员，B查看公司销售数据，C查看员工工资，这些行为对于普通员工，组长，经理，主管来说，并不是共有的行为。那么，抽象类就难以实现各个角色的不同行为，因为类的单继承性。而如果，A、B、C、分别是三个接口的话，那么经理继承ABC，员工继承A，主管继承AC，这样子处理的话，不仅易于理解，而且架构更加清晰，是吧。
更重要的一点是，假如公司的组织进行了调整，增加了一个职位。对于接口，只要这个角色去继承相应的接口即可，不会对于之前已经良好运行的代码做任何修改。事实上，对于已有代码的修改，是越少越好，因为代价很大，属于重复劳动，也可能出现意想不到的错误。这就是所谓的良好的扩展性，和可维护性。
我想看官应该理解了吧，如果你还不太清楚，我推荐这篇文章： http://blog.csdn.net/rujielaisusan/article/details/4628092