問題的提出
我常常在思考一個問題，我們?nèi)绾文茉O(shè)計(jì)出高水平、高質(zhì)量的軟件出來。怎樣是高水平、高質(zhì)量的軟件？它應(yīng)當(dāng)是易于維護(hù)、易于適應(yīng)變更、可重用性好的一個系統(tǒng)。如何做到這一點(diǎn)呢？答案當(dāng)然是“低耦合、高內(nèi)聚”了。低耦合就是軟件在構(gòu)造的時(shí)候，各個模塊、各個功能、各個類都不會過度依賴于它周圍的環(huán)境。只有這樣，才能使我們的模塊（功能、類）在周圍發(fā)生變更時(shí)不受影響，做到易于維護(hù)和易于適應(yīng)變更。正因?yàn)槿绱耍彩顾子谥赜玫狡渌δ茴愃频沫h(huán)境中，提高了重用性。高內(nèi)聚則使軟件中的各個模塊（功能、類）能夠各盡其能而又充分合作，也就是對于軟件問題空間中需求的各個功能，系統(tǒng)可以合理地把它分配給各個模塊（功能、類）來共同完成，而不是一個或幾個八面玲瓏、包打天下的超級類一個人完成。而對于該系統(tǒng)中的某一個模塊（功能、類），具有自己高度相關(guān)的職責(zé)，即該職責(zé)中的幾個任務(wù)是高度相關(guān)的。每一個模塊（功能、類）都決不去完成與自己無關(guān)職責(zé)的任務(wù)。
那么怎樣能構(gòu)造一個低耦合、高內(nèi)聚的系統(tǒng)能，時(shí)下最流行的框架結(jié)構(gòu)之一的struts+spring+hibernate然而我要說的是，即使我們使用了struts+spring+hibernate
分析與決策
1. 編寫DAO的時(shí)候不要直接去使用hibernate或spring對hibernate的支持。
現(xiàn)在我們在編寫DAO以上問題，究其原因，是我們項(xiàng)目中的DAO
2. 編寫Action的時(shí)候不要直接使用spring和spring的繼承類
前面我說了應(yīng)當(dāng)避免DAO的繼承類然后使用它的方法。如此的使用，我們的Action將依賴與spring。我們同樣可以使用一個叫BasicAction的父類，然后用一個接口來隔離spring。由于ActionBasicAction中，提高系統(tǒng)的可維護(hù)性。
3. 當(dāng)BUS需要獲取別的模塊的數(shù)據(jù)的時(shí)候，不要直接去使用該模塊的DAO
我舉一個簡單的例子：我需要設(shè)計(jì)一個軟件評審的管理軟件，該軟件分為評審組織者制訂評審計(jì)劃、評審者分別填寫評審表后由評審組織者匯總評審表、評審組織者制作評審報(bào)告。這是一個非常簡單的項(xiàng)目，分成了三個人來完成。但是項(xiàng)目進(jìn)行快結(jié)束的時(shí)候卻出現(xiàn)了問題。填寫評審表需要獲得評審計(jì)劃中的一些數(shù)據(jù)，制作評審報(bào)告的數(shù)據(jù)來源于評審表。項(xiàng)目組在開始編程前先開了一次會，大家約定好了各個部分的數(shù)據(jù)格式及其規(guī)則，然后開始工作。然而數(shù)天后項(xiàng)目組把各個模塊整合以后發(fā)現(xiàn)，系統(tǒng)根本跑不起來，為什么呢？設(shè)計(jì)評審計(jì)劃的人發(fā)現(xiàn)，所有評審計(jì)劃應(yīng)當(dāng)按照產(chǎn)品編號來進(jìn)行管理而不是項(xiàng)目編號。由于這個變更，填寫評審表模塊在待評審列表中什么都無法顯示；同樣，設(shè)計(jì)評審表的人發(fā)現(xiàn)，在一個評審計(jì)劃中評審表與評審者不是一對多的關(guān)系，而是一對一的關(guān)系，因而修改了這兩個表的關(guān)聯(lián)。因?yàn)檫@樣，在制作評審報(bào)告時(shí)就不能正確得到評審表數(shù)據(jù)。其實(shí)一個軟件項(xiàng)目在整個進(jìn)行過程中總是不斷變更。我們需要做的不是去抑制這些變更，而應(yīng)當(dāng)是通過軟件的結(jié)構(gòu)去適應(yīng)這些變更，即是降低各模塊間的依賴（耦合），提高內(nèi)聚。
拿這個實(shí)例來說，當(dāng)評審表需要調(diào)用評審計(jì)劃的數(shù)據(jù)的時(shí)候，不應(yīng)當(dāng)是自己寫一個DAO去調(diào)用評審計(jì)劃的數(shù)據(jù)，而應(yīng)當(dāng)是調(diào)用評審計(jì)劃的接口，將這個任務(wù)交給評審計(jì)劃類來完成。當(dāng)評審報(bào)告需要調(diào)用評審表的數(shù)據(jù)的時(shí)候，同樣應(yīng)當(dāng)去調(diào)用評審表的接口，由評審表來實(shí)現(xiàn)。同時(shí)，這種調(diào)用應(yīng)當(dāng)是去調(diào)用BUS層的接口。為什么呢？比如在評審計(jì)劃中的一個業(yè)務(wù)邏輯是只有在評審計(jì)劃發(fā)布以后才能制作評審表，那么怎樣才是已發(fā)布的評審計(jì)劃呢？這個業(yè)務(wù)邏輯應(yīng)當(dāng)由誰來定義？當(dāng)然是評審計(jì)劃。在什么地方定義？當(dāng)然是BUS而不是DAO，因?yàn)?/span>DAO僅僅是實(shí)現(xiàn)數(shù)據(jù)的持久化，而BUS才是實(shí)現(xiàn)業(yè)務(wù)邏輯的地方。既然如此，如果評審表去調(diào)用評審計(jì)劃的DAO，那么已發(fā)布評審計(jì)劃的業(yè)務(wù)邏輯必然包含在了評審表的業(yè)務(wù)邏輯里了。我們假設(shè)有一天，已發(fā)布評審計(jì)劃的業(yè)務(wù)邏輯發(fā)生變更了（實(shí)際上這樣的會在你毫不經(jīng)意間就發(fā)生了），編寫評審計(jì)劃的人會很快就修改了評審計(jì)劃的業(yè)務(wù)實(shí)現(xiàn)并且測試通過了。他不知道評審表里也包含了這樣的業(yè)務(wù)邏輯，因而修改后的程序在運(yùn)行到評審表的時(shí)候就很可能會出錯。不幸的是，在實(shí)際工作中，同樣一個業(yè)務(wù)邏輯可能包含在無數(shù)個你可能知道，但你也可能不知道的代碼中。這樣的結(jié)構(gòu)就是一個不易于維護(hù)的差的結(jié)構(gòu)。
總結(jié)：從技術(shù)升級和需求變更兩方面適應(yīng)變化
軟件開發(fā)專家Alistair Cockburn相關(guān)鏈接：回復(fù)：《如何在struts+spring+hibernate的框架下構(gòu)建低耦合高內(nèi)聚的軟件》。
| Spring-Hibernate.rar |
| 描述: |
|
下載 |
| 文件名: |
Spring-Hibernate.rar |
| 文件大小: |
9 KB |
| 下載過的: |
文件被下載或查看 511 次 |