我想，有很多朋友和我一樣，肯定也發現了這個問題，為什么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