JAVA面向接口的編程思想與具體實現

 面向對象設計裏有一點你們已基本造成共識，就是面向接口編程，我想大多數人對這個是沒有什麼以爲須要懷疑的。
        問題是在實際的項目開發中咱們是怎麼體現的呢？ 難道就是每個實現都提供一個接口就了事了？反過來講，你有時候有沒有以爲接口是多餘的事？ 又或者，你僅僅是以爲如今相似spring這樣的框架已習慣用接口這種方式而心存固然。 
        設計模式解析裏提到了面向對象設計考慮的幾個視角，一個是概念層，一個是規約層，一個是實現層。我若是沒有猜錯的話，實際上咱們大多數人的眼睛一直是盯着實現層的，而這正是面向對象設計所極力避免的，即你不要在一開始就關注這些細節，你要關注的是規約（接口）.
        對於實際項目開發來講，若是咱們把實現的過程分爲多個階段的話咱們不妨這麼劃分，第一階段，根據client端的須要去設計咱們的規約(interface),在這個階段任何實現都沒有，全部的任務就是定義接口所須要的職責，以及所須要的一些po,vo;第二階段，實現前面定義的規約.
        之前我是怎麼作的呢？ 我是交叉做的，即假模假樣的定義一個接口（其實我內心在想這個東西有屁用）,而後定義了一個方法，而後就當即去實現這個方法，再而後我又定義一個方法，繼續去實現，我如今終於想通了，這樣好累，效率很低，最重要的是，這不屬於真正的設計。
        如今我是怎麼作的呢？好比一個list.jsp裏須要查詢，列表，而後看明細信息，而後增長信息，我會第一步在接口裏定義完(這個過程會有總體設計的意識),絕不關心底層實現(數據庫、事務)，個人目標就是"我想要這個功能，我想要那個功能"，至於那個功能怎麼實如今第一階段我認爲那不是個人事情(儘管這個事情最終仍是由我來作) .你們看這個過程和前面的過程有什麼本質的不一樣呢？ 就是分層的概念更加明顯，你的工做更有層次，每次都有先設計再實現的步驟，而前面那個過程很容易就讓你不知不覺地陷入純實現的陷阱中。

什麼叫面向接口編程？
        在一個面向對象的系統中，系統的各類功能是由許許多多的不一樣對象協做完成的。在這種狀況下，各個對象內部是如何實現的對系統設計人員來說就不那麼重要了；而各個對象之間的協做關係則成爲系統設計的關鍵。小到不一樣類之間的通訊，大到各模塊之間的交互，在系統設計之初都是要着重考慮的，這也是系統設計的主要工做內容。面向接口編程我想就是指按照這種思想來編程吧！實際上，在平常工做中，你已經按照接口編程了，只不過若是你沒有這方面的意識，那麼你只是在被動的實現這一思想；表如今頻繁的抱怨別人改的代碼影響了你（接口沒有設計到），表如今某個模塊的改動引發其餘模塊的大規模調整（模塊接口沒有很好的設計）等等。
　　Booch先生那天談到Interaction Designer，它就是指作這類設計的人，只不過層次更高一些。我想目前咱們的軟件設計隊伍中，這類人是最缺少的人才之一。 
非接口編程？是否是就是面向過程的編程思想？
        1.關於接口的理解
　　接口從更深層次的理解，應是定義（規範，約束）與實現（名實分離的原則）的分離。 
　　咱們在通常實現一個系統的時候，一般是將定義與實現合爲一體，不加分離的，我認爲最爲理解的系統設計規範應是全部的定義與實現分離，儘管這可能對系統中的某些狀況有點繁煩。 
　　接口的自己反映了系統設計人員對系統的抽象理解。 
　　接口應有兩類：
         第一類是對一個體的抽象，它可對應爲一個抽象體(abstract class)； 
