空間站

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

 

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

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

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

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

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

與“低耦合”一樣，高內(nèi)聚也不是一個(gè)絕對(duì)，而是一個(gè)相對(duì)的指標(biāo)，應(yīng)當(dāng)適當(dāng)而不能過(guò)度。正如我們?cè)诂F(xiàn)實(shí)生活中，如果在一個(gè)十來(lái)人的小公司，每個(gè)人的分工可能會(huì)粗一些，所分配的職責(zé)會(huì)廣一些雜一些，因?yàn)槠淇傮w的任務(wù)少；而如果在一個(gè)一兩百人的大公司，每個(gè)人的分工會(huì)細(xì)一些，所分配的任務(wù)會(huì)更加專一些，因?yàn)榭傮w任務(wù)多，更需要專業(yè)化的分工來(lái)提高效率。軟件開(kāi)發(fā)也是一樣，如果“評(píng)審計(jì)劃”對(duì)象完成的業(yè)務(wù)功能少，并且不復(fù)雜，它完全可以代理它的子表“評(píng)審對(duì)象”和“評(píng)審者”的管理。但是“評(píng)審計(jì)劃”對(duì)象需要完成的“對(duì)評(píng)審計(jì)劃表的管理”這個(gè)基本職責(zé)包含的業(yè)務(wù)功能繁多或者復(fù)雜，它就應(yīng)當(dāng)將“對(duì)評(píng)審對(duì)象表的管理”交給“評(píng)審對(duì)象”對(duì)象，將“對(duì)評(píng)審者表的管理”交給“評(píng)審者”對(duì)象。同樣，高內(nèi)聚的可維護(hù)性好、易變更性好只能是一個(gè)相對(duì)的指標(biāo)。如果一個(gè)變更的確是大范圍的變更，你永遠(yuǎn)不可能通過(guò)內(nèi)聚就不進(jìn)行大范圍的變更了。同時(shí)內(nèi)聚也是要付出代價(jià)的，所以你也不必要去為了一個(gè)不太可能的變更去進(jìn)行過(guò)度設(shè)計(jì)，應(yīng)當(dāng)掌握一個(gè)度。過(guò)度的內(nèi)聚必將增加系統(tǒng)中元素之間的依賴，提高耦合度。所以“高內(nèi)聚”與“低耦合”是矛盾的，必須權(quán)衡利弊，綜合地去處理。綜上所述，“高內(nèi)聚”給軟件項(xiàng)目帶來(lái)的優(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è)對(duì)象發(fā)出了撕心裂肺的怒吼——誰(shuí)來(lái)創(chuàng)建我？！！！一個(gè)對(duì)象，不管擁有多么強(qiáng)大的功能，不管進(jìn)行了多么精巧的設(shè)計(jì)，如果不能被創(chuàng)建，就如同韓信不能做將軍，孫臏不能當(dāng)軍師，勾踐不能回越國(guó)，劉備不能得荊州，一切一切的雄才武略都如廢紙一張。既然“創(chuàng)建”對(duì)于對(duì)象如此重要，我們就來(lái)好好探討一下GRASP3.           當(dāng)我們完成了用例模型、領(lǐng)域模型、對(duì)象分析的設(shè)計(jì)，初步完成了對(duì)象設(shè)計(jì)和職責(zé)分配的工作，開(kāi)始進(jìn)一步細(xì)化的時(shí)候，一個(gè)我們不得不考慮的問(wèn)題就擺在我們的面前——誰(shuí)來(lái)創(chuàng)建這些對(duì)象？也許現(xiàn)在的你會(huì)覺(jué)得好笑，這也是問(wèn)題嗎？在軟件實(shí)際開(kāi)發(fā)過(guò)程中，誰(shuí)需要使用某個(gè)對(duì)象，就去創(chuàng)建它就行了，有什么好討論的。但是，我不得不說(shuō)的是，如果你只是漫不經(jīng)心地想要隨意開(kāi)發(fā)一套軟件系統(tǒng)，僅僅是完成自己工作而已，你完全不用考慮創(chuàng)建對(duì)象的問(wèn)題。然而如果你希望開(kāi)發(fā)一套高質(zhì)量的、低耦合的、封裝性和復(fù)用性高的軟件系統(tǒng)，你必須得認(rèn)真考慮這個(gè)問(wèn)題。為什么呢？因?yàn)橄到y(tǒng)中如果一個(gè)對(duì)象A那么為了降低系統(tǒng)耦合，提高系統(tǒng)的清晰度、封裝性和可復(fù)用性，應(yīng)該有一些通用的原則，以用于對(duì)象職責(zé)分配中，關(guān)于“創(chuàng)建對(duì)象”這類職責(zé)的分配。這些原則的描述就在GRASP1）   創(chuàng)建者模式的描述

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

2）   何時(shí)使用

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

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

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

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

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