3 ）職責(zé)驅(qū)動(dòng)設(shè)計(jì)和領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)

前面我提到，當(dāng)我們嘗試寫一些復(fù)雜功能的時(shí)候，我們把功能分解成一個(gè)個(gè)相對(duì)獨(dú)立的函數(shù)。但是，應(yīng)當(dāng)將這些函數(shù)分配到哪個(gè)類中呢？也就是系統(tǒng)中的所有類都應(yīng)當(dāng)擁有哪些函數(shù)呢？或者說(shuō)應(yīng)當(dāng)表現(xiàn)出哪些行為呢？答案就在這里：以職責(zé)為中心，根據(jù)職責(zé)分配行為。我們?cè)诜治鱿到y(tǒng)時(shí)，首先是根據(jù)客戶需求進(jìn)行用例分析，然后根據(jù)用例繪制領(lǐng)域模式和分析模型，整個(gè)系統(tǒng)最主要的類就形成了。通過(guò)以上分析形成的類，往往和現(xiàn)實(shí)世界的對(duì)象是對(duì)應(yīng)的。正因?yàn)槿绱耍浖澜绲倪@些類也具有了與現(xiàn)實(shí)世界的對(duì)象相對(duì)應(yīng)的職責(zé)，以及在這些職責(zé)范圍內(nèi)的行為。

職責(zé)驅(qū)動(dòng)設(shè)計(jì)（ Responsibility Drive Design ， RDD ）是 Craig Larman 在他的經(jīng)典著作《 UML 和模式應(yīng)用》中提出的。職責(zé)驅(qū)動(dòng)設(shè)計(jì)的核心思想，就是我們?cè)趯?duì)一個(gè)系統(tǒng)進(jìn)行分析設(shè)計(jì)的時(shí)候，應(yīng)當(dāng)以職責(zé)為中心，根據(jù)職責(zé)分配行為。這種思想首先要求我們?cè)O(shè)計(jì)的所有軟件世界的對(duì)象，應(yīng)當(dāng)與現(xiàn)實(shí)世界盡量保持一致，他稱之為“低表示差異”。有了低表示差異，一方面提高了代碼的可讀性，另一方面，當(dāng)業(yè)務(wù)發(fā)生變更的時(shí)候，也可以根據(jù)實(shí)際情況快速應(yīng)對(duì)變更。

Craig Larman 在提出職責(zé)驅(qū)動(dòng)設(shè)計(jì)理論的同時(shí)，還提出了 GRASP 設(shè)計(jì)模式，來(lái)豐富這個(gè)理論。在 GRASP 設(shè)計(jì)模式中，我認(rèn)為，低耦合、高內(nèi)聚、信息專家模式最有用（以后再詳細(xì)講述）。