　　第二類是對一個體某一方面的抽象，即造成一個抽象面（interface）； 
　　一個體有可能有多個抽象面。 
　　抽象體與抽象面是有區別的。
        2.設計接口的另外一個不可忽視的因素是接口所處的環境(context,environment)，系統論的觀點：環境是系統要素所處的空間與外部影響因素的總和。任何接口都是在必定的環境中產生的。所以環境的定義及環境的變化對接口的影響是不容忽視的，脫離原先的環境，全部的接口將失去原有的意義。
        3.按照組件的開發模型（3C），它們三者相輔相成，各司一面，渾然一體，缺一不可。
　　面向對象是指，咱們考慮問題時，以對象爲單位，考慮它的屬性及方法 
　　面向過程是指，咱們考慮問題時，以一個具體的流程（事務過程）爲單位，考慮它的實現 
　　接口設計與非接口設計是針對複用技術而言的，與面向對象（過程）不是一個問題
　　我認爲：UML裏面所說的interface是協議的另外一種說法。並非指com的interface，CORBA的interface，Java的interface，Delphi的interface，人機界面的interface或NIC的interface。
　　在具體實現中，是能夠把UML的interface實現爲語言的interface，分佈式對象環境的interface或其它什麼interface，但就理解UML的interface而言，指的是系統每部分的實現和實現之間，經過interface所肯定的協議來共同工做。
　　因此我認爲，面向interface編程，原意是指面向抽象協議編程，實現者在實現時要嚴格按協議來辦。也就是BillJoy同志說的，一邊翻rfc，一邊寫代碼的意思。面向對象編程是指面向抽象和具象。抽象和具象是矛盾的統一體，不可能只有抽象沒有具象。通常懂得抽象的人都明白這個道理。 但有的人只知具象殊不知抽象爲什麼物。
　　因此只有interface沒有實現，或只有實現而沒有interface者是沒有用的，反OO的。
　　因此仍是老老實實面向對象編程，面向協議編程，或者什麼都不面向，老老實實編程。
　　可是我很討厭討論這樣的術語，不如咱們談談什麼叫面向領導的編程？面向用戶的編程？領導和用戶有時都很BT，咱們就面向BT編程？
選擇Java接口仍是抽象類？
        不少人有過這樣的疑問：爲何有的地方必須使用接口而不是抽象類，而在另外一些地方，又必須使用抽象類而不是接口呢？或者說，在考慮Java類的通常化問題時，不少人會在接口和抽象類之間猶豫不決，甚至隨便選擇一種。
　　實際上接口和抽象類的選擇不是爲所欲爲的。要理解接口和抽象類的選擇原則，有兩個概念很重要：對象的行爲和對象的實現。若是一個實體能夠有多種實現方式，則在設計實體行爲的描述方式時，應當達到這樣一個目標：在使用實體的時候，無需詳細瞭解實體行爲的實現方式。也就是說，要把對象的行爲和對象的實現分離開來。既然Java的接口和抽象類均可以定義不提供具體實現的方法，在分離對象的行爲和對象的實現時，到底應該使用接口仍是使用抽象類呢？
　　在接口和抽象類的選擇上，必須遵照這樣一個原則：行爲模型應該老是經過接口而不是抽象類定義。爲了說明其緣由，下面試着經過抽象類創建行爲模型，看看會出現什麼問題。 
　　假設要爲銷售部門設計一個軟件，這個軟件包含一個「發動機」（Motor）實體。顯然沒法在發動機對象中詳細地描述發動機的方方面面，只能描述某些對當前軟件來講重要的特徵。至於發動機的哪些特徵是重要的，則要與用戶（銷售部門）交流才能肯定。 
　　銷售部門的人要求每個發動機都有一個稱爲馬力的參數。對於他們來講，這是唯一值得關心的參數。基於這一判斷，能夠把發動機的行爲定義爲如下行爲。
　    行爲1：查詢發動機的馬力，發動機將返回一個表示馬力的整數。 
　　雖然如今還不清楚發動機如何取得馬力這個參數，但能夠確定發動機必定支持這個行爲，並且這是全部發動機唯一值得關注的行爲特徵。這個行爲特徵既能夠用接口定義，也能夠用抽象類定義。爲了說明用抽象類定義可能出現的問題，下面用抽象類創建發動機的行爲模型，並用Java方法描述行爲1，代碼以下： 
代碼
public abstract Motor{            
             abstract public int getHorsepower();            
          } 
