（原創）一個優秀軟件開發人員的必修課：GRASP（3）高內聚
關鍵字: 高內聚 java 軟件工程 軟件模式2.高內聚（High Cohesion）
高內聚是另一個普遍用來評判軟件設計質量的標準。內聚，更爲專業的說法叫功能內聚，是對軟件系統中元素職責相關性和集中度的度量。如果元素具有高度相關的職責，除了這些職責內的任務，沒有其它過多的工作，那麼該元素就具有高內聚性，反之則爲低內聚性。高內聚要求軟件系統中的各個元素具有較高的協作性，因爲在我們在完成軟件需求中的一個功能，可能需要做各種事情，但是具有高內聚性的一個元素，只完成它職責內的事情，而把那些不在它職責內的事情拿去請求別人來完成。這就好像，如果我是一個項目經理，我的職責是監控和協調我的項目各個階段的工作。當我的項目進入需求分析階段，我會請求需求分析員來完成；當我的項目進入開發階段，我會請求軟件開發人員來完成；當我的項目需要測試的時候，我會請求測試人員。。。。。。如果我參與了開發，我就不是一個高內聚的元素，因爲開發不是我的職責。
我們的項目爲什麼要高內聚呢？我覺得可以從可讀性、複用性、可維護性和易變更性四個方面來理解。
1．可讀性
一個人寫文章、講事情，條理清晰才能易於理解，這同樣發生在讀寫軟件代碼上。如果一堆代碼寫得一團亂麻，東一個跳轉西一個調用，讀它的人會感覺非常頭疼。這種事情也許一直在寫程序的你我都曾經有過經歷。如果一段程序條理非常清晰，每個類通過名稱或說明都能清楚明白它的意義，類的每個屬性、函數也都是易於理解的它所應當完成的任務和行爲，這段程序的可讀性必然提高。在軟件產業越來越密集，軟件產業中開發人員協作越來越緊密、分工越來越細的今天，軟件可讀性的要求相信也越來越爲人們所重視。
2．複用性
在軟件開發中，最低等級的複用是代碼拷貝，然後是函數的複用、對象的複用、組件的複用。軟件開發中最懶的人是最聰明的人，他們總是想到複用。在代碼編寫的時候突然發現某個功能是曾經實現過的功能，直接把它拷貝過來就ok了。如果這段代碼在同一個對象中，那麼就提出來寫一個函數到處調用就行了。如果不是在同一個對象中呢，就將其抽象成一個對象到處調用吧。如果不在一個項目中呢，那就做成組件給各個項目引用吧。代碼複用也使我們的代碼在複用的過程中不斷精化、不斷健壯、提高代碼質量。代碼的複用的確給我們的開發帶來了不少便利，但是一段代碼能否在各個需要的地方都能複用呢？這給我們的軟件開發質量提出了新的要求：好的代碼可以複用，不好的則不行。軟件中的一個對象如果能保證能完成自己職能範圍內的各項任務，同時又不去理會與自己職能無關的其它任務，那麼它就能夠保證功能的相對獨立性，也就可以脫離自己所處的環境而複用到其它環境中，這是一個具有內聚性的對象。
3．可維護性和易變更性
在前面《如何在struts+spring+hibernate的框架下構建低耦合高內聚的軟件》中我提到，我們現在的軟件是在不斷變更的，這種變更不僅來自於我們的客戶，更來自於我們的市場。如果我們的軟件通過變更能及時適應我們的市場需求，我們就可以在市場競爭中獲勝。如何能及時變更以適應我們的市場呢，就是通過調整軟件的結構，使我們每次的變更付出的代價最小，耗費的人力最小，這種變更才最快最經濟。高內聚的軟件，每個系統、模塊、類的任務都高度相關，就使每一次的變更涉及的範圍縮小到最小。比如評審表發生了變更，只會與評審表對象有關，我們不會去更改其它的對象。如果我們能做到這一點，我們的系統當然是可維護性好、易變更性好的系統。那麼，我們如何做到高內聚呢？就拿前面我提到的評審項目舉例。我現在要爲“評審表”對象編寫一段填寫並保存評審表的代碼。評審表對象的職責是更新和查詢評審表的數據，但是在顯示一個要填寫的評審表的時候，我需要顯示該評審計劃的名稱、該評審計劃有哪些評審對象需要評審。現在我如何編寫顯示一個要填寫的評審表的代碼？我在評審表對象的這個相應的函數中編寫一段查詢評審計劃和評審對象的代碼嗎？假如你這樣做了，你的代碼就不是高內聚的，因爲查詢評審計劃和評審對象的數據不是它的職責。正確的方法應當去請求“評審計劃”對象和“評審對象”對象來完成這些工作，而“評審表”對象只是獲取其結果。
另外，如果一個對象要完成一個雖然在自己職責範圍內，但過程非常複雜的任務時，也應當將該任務分解成數個功能相對獨立的子函數來完成。我曾經看見一個朋友寫的數百行的一個函數，讓人讀起來非常費勁。同時這樣的函數中一些相對獨立的代碼，本可以複用到其它代碼中，也變成了不可能。所以我給大家的建議是，不要寫太長的函數，超過一百行就可以考慮將一些功能分解出去。
與“低耦合”一樣，高內聚也不是一個絕對，而是一個相對的指標，應當適當而不能過度。正如我們在現實生活中，如果在一個十來人的小公司，每個人的分工可能會粗一些，所分配的職責會廣一些雜一些，因爲其總體的任務少；而如果在一個一兩百人的大公司，每個人的分工會細一些，所分配的任務會更加專一些，因爲總體任務多，更需要專業化的分工來提高效率。軟件開發也是一樣，如果“評審計劃”對象完成的業務功能少，並且不復雜，它完全可以代理它的子表“評審對象”和“評審者”的管理。但是“評審計劃”對象需要完成的“對評審計劃表的管理”這個基本職責包含的業務功能繁多或者複雜，它就應當將“對評審對象表的管理”交給“評審對象”對象，將“對評審者表的管理”交給“評審者”對象。同樣，高內聚的可維護性好、易變更性好只能是一個相對的指標。如果一個變更的確是大範圍的變更，你永遠不可能通過內聚就不進行大範圍的變更了。同時內聚也是要付出代價的，所以你也不必要去爲了一個不太可能的變更去進行過度設計，應當掌握一個度。過度的內聚必將增加系統中元素之間的依賴，提高耦合度。所以“高內聚”與“低耦合”是矛盾的，必須權衡利弊，綜合地去處理。在李洋等人翻譯的《UML和模式應用》中，將內聚和耦合翻譯爲軟件工程中的陰與陽，是中國人對內聚和耦合的最佳解釋。
綜上所述，“高內聚”給軟件項目帶來的優點是：可讀性強、易維護和變更、支持低耦合、移植和重用性強。