繼 Craig Larman 提出的職責(zé)驅(qū)動(dòng)設(shè)計(jì)數(shù)年之后，另一位大師提出了領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)。領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（ Domain Drive Design ， DDD ）是 Eric Evans 在他的同名著作《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》中提出的。在之前的設(shè)計(jì)理論中，領(lǐng)域模型是從用例模型到分析模型之間的一種中間模型，也就是從需求分析到軟件開(kāi)發(fā)之間的一種中間模型。這么一個(gè)中間模型，既不是需求階段的重要產(chǎn)物，在開(kāi)發(fā)階段也不以它作為標(biāo)準(zhǔn)進(jìn)行開(kāi)發(fā)，僅僅是作為參考，甚至給人感覺(jué)有一些多余。但是， Evans 在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中，將它放到了一個(gè)無(wú)比重要的位置。按照領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的理論，在需求分析階段，需求分析人員使用領(lǐng)域模型與客戶進(jìn)行溝通；在設(shè)計(jì)開(kāi)發(fā)階段，開(kāi)發(fā)人員使用領(lǐng)域模型指導(dǎo)設(shè)計(jì)開(kāi)發(fā)；在運(yùn)行維護(hù)和二次開(kāi)發(fā)階段，維護(hù)和二次開(kāi)發(fā)人員使用領(lǐng)域模型理解和熟悉系統(tǒng)，并指導(dǎo)他們進(jìn)行維護(hù)和二次開(kāi)發(fā)。總之，在整個(gè)軟件開(kāi)發(fā)的生命周期中，領(lǐng)域模型都成為了最核心的內(nèi)容。

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)繼承了職責(zé)驅(qū)動(dòng)設(shè)計(jì)。在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中強(qiáng)調(diào)的，依然是低表示差異，以及職責(zé)的分配。但是，如何做到低表示差異呢？如何完成職責(zé)分配呢？領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)給了我們完美的答案，那就是建立領(lǐng)域模型。領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)改變了我們的設(shè)計(jì)方式。在需求分析階段，用例模型已不再是這個(gè)階段的核心，而是建立領(lǐng)域模型。在開(kāi)發(fā)和二次開(kāi)發(fā)階段，開(kāi)發(fā)人員也不再是一埋頭地猛扎進(jìn)程序堆里開(kāi)始編程，而是首先細(xì)致地進(jìn)行領(lǐng)域模型分析。領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)強(qiáng)調(diào)持續(xù)精化，使領(lǐng)域模型不再是一旦完成分析就扔在一邊不再理會(huì)的圖紙，而是在不斷理解業(yè)務(wù)的基礎(chǔ)上不斷修改和精化領(lǐng)域模型，進(jìn)而驅(qū)動(dòng)我們代碼的精化。領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)強(qiáng)調(diào)的不再是一次軟件開(kāi)發(fā)過(guò)程中我們要做的工作，它看得更加長(zhǎng)遠(yuǎn)，它強(qiáng)調(diào)的是一套軟件在相當(dāng)長(zhǎng)一段時(shí)間內(nèi)持續(xù)升級(jí)的過(guò)程中我們應(yīng)當(dāng)做的工作。我認(rèn)為，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)是提高代碼質(zhì)量的最高等級(jí)。當(dāng)時(shí)，使用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)進(jìn)行軟件開(kāi)發(fā)是一場(chǎng)相當(dāng)巨大的改革，它顛覆了我們過(guò)去的所有開(kāi)發(fā)模式，我們必須腳踏實(shí)地地一步一步去實(shí)踐和改變。

?

職責(zé)驅(qū)動(dòng)設(shè)計(jì)

隨著軟件業(yè)的不斷發(fā)展，隨著軟件需求的不斷擴(kuò)大，軟件所管理的范圍也在不斷拓寬。過(guò)去一個(gè)軟件僅僅管理一臺(tái)電腦的一個(gè)小小的功能，而現(xiàn)在被擴(kuò)展到了一個(gè)企業(yè)、一個(gè)行業(yè)、一個(gè)產(chǎn)業(yè)鏈。過(guò)去我們開(kāi)發(fā)一套軟件，只有少量的二次開(kāi)發(fā)，當(dāng)它使用到一定時(shí)候我們就拋棄掉重新又開(kāi)發(fā)一套。現(xiàn)在，隨著用戶對(duì)軟件依賴程度的不斷加大，我們很難說(shuō)拋棄一套軟件重新開(kāi)發(fā)了，更多的是在一套軟件中持續(xù)改進(jìn)，使這套軟件的生命周期持續(xù)數(shù)年以及數(shù)個(gè)版本。正是因?yàn)檐浖I(yè)面臨著如此巨大的壓力，我們的代碼質(zhì)量，我們開(kāi)發(fā)的軟件擁有的可變更性和持續(xù)改進(jìn)的能力，成為軟件制勝的關(guān)鍵因素，令我們不能不反思。

?

代碼質(zhì)量評(píng)價(jià)的關(guān)鍵指標(biāo)：低耦合，高內(nèi)聚

耦合就是對(duì)某元素與其它元素之間的連接、感知和依賴的量度。耦合包括：

1 ．元素 B 是元素 A 的屬性，或者元素 A 引用了元素 B 的實(shí)例（這包括元素 A 調(diào)用的某個(gè)方法，其參數(shù)中包含元素 B ）。

