高內(nèi)聚 Java 軟件工程 軟件模式

《高內(nèi)聚 Java 軟件工程 軟件模式》由會員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在教育資源-天天文庫。

1、高內(nèi)聚Java軟件工程軟件模式一個重要的模式：高內(nèi)聚。2.高內(nèi)聚（HighCohesion）高內(nèi)聚是另一個普遍用來評判軟件設(shè)計質(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)中的各個元素具有較高的協(xié)作性，因?yàn)樵谖覀冊谕瓿绍浖枨笾械囊粋€功能，可能需要做各種事情，但是具有高內(nèi)聚性的一個元素，只完成它職責(zé)內(nèi)的事情，而把那些不在它職責(zé)內(nèi)的事情拿去請

2、求別人來完成。這就好像，如果我是一個項目經(jīng)理，我的職責(zé)是監(jiān)控和協(xié)調(diào)我的項目各個階段的工作。當(dāng)我的項目進(jìn)入需求分析階段，我會請求需求分析員來完成；當(dāng)我的項目進(jìn)入開發(fā)階段，我會請求軟件開發(fā)人員來完成；當(dāng)我的項目需要測試的時候，我會請求測試人員。。。。。。如果我參與了開發(fā)，我就不是一個高內(nèi)聚的元素，因?yàn)殚_發(fā)不是我的職責(zé)。我們的項目為什么要高內(nèi)聚呢？我覺得可以從可讀性、復(fù)用性、可維護(hù)性和易變更性四個方面來理解。1．可讀性一個人寫文章、講事情，條理清晰才能易于理解，這同樣發(fā)生在讀寫軟件代碼上。如果一堆代碼寫得一團(tuán)亂麻，東

3、一個跳轉(zhuǎn)西一個調(diào)用，讀它的人會感覺非常頭疼。這種事情也許一直在寫程序的你我都曾經(jīng)有過經(jīng)歷。如果一段程序條理非常清晰，每個類通過名稱或說明都能清楚明白它的意義，類的每個屬性、函數(shù)也都是易于理解的它所應(yīng)當(dāng)完成的任務(wù)和行為，這段程序的可讀性必然提高。在軟件產(chǎn)業(yè)越來越密集，軟件產(chǎn)業(yè)中開發(fā)人員協(xié)作越來越緊密、分工越來越細(xì)的今天，軟件可讀性的要求相信也越來越為人們所重視。2．復(fù)用性在軟件開發(fā)中，最低等級的復(fù)用是代碼拷貝，然后是函數(shù)的復(fù)用、對象的復(fù)用、組件的復(fù)用。軟件開發(fā)中最懶的人是最聰明的人，他們總是想到復(fù)用。在代碼編寫的

4、時候突然發(fā)現(xiàn)某個功能是曾經(jīng)實(shí)現(xiàn)過的功能，直接把它拷貝過來就ok了。如果這段代碼在同一個對象中，那么就提出來寫一個函數(shù)到處調(diào)用就行了。如果不是在同一個對象中呢，就將其抽象成一個對象到處調(diào)用吧。如果不在一個項目中呢，那就做成組件給各個項目引用吧。代碼復(fù)用也使我們的代碼在復(fù)用的過程中不斷精化、不斷健壯、提高代碼質(zhì)量。代碼的復(fù)用的確給我們的開發(fā)帶來了不少便利，但是一段代碼能否在各個需要的地方都能復(fù)用呢？這給我們的軟件開發(fā)質(zhì)量提出了新的要求：好的代碼可以復(fù)用，不好的則不行。軟件中的一個對象如果能保證能完成自己職能范圍內(nèi)的

5、各項任務(wù)，同時又不去理會與自己職能無關(guān)的其它任務(wù)，那么它就能夠保證功能的相對獨(dú)立性，也就可以脫離自己所處的環(huán)境而復(fù)用到其它環(huán)境中，這是一個具有內(nèi)聚性的對象。3．可維護(hù)性和易變更性在前面《如何在struts+spring+hibernate的框架下構(gòu)建低耦合高內(nèi)聚的軟件》中我提到，我們現(xiàn)在的軟件是在不斷變更的，這種變更不僅來自于我們的客戶，更來自于我們的市場。如果我們的軟件通過變更能及時適應(yīng)我們的市場需求，我們就可以在市場競爭中獲勝。如何能及時變更以適應(yīng)我們的市場呢，就是通過調(diào)整軟件的結(jié)構(gòu)，使我們每次的變更付出的

6、代價最小，耗費(fèi)的人力最小，這種變更才最快最經(jīng)濟(jì)。高內(nèi)聚的軟件，每個系統(tǒng)、模塊、類的任務(wù)都高度相關(guān)，就使每一次的變更涉及的范圍縮小到最小。比如評審表發(fā)生了變更，只會與評審表對象有關(guān)，我們不會去更改其它的對象。如果我們能做到這一點(diǎn)，我們的系統(tǒng)當(dāng)然是可維護(hù)性好、易變更性好的系統(tǒng)。那么，我們?nèi)绾巫龅礁邇?nèi)聚呢？就拿前面我提到的評審項目舉例。我現(xiàn)在要為“評審表”對象編寫一段填寫并保存評審表的代碼。評審表對象的職責(zé)是更新和查詢評審表的數(shù)據(jù)，但是在顯示一個要填寫的評審表的時候，我需要顯示該評審計劃的名稱、該評審計劃有哪些評審對

7、象需要評審。現(xiàn)在我如何編寫顯示一個要填寫的評審表的代碼？我在評審表對象的這個相應(yīng)的函數(shù)中編寫一段查詢評審計劃和評審對象的代碼嗎？假如你這樣做了，你的代碼就不是高內(nèi)聚的，因?yàn)椴樵冊u審計劃和評審對象的數(shù)據(jù)不是它的職責(zé)。正確的方法應(yīng)當(dāng)去請求“評審計劃”對象和“評審對象”對象來完成這些工作，而“評審表”對象只是獲取其結(jié)果。另外，如果一個對象要完成一個雖然在自己職責(zé)范圍內(nèi)，但過程非常復(fù)雜的任務(wù)時，也應(yīng)當(dāng)將該任務(wù)分解成數(shù)個功能相對獨(dú)立的子函數(shù)來完成。我曾經(jīng)看見一個朋友寫的數(shù)百行的一個函數(shù)，讓人讀起來非常費(fèi)勁。同時這樣的函數(shù)

8、中一些相對獨(dú)立的代碼，本可以復(fù)用到其它代碼中，也變成了不可能。所以我給大家的建議是，不要寫太長的函數(shù)，超過一百行就可以考慮將一些功能分解出去。與“低耦合”一樣，高內(nèi)聚也不是一個絕對，而是一個相對的指標(biāo)，應(yīng)當(dāng)適當(dāng)而不能過度。正如我們在現(xiàn)實(shí)生活中，如果在一個十來人的小公司，每個人的分工可能會粗一些，所分配的職責(zé)會廣一些雜一些，因?yàn)槠淇傮w的任務(wù)少；而如果在一個一兩百人的大公司，每個人的分工會