高內聚，低耦合

 

    目前已經有大量的框架幫助我們降低我們系統的耦合度。比如，使用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提供數據（如圖B）。經過這樣的調整，系統的耦合度就降低了。 


3）   使用接口而不是繼承 

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

    總之，“低耦合”給軟件項目帶來的優點是：易於變更、易於重用。 
    耦合：一個軟件結構內不同模塊之間互連程度的度量(耦合性也叫塊間聯系。指軟件系統結構中各模塊間相互聯系緊密程度的一種度量。模塊之間聯系越緊密，其耦合性就越強，模塊的獨立性則越差，模塊間耦合的高低取決於模塊間接口的復雜性，調用的方式以及傳遞的信息。) 對於低耦合，粗淺的理解是：一個完整的系統，模塊與模塊之間，盡可能的使其獨立存在。

 

 高內聚（High Cohesion） 
    高內聚是另一個普遍用來評判軟件設計質量的標准。內聚，更為專業的說法叫功能內聚，是對軟件系統中元素職責相關性和集中度的度量。如果元素具有高度相關的職責，除了這些職責內的任務，沒有其它過多的工作，那么該元素就具有高內聚性，反之則為低內聚性。高內聚要求軟件系統中的各個元素具有較高的協作性，因為在我們在完成軟件需求中的一個功能，可能需要做各種事情，但是具有高內聚性的一個元素，只完成它職責內的事情，而把那些不在它職責內的事情拿去請求別人來完成。這就好像，如果我是一個項目經理，我的職責是監控和協調我的項目各個階段的工作。當我的項目進入需求分析階段，我會請求需求分析員來完成；當我的項目進入開發階段，我會請求軟件開發人員來完成；當我的項目需要測試的時候，我會請求測試人員。。。。。。如果我參與了開發，我就不是一個高內聚的元素，因為開發不是我的職責。我們的項目為什么要高內聚呢？我覺得可以從可讀性、復用性、可維護性和易變更性四個方面來理解。 

1．可讀性 

一個人寫文章、講事情，條理清晰才能易於理解，這同樣發生在讀寫軟件代碼上。如果一堆代碼寫得一團亂麻，東一個跳轉西一個調用，讀它的人會感覺非常頭疼。這種事情也許一直在寫程序的你我都曾經有過經歷。如果一段程序條理非常清晰，每個類通過名稱或說明都能清楚明白它的意義，類的每個屬性、函數也都是易於理解的它所應當完成的任務和行為，這段程序的可讀性必然提高。在軟件產業越來越密集，軟件產業中開發人員協作越來越緊密、分工越來越細的今天，軟件可讀性的要求相信也越來越為人們所重視。 

2．復用性 

在軟件開發中，最低等級的復用是代碼拷貝，然后是函數的復用、對象的復用、組件的復用。軟件開發中最懶的人是最聰明的人，他們總是想到復用。在代碼編寫的時候突然發現某個功能是曾經實現過的功能，直接把它拷貝過來就ok了。如果這段代碼在同一個對象中，那么就提出來寫一個函數到處調用就行了。如果不是在同一個對象中呢，就將其抽象成一個對象到處調用吧。如果不在一個項目中呢，那就做成組件給各個項目引用吧。代碼復用也使我們的代碼在復用的過程中不斷精化、不斷健壯、提高代碼質量。代碼的復用的確給我們的開發帶來了不少便利，但是一段代碼能否在各個需要的地方都能復用呢？這給我們的軟件開發質量提出了新的要求：好的代碼可以復用，不好的則不行。軟件中的一個對象如果能保證能完成自己職能范圍內的各項任務，同時又不去理會與自己職能無關的其它任務，那么它就能夠保證功能的相對獨立性，也就可以脫離自己所處的環境而復用到其它環境中，這是一個具有內聚性的對象。