2 ．元素 A 調(diào)用了元素 B 的方法。

3 ．元素 A 直接或間接成為元素 B 的子類。

4 ．元素 A 是接口 B 的實(shí)現(xiàn)。

如果一個(gè)元素過(guò)于依賴其它元素，一旦它所依賴的元素不存在，或者發(fā)生變更，則該元素將不能再正常運(yùn)行，或者不得不相應(yīng)地進(jì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)聚就像一個(gè)專橫的管理者，它只做自己職責(zé)范圍內(nèi)的事，而將其它與它相關(guān)的事情，分配給別人去做。

高質(zhì)量的代碼要求我們的代碼保持低耦合、高內(nèi)聚。但是，這個(gè)要求是如此的抽象與模糊，如何才能做到這些呢？軟件大師們告訴我們了許多方法，其中之一就是 Craig Larman 的職責(zé)驅(qū)動(dòng)設(shè)計(jì)。

職責(zé)驅(qū)動(dòng)設(shè)計(jì) （ Responsibility Drive Design ， RDD ） 是 Craig Larman 在他的經(jīng)典著作《 UML 和模式應(yīng)用》中提出的。要理解職責(zé)驅(qū)動(dòng)設(shè)計(jì)，我們首先要理解 “ 低表示差異 ” 。

?

低表示差異

我們開(kāi)發(fā)的應(yīng)用軟件實(shí)際上是對(duì)現(xiàn)實(shí)世界的模擬，因此，軟件世界與現(xiàn)實(shí)世界存在著必然的聯(lián)系。當(dāng)我們?cè)谶M(jìn)行需求分析的時(shí)候，需求分析員實(shí)際上是從客戶那里在了解現(xiàn)實(shí)世界事物的規(guī)則、工作的流程。如果我們?cè)谲浖治龊驮O(shè)計(jì)的過(guò)程中，將軟件世界與現(xiàn)實(shí)世界緊密地聯(lián)系到一起，我們的軟件將更加本色地還原事物最本質(zhì)的規(guī)律。這樣的設(shè)計(jì)，就稱之為“低表示差異”。

?

?

采用“低表示差異”進(jìn)行軟件設(shè)計(jì)，現(xiàn)實(shí)世界有什么事物，就映射為軟件世界的各種對(duì)象（類）；現(xiàn)實(shí)世界的事物擁有什么樣的職責(zé)，在軟件世界里的對(duì)象就擁有什么樣的職責(zé)；在現(xiàn)實(shí)世界中的事物，因?yàn)樗穆氊?zé)而產(chǎn)生的行為，在軟件世界中就反映為對(duì)象所擁有的函數(shù)。

低表示差異，使分析設(shè)計(jì)者對(duì)軟件的分析和設(shè)計(jì)更加簡(jiǎn)單，思路更加清晰；使代碼更加可讀，閱讀者更加易于理解；更重要的是，當(dāng)需求發(fā)生變更，或者業(yè)務(wù)產(chǎn)生擴(kuò)展時(shí)，設(shè)計(jì)者只需要遵循事物本來(lái)的面貌去思考和修改軟件，使軟件更加易于變更和擴(kuò)展。

?

?

角色、職責(zé)、協(xié)作

理解了“低表示差異”，現(xiàn)在我們來(lái)看看我們應(yīng)當(dāng)如何運(yùn)用職責(zé)驅(qū)動(dòng)設(shè)計(jì)進(jìn)行分析和設(shè)計(jì)。首先，我們通過(guò)與客戶的溝通和對(duì)業(yè)務(wù)需求的了解，從中提取出現(xiàn)實(shí)世界中的關(guān)鍵事物以及相互之間的關(guān)系。這個(gè)過(guò)程我們通常通過(guò)建立領(lǐng)域模型來(lái)完成。領(lǐng)域模型建立起來(lái)以后，通過(guò)諸如 Rational Rose 這樣的設(shè)計(jì)軟件的正向工程，生成了我們?cè)谲浖到y(tǒng)中最初始的軟件類。這些軟件類，由于每個(gè)都扮演著現(xiàn)實(shí)世界中的一個(gè)具體的角色，因而賦予了各自的職責(zé)。前面我已經(jīng)提到，如果你的系統(tǒng)采用職責(zé)驅(qū)動(dòng)設(shè)計(jì)的思想進(jìn)行設(shè)計(jì)開(kāi)發(fā)，作為一個(gè)好的習(xí)慣，你應(yīng)當(dāng)在每一個(gè)軟件類的注釋首行，清楚地描述該軟件類的職責(zé)。

