黑馬程序員—面向接口編程的好處

 

洞悉編程思想是咱們學習語言過程當中的必由之路，但注意對於編程思想的理解必定要創建在大量的代碼實現經驗上，否則只是在口頭空談編程思想而不去編程，根本沒法深刻理解思想的核心。

 

面向對象思想的核心之一，就是模擬真實世界，把真實世界中的事物抽象成類，整個程序靠各個類的實例互相通訊、互相協做完成系統功能，這很是符合真實世界的運行情況，也是面向對象思想的精髓。

例如：接口是一組規則的集合，它規定了實現本接口的類或接口必須擁有的一組規則。在天然界的體現就是「若是你是……則必須能……」的理念。

 

 

面向接口編程

高內聚低耦合

設計模式之開閉原則

 

 

面向接口編程和麪向對象編程是什麼關係 

首先，面向接口編程和麪向對象編程並非平級的，它並非比面向對象編程更先進的一種獨立的編程思想，而是附屬於面向對象思想體系，屬於其一部分。或者說，它是面向對象編程體系中的思想精髓之一。 

 

接口就是標準規範，就是定死了一個框架，你根據這個框架去執行！有了標準去遵照就容易擴展！咱們只須要面向標準編程，而不用針對具體的實現類！

 

 

面向接口編程的好處：

1.更加抽象,更加面向對象

2.提升編程的靈活性

3.實現高內聚、低耦合，提升可維護性，下降系統維護成本。

 

面向接口主要是傳統行業學習，好比建築業，建築業最重要的是圖紙，那就是接口。開發軟件的圖紙就是軟件設計師設計的接口。

 

一個接口能夠從三方面去考察： 

制定者（或者叫協調者），實現者（或者叫生產者），調用者（或者叫消費者）。 

 

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

 

因此一般說的「面向接口編程」能夠理解爲：只有實現者和調用者都遵循「面向接口編程」這個準則，制定者的協調目的才能達到。 

 

 

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

 

不少人費解：既然我每鏈接一種數據庫（如mysql）都要事先部署驅動程序，那我直接訪問驅動程序不就好了？還要JDBC幹嘛？ 

實際上，JDBC已經起了相當重要的做用了：正由於驅動程序是按照JDBC所規定的方法編寫的，你才能夠按照JDBC的方式去使用。 

換句話說，若是驅動程序提供者不按照JDBC標準來編寫，而是按它本身首創的方式編寫，那麼你在使用驅動程序的時候就要花時間查看驅動程序的文檔以搞清楚用法。而當你往後決定使用另外一種數據庫的時候，這種數據庫的驅動程序也不是按照JDBC編寫的，你又得去搞清楚另外一套徹底不一樣的用法，而你的全部代碼都必須作相應的更改。這種代價是不可想象的。 

 

而如今的狀況是，驅動程序提供者都按照JDBC規定的方式來編寫，程序員都按照JDBC規定的方式來使用。程序員不用關心本身正在使用何種數據庫，而驅動程序編寫者也不用費盡心力去編寫接口文檔來向程序員解釋驅動程序的用法，你們都向標準看齊就好了。 

如今，你以爲面向接口（標準）編程的好處還不明顯嗎？ 

 

當你正在你的鍵盤上打字的時候，你是否想到，你在學校就學會了的打字方法至今還在用，由於全部計算機鍵盤的佈局都是同樣的。這時，你會不會由衷地感激這個設計鍵盤佈局的人呢？正是他讓你只要學會一種打字方法就能夠用在全部計算機的鍵盤上。

 

 

這個例子的總結：接口（標準）做爲中間方，做爲制定者，爲實現者與調用者提供統一的行業規範，這樣你們作出來的東西就是按照統一的標準而來，協調了二者之間的關係，消除了二者的不一樣！

 

 

java之因此受歡迎就是得益於它的規範。咱們爲何用struts框架？由於它提供你一個固定的模式給你，你們寫出來的東西都是相似的，好懂！若是用C或C++，10我的可能有10種不一樣的實現和思路，這樣沒人願意花時間去理解別人的代碼！而JAVA的面向接口其實就是讓你們按規範辦事。這在大型項目的開發中是頗有好處的。

 

再好比在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就能夠了，而在已經寫好的代碼中，咱們能夠一行不改的進行了數據庫移植，這個就是面向對象設計原則中的「開-閉原則」（對增長是開放的，對修改是封閉的）。但這只是理論上的，現實中很難作到的。

 

對這個例子的理解：利用面向接口和配置文件進行解耦，加強了系統的靈活性、可維護性，換代碼不換實現，將對項目的影響下降到最小！

 

在現實生活的理解：好比公司裏制定了接口，也就是標準、規範，咱們的工做只須要根據公司的規範進行，而不須要根據具體的不一樣領導者執行；不然的話：不一樣領導者的交替更換，它的要求一直更換，咱們今天習慣了聽這個領導的，明天又來了一個，咱們就要更換思惟：這樣老是更換就相似於實際項目中的混亂問題；因此面向接口是一個很好的解決辦法！咱們不須要具體的聽誰的，只須要遵照事先制定的接口規範就行！

 