　　在Motor抽象類的基礎上構造出多種具體實現，例如A型發動機、B型發動機等，再加上系統的其它部分，最後獲得1.0版的軟件並交付使用。一段時間過去了，如今要設計2.0版的軟件。在評估2.0版軟件需求的過程當中，發現一小部分發動機是電池驅動的，而電池須要必定的充電時間。銷售部門的人但願可以經過計算機查閱充電時間。根據這一要求定義一個新的行爲，如圖1所示。 
　　行爲2：查詢電驅動發動機的充電時間，發動機將返回一個表示充電時間的整數。 
　　用Java方法來描述這個行爲，代碼以下： 
代碼
public abstract BatteryPoweredMotor extends Motor{            
            abstract public int getTimeToRecharge();            
          }  
　　在銷售部門的軟件中，電驅動發動機也以類的形式實現，但這些類從BatteryPoweredMotor而不是Motor派生。這些改動加入到2.0版軟件以後，銷售部門很滿意。隨着業務的不斷髮展，不久以後光驅動的發動機出現了。銷售部門要求光驅動發動機須要必定光能才能運轉，光能以流明（Lumen）度量。這個信息對客戶很重要，由於下雨或多雲的天氣裏，某些光驅動發動機可能沒法運轉。銷售部門要求爲軟件增長對光驅動發動機的支持，因此要定義一個新的行爲。
　　行爲3：查詢光驅動發動機可以正常運轉所須要的最小流明數，發動機返回一個整數。 
　　再定義一個抽象類並把行爲3轉換成Java方法，代碼以下： 
代碼
public abstract SolarPoweredMotor extends Motor{            
             abstract public int getLumensToOperate();            
          }
　　如圖1所示，SolarPoweredMotor和BatteryPoweredMotor都從Motor抽象類派生。在整個軟件中，90％以上的代碼以相同的方式對待全部的發動機。偶爾須要檢查一下發動機是光驅動仍是電驅動，使用instanceof實現，代碼以下： 
代碼
        if (instanceof SolarPoweredMotor){...}            
        if (instanceof BatteryPoweredMotor){...}
　　不管是哪一種發動機，馬力這個參數都很重要，因此在全部派生的抽象類（SolarPoweredMotor和BatteryPoweredMotor）中，getHorsepower()方法都有效。
　　如今銷售部門又有了一種新的發動機，它是一種既有電驅動又有光驅動的雙重驅動發動機。光驅動和電驅動的行爲自己沒有變化，但新的發動機同時支持兩種行爲。在考慮如何定義新型的光電驅動發動機時，接口和抽象類的差異開始顯示出來了。新的目標是在增長新型發動機的前提下儘可能少改動代碼。由於與光驅動發動機、電驅動發動機有關的代碼已通過全面的測試，不存在已知的Bug。爲了增長光電驅動發動機，要定義一個新的SolarBatteryPowered抽象類。若是讓SolarBatteryPowered從Motor抽象類派生，SolarBatteryPowered將不支持針對光驅動發動機和電驅動發動機的instanceof操做。也就是說，若是查詢一個光電驅動的發動機是光驅動的，仍是電驅動的，獲得的答案是：都不是。 
　　若是讓SolarBatteryPowered從SolarPoweredMotor（或BatteryPoweredMotor）抽象類派生，相似的問題也會出現，SolarBatteryPowered將不支持針對BatteryPoweredMotor（或SolarPoweredMotor）的instanceof操做。從行爲上看，光電驅動的發動機必須同時從兩個抽象類派生，但Java語言不容許多重繼承。之因此會出現這個問題，根本的緣由在於使用抽象類不只意味着定義特定的行爲，並且意味着定義實現的模式。也就是說，應該定義一個發動機如何得到行爲的模型，而不只僅是聲明發動機具備某一個行爲。
　　若是用接口來創建行爲模型，就能夠避免隱含地規定實現模式。例如，前面的幾個行爲改用接口定義以下。 
行爲1：
代碼
public interface Motor(){            
           public int getHorsepower();            
         } 