當(dāng)我們完成了系統(tǒng)中軟件類的制訂，分配好了各自的職責(zé)，我們就應(yīng)該開(kāi)始根據(jù)軟件需求，編寫各個(gè)軟件類的功能。在前面我給大家提出了一個(gè)建議，就是不要在一個(gè)函數(shù)中編寫大段的代碼。編寫大段的代碼，通常會(huì)降低代碼的內(nèi)聚度，因?yàn)檫@些代碼中將包含不是該軟件類應(yīng)當(dāng)完成的工作。作為一個(gè)有經(jīng)驗(yàn)的開(kāi)發(fā)人員，在編寫一個(gè)功能時(shí)，首先應(yīng)當(dāng)對(duì)功能進(jìn)行分解。一段稍微復(fù)雜的功能，通常都可以被分解成一個(gè)個(gè)相對(duì)獨(dú)立的步驟。步驟與步驟之間存在著交互，那就是數(shù)據(jù)的輸入輸出。通過(guò)以上的分解，每一個(gè)步驟將形成一個(gè)獨(dú)立的函數(shù)，并且使用一個(gè)可以表明這個(gè)步驟意圖的釋義函數(shù)名。接下來(lái)，我們應(yīng)當(dāng)考慮的，就是應(yīng)當(dāng)將這些函數(shù)交給誰(shuí)。它們有可能交給原軟件類，也有可能交給其它軟件類，其分配的原則是什么呢？答案是否清楚，那就是職責(zé)。每個(gè)軟件類代表現(xiàn)實(shí)世界的一個(gè)事物，或者說(shuō)一個(gè)角色。在現(xiàn)實(shí)世界中這個(gè)任務(wù)應(yīng)當(dāng)由誰(shuí)來(lái)完成，那么在軟件世界中，這個(gè)函數(shù)就應(yīng)當(dāng)分配給相應(yīng)的那個(gè)軟件類。

通過(guò)以上步驟的分解，一個(gè)功能就分配給了多個(gè)軟件類，相互協(xié)作地完成這個(gè)功能。這樣的分析和設(shè)計(jì)，其代碼一定是高內(nèi)聚的和高可讀性的。同時(shí)，當(dāng)需求發(fā)生變更的時(shí)候，設(shè)計(jì)者通過(guò)對(duì)現(xiàn)實(shí)世界的理解，可以非常輕松地找到那個(gè)需要修改的軟件類，而不會(huì)影響其它類，因而也就變得易維護(hù)、易變更和低耦合了。

