（原創）一個優秀軟件開發人員的必修課：GRASP（2）低耦合

（原創）一個優秀軟件開發人員的必修課：GRASP（2）低耦合

我偶然在google或yahoo這樣的搜索引擎搜索GRASP發現，除了國外的網站，國內網站多介紹和討論GoF而很少介紹GRASP，即使這少量的文章也講解非常粗略。個人認爲作爲優秀的開發人員，理解GRASP比GoF更重要，故寫此文章。前面我在《（原創）一個優秀軟件開發人員的必修課：GRASP軟件開發模式淺析》中介紹了使用GRASP的目的，今天允許我調換一下順序，先從低耦合講起，因爲諸如創建者模式、信息專家模式的根本目的就是降低耦合。

1.低耦合（Low Coupling）

“低耦合”這個詞相信大家已經耳熟能詳，我們在看spring的書籍、MVC的數據、設計模式的書籍，無處不提到“低耦合、高內聚”，它已經成爲軟件設計質量的標準之一。那麼什麼是低耦合？耦合就是對某元素與其它元素之間的連接、感知和依賴的量度。這裏所說的元素，即可以是功能、對象（類），也可以指系統、子系統、模塊。假如一個元素A去連接元素B，或者通過自己的方法可以感知B，或者當B不存在的時候就不能正常工作，那麼就說元素A與元素B耦合。耦合帶來的問題是，當元素B發生變更或不存在時，都將影響元素A的正常工作，影響系統的可維護性和易變更性。同時元素A只能工作於元素B存在的環境中，這也降低了元素A的可複用性。正因爲耦合的種種弊端，我們在軟件設計的時候努力追求“低耦合”。低耦合就是要求在我們的軟件系統中，某元素不要過度依賴於其它元素。請注意這裏的“過度”二字。系統中低耦合不能過度，比如說我們設計一個類可以不與JDK耦合，這可能嗎？除非你不是設計的Java程序。再比如我設計了一個類，它不與我的系統中的任何類發生耦合。如果有這樣一個類，那麼它必然是低內聚（關於內聚的問題我隨後討論）。耦合與內聚常常是一個矛盾的兩個方面。最佳的方案就是尋找一個合適的中間點。

哪些是耦合呢？

1．元素B是元素A的屬性，或者元素A引用了元素B的實例（這包括元素A調用的某個方法，其參數中包含元素B）。

2．元素A調用了元素B的方法。

3．元素A直接或間接成爲元素B的子類。

4．元素A是接口B的實現。

幸運的是，目前已經有大量的框架幫助我們降低我們系統的耦合度。比如，使用struts我們可以應用MVC模型，使頁面展現與業務邏輯分離，做到了頁面展現與業務邏輯的低耦合。當我們的頁面展現需要變更時，我們只需要修改我們的頁面，而不影響我們的業務邏輯；同樣，我們的業務邏輯需要變更的時候，我們只需要修改我們的java程序，與我們的頁面無關。使用spring我們運用IoC（反向控制），降低了業務邏輯中各個類的相互依賴。假如類A因爲需要功能F而調用類B，在通常的情況下類A需要引用類B，因而類A就依賴於類B了，也就是說當類B不存在的時候類A就無法使用了。使用了IoC，類A調用的僅僅是實現了功能F的接口的某個類，這個類可能是類B，也可能是另一個類C，由spring的配置文件來決定。這樣，類A就不再依賴於類B了，耦合度降低，重用性提高了。使用hibernate則是使我們的業務邏輯與數據持久化分離，也就是與將數據存儲到數據庫的操作分離。我們在業務邏輯中只需要將數據放到值對象中，然後交給hibernate，或者從hibernate那裏得到值對象。至於用Oracle、MySQL還是SQL Server，如何執行的操作，與我無關。

但是，作爲優秀的開發人員，僅僅依靠框架提供的降低軟件耦合的方法是遠遠不夠的。根據我的經驗，以下一些問題我們應當引起注意：

1）根據可能的變化設計軟件

我們採用職責驅動設計，設計中盡力做到“低耦合、高內聚”的一個非常重要的前提是，我們的軟件是在不斷變化的。如果沒有變化我們當然就不用這麼費勁了；但是如果有變化，我們希望通過以上的設計，使我們在適應或者更改這樣的變化的時候，付出更小的代價。這裏提供了一個非常重要的信息是，我們努力降低耦合的是那些可能發生變更的地方，因爲降低耦合是有代價的，是以增加資源耗費和代碼複雜度爲代價的。如果系統中某些元素不太可能變更，或者降低耦合所付出的代價太大，我們當然就應當選擇耦合。有一次我試圖將我的表現層不依賴於struts，但發現這樣的嘗試代價太大而失去意義了。對於軟件可能變更的部分，我們應當努力去降低耦合，這就給我們提出一個要求是，在軟件設計的時候可以預判日後的變化。根據以往的經驗我認爲，一個軟件的業務邏輯和採用的技術框架往往是容易變化的2個方面。客戶需求變更是我們軟件設計必須考慮的問題。在RUP的開發過程中，爲什麼需要將分析設計的過程分爲分析模型和設計模型，愚以爲，從分析模型到設計模型的過程實際上是系統從滿足直接的客戶需求到優化系統結構、適應可預見的客戶需求變更的一個過程。這種客戶需求的變更不僅僅指對一個客戶需求的變更，更是指我們的軟件從適應一個客戶需求到適應更多客戶需求的過程。另一個方面，現在技術變更之快，EJB、hibernate、spring、ajax，一個一個的技術像走馬燈一樣從我們腦海中滑過，我們真不知道明天我在用什麼。在這樣的情況下，適應變化就是我們最佳的選擇。

2）合理的職責劃分

合理的職責劃分，讓系統中的對象各司其職，不僅是提高內聚的要求，同時也可以有效地降低耦合。比如評審計劃BUS、評審表BUS、評審報告BUS都需要通過評審計劃DAO去查詢一些評審計劃的數據，如果它們都去直接調用評審計劃DAO（如圖A），則評審計劃BUS、評審表BUS、評審報告BUS三個對象都與評審計劃DAO耦合，評審計劃DAO一旦變更將與這三個對象都有關。在這個實例中，實際上評審計劃BUS是信息專家（關於信息專家模式我將在後面討論），評審表BUS和評審報告BUS如果需要獲得評審計劃的數據，應當向評審計劃BUS提出需求，由評審計劃BUS提供數據。經過這樣的調整，系統的耦合度就降低了。

3）使用接口而不是繼承

通過對耦合的分析，我們不難發現，繼承就是一種耦合。如果子類A繼承了父類B，不論是直接或間接的繼承，子類A都必將依賴父類B。子類A必須使用在存在父類B的環境中，父類B不存在子類A就不能使用，這樣將影響子類A的可移植性。一旦父類B發生任何變更，更改或去掉一個函數名，或者改變一個函數的參數，都將導致子類A不得不變更，甚至重寫。假如父類B的子類數十上百個，甚至貫穿這個項目各個模塊，這樣的變更是災難性的。這種情況最典型的例子是我們現在使用hibernate和spring設計DAO對象的方式，具體的描述參見我寫的《如何在struts + spring + hibernate的框架下構建低耦合高內聚的軟件結構》一文。

總之，“低耦合”給軟件項目帶來的優點是：易於變更、易於重用。

• 大小: 21.4 KB