行爲2：
代碼            
public interface BatteryPoweredMotor extends Motor(){            
     public int getTimeToRecharge();            
}
行爲3：
代碼          
public interface SolarPoweredMotor extends Motor{            
     abstract public int getLumensToOperate();            
}
　　如今光電驅動的發動機能夠描述爲： 
代碼            
public DualPoweredMotor implements SolarPoweredMotor, BatteryPoweredMotor{}        
　　DualPoweredMotor只繼承行爲定義，而不是行爲的實現模式，如圖2所示。 
　　在使用接口的同時仍舊可使用抽象類，不過這時抽象類的做用是實現行爲，而不是定義行爲。只要實現行爲的類聽從接口定義，即便它改變了父抽象類，也不用改變其它代碼與之交互的方式。特別是對於公用的實現代碼，抽象類有它的優勢。抽象類可以保證明現的層次關係，避免代碼重複。然而，即便在使用抽象類的場合，也不要忽視經過接口定義行爲模型的原則。從實踐的角度來看，若是依賴於抽象類來定義行爲，每每致使過於複雜的繼承關係，而經過接口定義行爲可以更有效地分離行爲與實現，爲代碼的維護和修改帶來方便。

Java接口特性學習 
        在Java中看到接口，第一個想到的可能就是C++中的多重繼承和Java中的另一個關鍵字abstract。從另一個角度實現多重繼承是接口的功能之一，接口的存在可使Java中的對象能夠向上轉型爲多個基類型，而且和抽象類同樣能夠防止他人建立該類的對象，由於接口不容許建立對象。
interface關鍵字用來聲明一個接口，它能夠產生一個徹底抽象的類，而且不提供任何具體實現。interface的特性整理以下：
1. 接口中的方法能夠有參數列表和返回類型，但不能有任何方法體。
2. 接口中能夠包含字段，可是會被隱式的聲明爲static和final。
3. 接口中的字段只是被存儲在該接口的靜態存儲區域內，而不屬於該接口。
4. 接口中的方法能夠被聲明爲public或不聲明，但結果都會按照public類型處理。
5. 當實現一個接口時，須要將被定義的方法聲明爲public類型的，不然爲默認訪問類型，Java編譯器不容許這種狀況。
6. 若是沒有實現接口中全部方法，那麼建立的仍然是一個接口。
7. 擴展一個接口來生成新的接口應使用關鍵字extends，實現一個接口使用implements。
         interface在某些地方和abstract有類似的地方，可是採用哪一種方式來聲明類主要參照如下兩點：
1. 若是要建立不帶任何方法定義和成員變量的基類，那麼就應該選擇接口而不是抽象類。
2. 若是知道某個類應該是基類，那麼第一個選擇的應該是讓它成爲一個接口，只有在必需要有方法定義和成員變量的時候，才應該選擇抽象類。由於抽象類中容許存在一個或多個被具體實現的方法，只要方法沒有被所有實現該類就還是抽象類。

        以上就是接口的基本特性和應用的領域，可是接口毫不僅僅如此，在Java語法結構中，接口能夠被嵌套，既能夠被某個類嵌套，也能夠被接口嵌套。這在實際開發中可能應用的很少，但也是它的特性之一。須要注意的是，在實現某個接口時，並不須要實現嵌套在其內部的任何接口，並且，private接口不能在定義它的類以外被實現。

 

轉載自: http://blog.chinaunix.net/u/25176/showart_429060.html