面向接口的編程正是java的優點，首先 用起來方便，結構清晰

在j2ee中的接口也就是類，類與類之間的通信因為接口而變的簡單易懂

呵呵，像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就可以了，而在已經寫好的代碼中，我們可以一行不
改的進行了數據庫移植，這個就 是面向對象設計原則中的“開-閉原則”（對增加是開放的，對修改是封閉的）。但
這只是理論上的，現實中很難做到的。

接口 = 電腦的USB插口!

因為接口訂好了，所以那面到底插的是什么就不重要了！
我們用戶只需要
1 插上去
2 停用移動設備
3 拔下來

這三個就好似USB的接口功能。他隱藏了實際功能，但提供給用戶統一的操作界面和使用方式

寫小的應用程序看不到接口的優勢，寫大點的程序馬上就顯示出接口的優勢，越大越明顯．所以還是從現在開始養成面向接口編程的習慣．寫多了程序就會覺得優勢 顯而易見．

鏈條組裝起來了,然后向上面掛東西.....掛的東西可以隨時拿下來,可以隨時替換掉,可以隨時安上去.......

子類只能繼承一個父類
卻可以繼承多個接口..功能區分清晰，改起來方便
夠了吧
多給點

優點：
接口和實現分離了，適于團隊的協作開發。

更具體的優點：可以參看IDP原則。

缺點：
設計難了，在你沒有寫實現的時候，就得想好接口，接口一變，全部亂套，這就是 所謂的設計比實現難。

主要為了實現松散耦合的系統，便于以后升級，擴展．你去研究一下spring吧，那東東會讓你真正體會到interface的優點．

接口，主要是為了 彌補 JAVA 丟失的 多繼承性 的特點吧 。。。

封裝好，好使用

易擴展

容易讓人把編寫程序和現實聯系起來。呵呵

接口在項目中用的比較多的原因是，當你調用別人的接口時可以不用部署，直接引用就行了。

我記得我曾經在一篇帖子中提到過，一個接口可以從三方面去考察：
制 定者（或者叫協調者），實現者（或者叫生產者），調用者（或者叫消費者）。

接口本質上就是由制定者來協調實現者和調用者之間的關系。

所以通常說的 “面向接口編程”可以理解為：
只有實現者和調用者都遵循“面向接口 編程”這個準則，制定者的協調目的才能達到。

一個老生常談的例子就是JDBC。

很多人費解：既然我每連接 一種數據庫（如mysql）都要事先部署驅動程序，那我直接訪問驅動程序不就行了？還要JDBC干嗎？

實際上，JDBC已經起了至關重要 的作用了：正因為驅動程序是按照JDBC所規定的方法編寫的，你才可以按照JDBC的方式去使用。
換句話說，如果驅動程序提供者不按照JDBC標 準來編寫，而是按它自己獨創的方式編寫，那么你在使用驅動程序的時候就要花時間查看驅動程序的文檔以搞清楚用法。而當你日后決定使用另一種數據庫的時候， 這種數據庫的驅動程序也不是按照JDBC編寫的，你又得去搞清楚另一套完全不同的用法，而你的所有代碼都必須做相應的更改。這種代價是不可想象的。

而 現在的情況是，驅動程序提供者都按照JDBC規定的方式來編寫，程序員都按照JDBC規定的方式來使用。程序員不用關心自己正在使用何種數據庫，而驅動程 序編寫者也不用費盡心力去編寫接口文檔來向程序員解釋驅動程序的用法，大家都向標準看齊就行了。

轉載自：http://www.java123.net/JavaSE/mianxiangjiekoubianchengdehaochuheyoudian_7139.html