說(shuō)了這么多，舉一個(gè)實(shí)例也許更能幫助理解。拿一個(gè)員工工資系統(tǒng)來(lái)說(shuō)吧。當(dāng)人力資源在發(fā)放一個(gè)月工資的時(shí)候，以及離職的員工肯定不能再發(fā)放工資了。在系統(tǒng)設(shè)計(jì)的期初，開(kāi)發(fā)人員商量好，在員工信息中設(shè)定一個(gè)“離職標(biāo)志”字段。編寫工資發(fā)放的開(kāi)發(fā)人員通過(guò)查詢，將“離職標(biāo)志”為 false 的員工查詢出來(lái)，并為他們計(jì)算和發(fā)放工資。但是，隨著這個(gè)系統(tǒng)的不斷使用，編寫員工管理的開(kāi)發(fā)人員發(fā)現(xiàn)，“離職標(biāo)志”字段已經(jīng)不能滿足客戶的需求，因而將“離職標(biāo)志”字段廢棄，并增加了一個(gè)“離職時(shí)間”字段來(lái)管理離職的員工。然而，編寫工資發(fā)放的開(kāi)發(fā)人員并不知道這樣的變更，依然使用著“離職標(biāo)志”字段。顯然，這樣的結(jié)果就是，軟件系統(tǒng)開(kāi)始對(duì)離職員工發(fā)放工資了。仔細(xì)分析這個(gè)問(wèn)題的原因，我們不難發(fā)現(xiàn)，確認(rèn)員工是否離職，并不是“發(fā)放工資”軟件類應(yīng)當(dāng)完成的工作，而應(yīng)當(dāng)是“員工管理”軟件類應(yīng)當(dāng)完成的。如果將“獲取非離職員工”的任務(wù)交給“員工管理”軟件類，而“發(fā)放工資”軟件類僅僅只是去調(diào)用，那么離職功能由“離職標(biāo)志”字段改為了“離職時(shí)間”字段，其實(shí)就與“發(fā)放工資”軟件類毫無(wú)關(guān)系。而作為“員工管理”的開(kāi)發(fā)人員，一旦發(fā)生這樣的變更，他當(dāng)然知道去修改自己相應(yīng)的“獲取非離職員工”函數(shù)，這樣就不會(huì)發(fā)生以上問(wèn)題。通過(guò)這樣一個(gè)實(shí)例，也許你能夠理解“職責(zé)驅(qū)動(dòng)設(shè)計(jì)”的精要與作用了吧。

?

職責(zé)分配與信息專家

通過(guò)以上對(duì)職責(zé)驅(qū)動(dòng)設(shè)計(jì)的講述，我們不難發(fā)現(xiàn)，職責(zé)驅(qū)動(dòng)設(shè)計(jì)的精要就是職責(zé)分配。但是，在紛繁復(fù)雜的軟件設(shè)計(jì)中，如何進(jìn)行職責(zé)分配常常令我們迷惑。幸運(yùn)的是， Larman 大師清楚地認(rèn)識(shí)到了這一點(diǎn)。在他的著作中，信息專家模式為我們提供了幫助。

信息專家模式（又稱為專家模式）告訴我們，在分析設(shè)計(jì)中，應(yīng)當(dāng)將職責(zé)分配給軟件系統(tǒng)中的這樣一個(gè)軟件類，它擁有實(shí)現(xiàn)這個(gè)職責(zé)所必須的信息。我們稱這個(gè)軟件類，叫“信息專家”。用更加簡(jiǎn)短的話說(shuō)，就是將職責(zé)分配給信息專家。

為什么我們要將職責(zé)分配給信息專家呢？我們用上面的例子來(lái)說(shuō)明吧。當(dāng)“發(fā)放工資”軟件類需要獲取非離職員工時(shí)，“員工管理”軟件類就是“獲取非離職員工”任務(wù)的信息專家，因?yàn)樗莆罩袉T工的信息。假設(shè)我們不將“獲取非離職員工”的任務(wù)交給“員工管理”軟件類，而是另一個(gè)軟件類 X ，那么，為了獲取員工信息，軟件類 X 不得不訪問(wèn)“員工管理”軟件類，從而使“發(fā)放工資”與 X 耦合， X 又與“員工管理”耦合。這樣的設(shè)計(jì)，不如直接將“獲取非離職員工”的任務(wù)交給“員工管理”軟件類，使得“發(fā)放工資”僅僅與“員工管理”耦合，從而有效地降低了系統(tǒng)的整體耦合度。

?

總之，采用“職責(zé)驅(qū)動(dòng)設(shè)計(jì)”的思路，為我們提高軟件開(kāi)發(fā)質(zhì)量、可讀性、可維護(hù)性，以及保持軟件的持續(xù)發(fā)展，提供了一個(gè)廣闊的空間。

一堂如何提高代碼質(zhì)量的培訓(xùn)課（3）