空間站

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

 

我們的項目為什么要高內聚呢？我覺得可以從可讀性、復用性、可維護性和易變更性四個方面來理解。

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

2在軟件開發中，最低等級的復用是代碼拷貝，然后是函數的復用、對象的復用、組件的復用。軟件開發中最懶的人是最聰明的人，他們總是想到復用。在代碼編寫的時候突然發現某個功能是曾經實現過的功能，直接把它拷貝過來就ok在前面《如何在struts+spring+hibernate的框架下構建低耦合高內聚的軟件》中我提到，我們現在的軟件是在不斷變更的，這種變更不僅來自于我們的客戶，更來自于我們的市場。如果我們的軟件通過變更能及時適應我們的市場需求，我們就可以在市場競爭中獲勝。如何能及時變更以適應我們的市場呢，就是通過調整軟件的結構，使我們每次的變更付出的代價最小，耗費的人力最小，這種變更才最快最經濟。高內聚的軟件，每個系統、模塊、類的任務都高度相關，就使每一次的變更涉及的范圍縮小到最小。比如評審表發生了變更，只會與評審表對象有關，我們不會去更改其它的對象。如果我們能做到這一點，我們的系統當然是可維護性好、易變更性好的系統。

那么，我們如何做到高內聚呢？就拿前面我提到的評審項目舉例。我現在要為“評審表”對象編寫一段填寫并保存評審表的代碼。評審表對象的職責是更新和查詢評審表的數據，但是在顯示一個要填寫的評審表的時候，我需要顯示該評審計劃的名稱、該評審計劃有哪些評審對象需要評審?，F在我如何編寫顯示一個要填寫的評審表的代碼？我在評審表對象的這個相應的函數中編寫一段查詢評審計劃和評審對象的代碼嗎？假如你這樣做了，你的代碼就不是高內聚的，因為查詢評審計劃和評審對象的數據不是它的職責。正確的方法應當去請求“評審計劃”對象和“評審對象”對象來完成這些工作，而“評審表”對象只是獲取其結果。

另外，如果一個對象要完成一個雖然在自己職責范圍內，但過程非常復雜的任務時，也應當將該任務分解成數個功能相對獨立的子函數來完成。我曾經看見一個朋友寫的數百行的一個函數，讓人讀起來非常費勁。同時這樣的函數中一些相對獨立的代碼，本可以復用到其它代碼中，也變成了不可能。所以我給大家的建議是，不要寫太長的函數，超過一百行就可以考慮將一些功能分解出去。

與“低耦合”一樣，高內聚也不是一個絕對，而是一個相對的指標，應當適當而不能過度。正如我們在現實生活中，如果在一個十來人的小公司，每個人的分工可能會粗一些，所分配的職責會廣一些雜一些，因為其總體的任務少；而如果在一個一兩百人的大公司，每個人的分工會細一些，所分配的任務會更加專一些，因為總體任務多，更需要專業化的分工來提高效率。軟件開發也是一樣，如果“評審計劃”對象完成的業務功能少，并且不復雜，它完全可以代理它的子表“評審對象”和“評審者”的管理。但是“評審計劃”對象需要完成的“對評審計劃表的管理”這個基本職責包含的業務功能繁多或者復雜，它就應當將“對評審對象表的管理”交給“評審對象”對象，將“對評審者表的管理”交給“評審者”對象。同樣，高內聚的可維護性好、易變更性好只能是一個相對的指標。如果一個變更的確是大范圍的變更，你永遠不可能通過內聚就不進行大范圍的變更了。同時內聚也是要付出代價的，所以你也不必要去為了一個不太可能的變更去進行過度設計，應當掌握一個度。過度的內聚必將增加系統中元素之間的依賴，提高耦合度。所以“高內聚”與“低耦合”是矛盾的，必須權衡利弊，綜合地去處理。綜上所述，“高內聚”給軟件項目帶來的優點是：可讀性強、易維護和變更、支持低耦合、移植和重用性強。