總結：接口也就是一種規範！面向接口編程就相似於現實中遵照公司規定同樣！這樣加強了系統的靈活性、可維護性，減少影響！實現項目中常說的：高內聚、低耦合！

 

什麼是高內聚、低耦合？

原由：模塊獨立性指每一個模塊只完成系統要求的獨立子功能，而且與其餘模塊的聯繫最少且接口簡單，兩個定性的度量標準――耦合性和內聚性。

 

內聚性又稱塊內聯繫。指單個模塊的功能強度的度量，即一個模塊內部各個元素彼此結合的緊密程度的度量。若一個模塊內各元素（語名之間、程序段之間）聯繫的越緊密，則它的內聚性就越高。

高內聚就是在一個模塊內，讓每一個元素之間都儘量的緊密相連。也就是充分利用每個元素的功能，各施所能，以最終實現某個功能。若是某個元素與該模塊的關係比較疏鬆的話，可能該模塊的結構還不夠完善，或者是該元素是多餘的。

高內聚關鍵字：最充分的利用模塊中每個元素的功能，達到功能實現最大化，內聚性越強越好，用最小的資源幹最大的事情！

 

耦合性也稱塊間聯繫。指軟件系統結構中各模塊間相互聯繫緊密程度的一種度量。模塊之間聯繫越緊密，其耦合性就越強，模塊的獨立性則越差。模塊間耦合高低取決於模塊間接口的複雜性、調用的方式及傳遞的信息。

低耦合關鍵字：項目中的各個模塊之間的關聯要儘量的小，耦合性（相互間的聯繫）越低越好，減少「牽一髮而動全身」的可能性！

 

耦合性與內聚性是模塊獨立性的兩個定性標準，將軟件系統劃分模塊時，儘可能作到高內聚低耦合，提升模塊的獨立性，爲設計高質量的軟件結構奠基基礎。

 

有個例子很容易明白：一個程序有50個函數，這個程序執行得很是好；然而一旦你修改其中一個函數，其餘49個函數都須要作修改，這就是高耦合的後果。一旦你理解了它，你編寫概要設計的時候設計類或者模塊天然會考慮到「高內聚，低耦合」。

 

高內聚低耦合是軟件設計的一個基本原則，說的是在程序的各個模塊中，儘可能讓每一個模塊獨立，相關的處理儘可能在單個模塊中完成，就是俗話說的：該幹嗎幹嗎去！優勢：能提下降各模塊的之間的聯繫，減小「牽一髮而動全身」的概率，提升開發效率，下降升級維護成本，也便於進行單元測試，提升軟件質量。

 

內聚和耦合，包含了橫向和縱向的關係。功能內聚和數據耦合，是咱們須要達成的目標。橫向的內聚和耦合，一般體如今系統的各個模塊、類之間的關係，而縱向的耦合，體如今系統的各個層次之間的關係。

 

高內聚低耦合也能夠更好的支持代碼的複用，咱們在作項目的時候發現須要的功能以前實現過，那麼直接拿來用就OK，可是須要注意的是這個功能模塊的耦合性必定要低才行，就是最好只拿它一個就能夠來用！

 

設計模式的原則裏的開閉原則，其實就是要使用接口來實現對擴展開放，對修改關閉。

 

 開閉原則是面向對象設計中最基礎的設計原則，它指導咱們如何創建穩定靈活的系統。開閉原則多是設計模式六項原則中定義最模糊的一個了，它只告訴咱們對擴展開放，對修改關閉，但是到底如何才能作到對擴展開放，對修改關閉，並無明確的告訴咱們。之前，若是有人告訴我「你進行設計的時候必定要遵照開閉原則」，我會覺的他什麼都沒說，但貌似又什麼都說了。由於開閉原則真的太虛了。

 

在仔細思考以及仔細閱讀不少設計模式的文章後，終於對開閉原則有了一點認識。其實，咱們遵循設計模式前面5大原則，以及使用23種設計模式的目的就是遵循開閉原則。也就是說，只要咱們對前面5項原則遵照的好了，設計出的軟件天然是符合開閉原則的，這個開閉原則更像是前面五項原則遵照程度的「平均得分」，前面5項原則遵照的好，平均分天然就高，說明軟件設計開閉原則遵照的好；若是前面5項原則遵照的很差，則說明開閉原則遵照的很差。

 

其實筆者認爲，開閉原則無非就是想表達這樣一層意思：用抽象構建框架，用實現擴展細節。由於抽象靈活性好，適應性廣，只要抽象的合理，能夠基本保持軟件架構的穩定。而軟件中易變的細節，咱們用從抽象派生的實現類來進行擴展，當軟件須要發生變化時，咱們只須要根據需求從新派生一個實現類來擴展就能夠了。固然前提是咱們的抽象要合理，要對需求的變動有前瞻性和預見性才行。

 

