空間站

2.           高內(nèi)聚是另一個(gè)普遍用來評判軟件設(shè)計(jì)質(zhì)量的標(biāo)準(zhǔn)。內(nèi)聚，更為專業(yè)的說法叫功能內(nèi)聚，是對軟件系統(tǒng)中元素職責(zé)相關(guān)性和集中度的度量。如果元素具有高度相關(guān)的職責(zé)，除了這些職責(zé)內(nèi)的任務(wù)，沒有其它過多的工作，那么該元素就具有高內(nèi)聚性，反之則為低內(nèi)聚性。高內(nèi)聚要求軟件系統(tǒng)中的各個(gè)元素具有較高的協(xié)作性，因?yàn)樵谖覀冊谕瓿绍浖枨笾械囊粋€(gè)功能，可能需要做各種事情，但是具有高內(nèi)聚性的一個(gè)元素，只完成它職責(zé)內(nèi)的事情，而把那些不在它職責(zé)內(nèi)的事情拿去請求別人來完成。這就好像，如果我是一個(gè)項(xiàng)目經(jīng)理，我的職責(zé)是監(jiān)控和協(xié)調(diào)我的項(xiàng)目各個(gè)階段的工作。當(dāng)我的項(xiàng)目進(jìn)入需求分析階段，我會(huì)請求需求分析員來完成；當(dāng)我的項(xiàng)目進(jìn)入開發(fā)階段，我會(huì)請求軟件開發(fā)人員來完成；當(dāng)我的項(xiàng)目需要測試的時(shí)候，我會(huì)請求測試人員。。。。。。如果我參與了開發(fā)，我就不是一個(gè)高內(nèi)聚的元素，因?yàn)殚_發(fā)不是我的職責(zé)。

 

我們的項(xiàng)目為什么要高內(nèi)聚呢？我覺得可以從可讀性、復(fù)用性、可維護(hù)性和易變更性四個(gè)方面來理解。

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

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

那么，我們?nèi)绾巫龅礁邇?nèi)聚呢？就拿前面我提到的評審項(xiàng)目舉例。我現(xiàn)在要為“評審表”對象編寫一段填寫并保存評審表的代碼。評審表對象的職責(zé)是更新和查詢評審表的數(shù)據(jù)，但是在顯示一個(gè)要填寫的評審表的時(shí)候，我需要顯示該評審計(jì)劃的名稱、該評審計(jì)劃有哪些評審對象需要評審。現(xiàn)在我如何編寫顯示一個(gè)要填寫的評審表的代碼？我在評審表對象的這個(gè)相應(yīng)的函數(shù)中編寫一段查詢評審計(jì)劃和評審對象的代碼嗎？假如你這樣做了，你的代碼就不是高內(nèi)聚的，因?yàn)椴樵冊u審計(jì)劃和評審對象的數(shù)據(jù)不是它的職責(zé)。正確的方法應(yīng)當(dāng)去請求“評審計(jì)劃”對象和“評審對象”對象來完成這些工作，而“評審表”對象只是獲取其結(jié)果。

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

與“低耦合”一樣，高內(nèi)聚也不是一個(gè)絕對，而是一個(gè)相對的指標(biāo)，應(yīng)當(dāng)適當(dāng)而不能過度。正如我們在現(xiàn)實(shí)生活中，如果在一個(gè)十來人的小公司，每個(gè)人的分工可能會(huì)粗一些，所分配的職責(zé)會(huì)廣一些雜一些，因?yàn)槠淇傮w的任務(wù)少；而如果在一個(gè)一兩百人的大公司，每個(gè)人的分工會(huì)細(xì)一些，所分配的任務(wù)會(huì)更加專一些，因?yàn)榭傮w任務(wù)多，更需要專業(yè)化的分工來提高效率。軟件開發(fā)也是一樣，如果“評審計(jì)劃”對象完成的業(yè)務(wù)功能少，并且不復(fù)雜，它完全可以代理它的子表“評審對象”和“評審者”的管理。但是“評審計(jì)劃”對象需要完成的“對評審計(jì)劃表的管理”這個(gè)基本職責(zé)包含的業(yè)務(wù)功能繁多或者復(fù)雜，它就應(yīng)當(dāng)將“對評審對象表的管理”交給“評審對象”對象，將“對評審者表的管理”交給“評審者”對象。同樣，高內(nèi)聚的可維護(hù)性好、易變更性好只能是一個(gè)相對的指標(biāo)。如果一個(gè)變更的確是大范圍的變更，你永遠(yuǎn)不可能通過內(nèi)聚就不進(jìn)行大范圍的變更了。同時(shí)內(nèi)聚也是要付出代價(jià)的，所以你也不必要去為了一個(gè)不太可能的變更去進(jìn)行過度設(shè)計(jì)，應(yīng)當(dāng)掌握一個(gè)度。過度的內(nèi)聚必將增加系統(tǒng)中元素之間的依賴，提高耦合度。所以“高內(nèi)聚”與“低耦合”是矛盾的，必須權(quán)衡利弊，綜合地去處理。綜上所述，“高內(nèi)聚”給軟件項(xiàng)目帶來的優(yōu)點(diǎn)是：可讀性強(qiáng)、易維護(hù)和變更、支持低耦合、移植和重用性強(qiáng)。

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

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

2）   何時(shí)使用

在理解創(chuàng)建者模式的時(shí)候，我認(rèn)為一個(gè)首先必須理解的問題是，在軟件項(xiàng)目的整個(gè)過程中，它應(yīng)該是在什么階段使用。一個(gè)網(wǎng)友曾經(jīng)發(fā)帖問我，他不清楚GRASP3）   為什么

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

4）   創(chuàng)建者模式是原則，不是準(zhǔn)則

“創(chuàng)建者模式是原則，不是準(zhǔn)則”難道“原則”和“準(zhǔn)則”還有不同嗎？當(dāng)然。創(chuàng)建者模式是原則，所以我們在業(yè)務(wù)分析階段應(yīng)當(dāng)盡量遵守。但創(chuàng)建者模式不是準(zhǔn)則，因?yàn)椴⒎俏覀兊乃熊浖惗急仨氉袷亍槭裁催@么說呢？隨著項(xiàng)目的進(jìn)行，我們的分析設(shè)計(jì)就不再停留在業(yè)務(wù)的分析上，各種具體的框架和技術(shù)將不斷引進(jìn)項(xiàng)目中，這時(shí)對象的創(chuàng)建就不一定符合創(chuàng)建者模式。比如，為了提高系統(tǒng)的性能和可維護(hù)性、更好地處理對象的創(chuàng)建與回收等復(fù)雜的問題，我們常常把對象的創(chuàng)建交給工廠，如spring

總之，合理地創(chuàng)建對象可以有效的提供可讀性、降低耦合度、提高系統(tǒng)的封裝性和可移植性，我們應(yīng)當(dāng)引起重視。