當我們分析清楚客戶需求設計出用例模型以后，當我們分析清楚客戶的業務環境制作出領域模型以后，當我們綜合用例模型、領域模型和我們的聰明才智設計出一個又一個的類和它們各自的方法以后，當就在一切都準備就緒只欠東風的關鍵時刻，一個對象發出了撕心裂肺的怒吼——誰來創建我？！?。∫粋€對象，不管擁有多么強大的功能，不管進行了多么精巧的設計，如果不能被創建，就如同韓信不能做將軍，孫臏不能當軍師，勾踐不能回越國，劉備不能得荊州，一切一切的雄才武略都如廢紙一張。既然“創建”對于對象如此重要，我們就來好好探討一下GRASP3.           當我們完成了用例模型、領域模型、對象分析的設計，初步完成了對象設計和職責分配的工作，開始進一步細化的時候，一個我們不得不考慮的問題就擺在我們的面前——誰來創建這些對象？也許現在的你會覺得好笑，這也是問題嗎？在軟件實際開發過程中，誰需要使用某個對象，就去創建它就行了，有什么好討論的。但是，我不得不說的是，如果你只是漫不經心地想要隨意開發一套軟件系統，僅僅是完成自己工作而已，你完全不用考慮創建對象的問題。然而如果你希望開發一套高質量的、低耦合的、封裝性和復用性高的軟件系統，你必須得認真考慮這個問題。為什么呢？因為系統中如果一個對象A那么為了降低系統耦合，提高系統的清晰度、封裝性和可復用性，應該有一些通用的原則，以用于對象職責分配中，關于“創建對象”這類職責的分配。這些原則的描述就在GRASP1）   創建者模式的描述

如果以下條件之一為真（越多越好），則將創建類A如果有以上多個選項適用，通常首先條件1

2）   何時使用

在理解創建者模式的時候，我認為一個首先必須理解的問題是，在軟件項目的整個過程中，它應該是在什么階段使用。一個網友曾經發帖問我，他不清楚GRASP3）   為什么

我們做事往往有個習慣，凡事問個為什么。前面我提到，使用創建者模式的主要目的是可以降低系統的耦合。那么，我們在使用創建者模式的這幾個建議的時候是如何降低耦合的呢？這一直是困擾了我很久的一個疑問，Craig Larman創建者模式告訴我們，如果系統中存在包含者容納被包含者，或整體聚集部分，則包含者往往是被包含者的最佳創建者，整體往往是部分的最佳創建者。為什么呢？首先，這樣的設計易于理解，可讀性強。為什么這么說呢，我們用我們常見的單據與單據明細來說明吧。一張單據有多條單據明細，這些單據明細聚集于單據中，是單據的一個部分。對于某張單據，我們只有去填寫這張單據，才會去填寫它的明細。同樣，我們要查看和修改這張單據的明細，首先肯定是找到這張單據。以上這些是我們在實際生活中大家都認同的管理單據的方式。GRASP盡管包含者往往是被包含者的最佳創建者，整體往往是部分的最佳創建者，但是在一個軟件系統中，并不是所有類都有它的包含者或者整體。如果沒有，誰應當創建它呢？記錄者當然是另一個可以考慮的人選。倉庫管理員管理進出庫是ERP如果我們正在設計的軟件類也沒有記錄者，這可如何是好？具有創建這個類所需數據的那個類可以考慮，那個類就是信息專家（什么是“信息專家”，我會在以后對信息專家模式的文章中詳細描述）。在我們的設計過程中，很多類的創建是需要一些初始化數據的。最典型的就是我們的vo如果以上方法還不行，那我們就只有找使用者了。尋找使用者是我們創建類最常用的一種方法，但它的缺點也非常明顯。正如前面我描述的，我們系統中對某個軟件類的使用可能分布到系統的各個角落。當我們因為某個需求需要修改這個類的時候，我們根本不知道誰在使用它。正因為如此，這樣的修改變得如夢魘一般，不斷地搜索，不斷地修改。我們前面說過，合理的軟件構造是為了使我們的變更代價最小，而這樣的變更將使我們的代價太大了，也許一個不經意的變更錯誤將造成我們的系統中一個意想不到的地方發生異常。故我們變更后測試的代價也就因此而增大?？傊?，尋找使用者作為創建者是我們業務分析階段最后的終極選擇。

4）   創建者模式是原則，不是準則

“創建者模式是原則，不是準則”難道“原則”和“準則”還有不同嗎？當然。創建者模式是原則，所以我們在業務分析階段應當盡量遵守。但創建者模式不是準則，因為并非我們的所有軟件類都必須遵守。為什么這么說呢？隨著項目的進行，我們的分析設計就不再停留在業務的分析上，各種具體的框架和技術將不斷引進項目中，這時對象的創建就不一定符合創建者模式。比如，為了提高系統的性能和可維護性、更好地處理對象的創建與回收等復雜的問題，我們常常把對象的創建交給工廠，如spring

總之，合理地創建對象可以有效的提供可讀性、降低耦合度、提高系統的封裝性和可移植性，我們應當引起重視。