說到這裏，再回想一下前面說的5項原則，偏偏是告訴咱們用抽象構建框架，用實現擴展細節的注意事項而已：單一職責原則告訴咱們實現類要職責單一；里氏替換原則告訴咱們不要破壞繼承體系；依賴倒置原則告訴咱們要面向接口編程；接口隔離原則告訴咱們在設計接口的時候要精簡單一；迪米特法則告訴咱們要下降耦合。而開閉原則是總綱，他告訴咱們要對擴展開放，對修改關閉。

 

 

備註：別人關於面向接口編程的總結，很不錯！

 

在項目中的意義： 

在傳統的項目開發過程當中，因爲客戶的需求常常變化，若是不採用面向接口編程，那麼咱們必須不停改寫現有的業務代碼。改寫代碼可能產生新的BUG，並且改寫代碼還會影響到調用該業務的類，可能全都須要修改，影響系統自己的穩定性。並且爲了將改寫代碼帶來的影響最小，咱們不得不屈服當前的系統情況來完成設計，代碼質量和穩定性更低。當這種狀況積累到必定程度時，系統就會出現不可預計的錯誤，代碼凌亂，不易讀懂，後接手的人沒法讀懂代碼，系統的維護工做愈來愈重，最終可能致使項目失敗。 

 

接口在項目就是一個業務邏輯，面向接口編程就是先把客戶的業務提取出來，做爲接口。業務具體實現經過該接口的實現類來完成。當客戶需求變化時，只需編寫該業務邏輯的新的實現類，經過更改配置文件(例如Spring框架)中該接口的實現類就能夠完成需求，不須要改寫現有代碼，減小對系統的影響。 

採用基於接口編程的項目，業務邏輯清晰，代碼易懂，方便擴展，可維護性強。即便更換一批人員，新來的人依然能夠快速上手。對於公司來講，意義更大。 

 

在Java語言中的意義： 

Java自己也是一個不斷完善的語言，他也在頻繁的改動他的系統API來完善，他的API是一個龐大的體系，互相關聯，若是不採用接口，而都是用實現類的話，那麼API的改動就會給整個體系帶來不穩定。並且若是改動API，那麼就會有大量採用舊API的項目因沒法正常運行，會損失大量客戶。換句話說，JDK已經發布的API是一種承諾，一經發布就不能更改，即便原來API存在各類各樣的問題（例如java.util.Properties類就是一個失敗的例子）也必須保留，因而在Java裏就出現了不建議使用的方法，但JDK依然提供該方法。並且Java語言自己是一個跨平臺的語言，爲了知足在各個平臺下運行，就必須把各類操做作成接口，在編寫各個平臺下的實現類。 

 

設計模式的體現： 

在設計模式的原則裏的開閉原則，其實就是要使用接口來實現對擴展開放，對修改關閉。在設計模式的其餘原則裏也有關於基於接口編程的原則，即依賴倒轉的設計原則(DIP)----高層模塊不該該依賴於底層模塊。兩者都應該依賴於抽象；抽象不該該依賴於細節，細節應該依賴於抽象(注：來自《敏捷軟件開發--原則、模式與實踐》Robert C.Martin著)。在使用面向接口的編程過程當中，將具體邏輯與實現分開，減小了各個類之間的相互依賴，當各個類變化時，不須要對已經編寫的系統進行改動，添加新的實現類就能夠了，再也不擔憂新改動的類對系統的其餘模塊形成影響。 

編程也是一門藝術，在C語言中靈活的使用指針是一門藝術，在面對對象的程序中，靈活的使用接口也是一門藝術。如今項目中，功能愈來愈複雜，只設計了完美的類，對於整個系統來講沒有多大意義，如今的項目更注重各個功能模塊的整合及可維護性，接口的設計就顯得更爲重要了。程序設計再也不是設計類的具體實現，而是從整個項目出發，設計出可擴展性強的接口。當你發現愈來愈靈活的使用接口時，那麼你就從程序員升級爲架構師了。

 

 

參考網頁地址：

http://bbs.csdn.net/topics/200039218

http://blog.csdn.net/zhengzhb/article/details/7296944

 

隨感：最近在瞭解Android的過程當中，發現了大批的牛人：有才華，有品格，更讓我堅決有品格的汗水比天賦更值得尊重的理解！

任何一個行業想要成爲卓越的人才，都必須具有很強的精神品格，老是淺嘗輒止，懂點皮毛，這樣只能體現我的品格的膚淺與技術的底下！

還記得高三班主任說過的：先作人，後作事！老老實實作人，踏踏實實作事！當時不屑於顧，認爲這兩點沒有什麼聯繫。可是如今想來，先作人就是把作事須要的品格等培養出來，後作事就水到渠成，如虎添翼！

許多人在先作人（無貶義）上根本沒下功夫，沒有經受任何的磨練，匆匆開始作事！結果在任何事情上都是三分鐘熱度，根本沒有一點堅持精神！你作一件事情失敗，作兩件事情失敗，作三件事情失敗，你能夠不反思，能夠歸咎於運氣很差！但作十件事情失敗的時候你就要想：其實你作任何事情都註定失敗，由於你根本沒有作事情所須要的品格做爲前提保證！

天外有天，人外有人！你該用品格去砸開將來的大門！