一篇非常經典的文章（面向接口程式設計）

面向對象設計裡有一點大家已基本形成共識，就是面向接口程式設計，我想大多數人對這個是沒有什麼覺得需要懷疑的。      問題是在實際的項目開發中我們是怎麼展現的呢？ 難道就是每一個實作都提供一個接口就了事了？反過來說，你有時候有沒有覺得接口是多餘的事？ 又或者，你僅僅是覺得現在類似spring這樣的架構已習慣用接口這種方式而心存當然。      設計模式解析裡提到了面向對象設計考慮的幾個視角，一個是概念層，一個是規約層，一個是實作層。我如果沒有猜錯的話，實際上我們大多數人的眼睛一直是盯着實作層的，而這正是面向對象設計所極力避免的，即你不要在一開始就關注這些細節，你要關注的是規約（接口）.       對于實際項目開發來說，如果我們把實作的過程分為多個階段的話我們不妨這麼劃分，第一階段，根據client端的需要去設計我們的規約(interface),在這個階段任何實作都沒有，所有的任務就是定義接口所需要的職責，以及所需要的一些po,vo;第二階段，實作前面定義的規約. 以前我是怎麼做的呢？ 我是交叉作的，即假模假樣的定義一個接口（其實我心裡在想這個東西有屁用）,然後定義了一個方法，然後就立即去實作這個方法，再然後我又定義一個方法，繼續去實作，我現在終于想通了，這樣好累，效率很低，最重要的是，這不屬于真正的設計。       現在我是怎麼做的呢？比如一個list.jsp裡需要查詢，清單，然後看明細資訊，然後增加資訊，我會第一步在接口裡定義完(這個過程會有整體設計的意識),毫不關心底層實作(資料庫、事務)，我的目标就是"我想要這個功能，我想要那個功能"，至于那個功能怎麼實作在第一階段我認為那不是我的事情(盡管這個事情最終還是由我來做) .大家看這個過程和前面的過程有什麼本質的不同呢？ 就是分層的概念更加明顯，你的工作更有層次，每次都有先設計再實作的步驟，而前面那個過程很容易就讓你不知不覺地陷入純實作的陷阱中。 什麼叫面向接口程式設計 2007/09/13 08:48 在一個面向對象的系統中，系統的各種功能是由許許多多的不同對象協作完成的。在這種情況下，各個對象内部是如何實作自己的對系統設計人員來講就不那麼重要了；而各個對象之間的協作關系則成為系統設計的關鍵。小到不同類之間的通信，大到各子產品之間的互動，在系統設計之初都是要着重考慮的，這也是系統設計的主要工作内容。面向接口程式設計我想就是指按照這種思想來程式設計吧！實際上，在日常工作中，你已經按照接口程式設計了，隻不過如果你沒有這方面的意識，那麼你隻是在被動的實作這一思想；表現在頻繁的抱怨别人改的代碼影響了你（接口沒有設計到），表現在某個子產品的改動引起其他子產品的大規模調整（子產品接口沒有很好的設計）等等。 　　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接口不能在定義它的類之外被實作。