在架構(gòu)設(shè)計(jì)的領(lǐng)域，?們總結(jié)出了很多原則。這些原則的?語?都很簡略，容易傳播。但是提出這些原則的?，往往不會(huì)告訴你，為什么應(yīng)該是這樣的原則。哪怕說了背景，過了?段時(shí)間，聽的?可能已經(jīng)不知道原則提出?的初衷。?且這些原則，粗看起來是很有道理，可是在實(shí)踐中，卻往往不是這么回事，那么就淪為?靈雞湯了。在看這些原則的時(shí)候，每個(gè)?都要形成??的判斷能?，不要?云亦云才好。以下是個(gè)?對(duì)?些設(shè)計(jì)原則的思考，不?定正確，期望能夠引發(fā)讀者??的思考，形成讀者??的判斷。

?

KISS 原則

---

KISS(Keep It Simple, Stupid) 原則，翻譯成中?就是“保持簡單、愚蠢”。這是?句沒有主語的話，猜想主語應(yīng)該是指設(shè)計(jì)師，并且這個(gè)“It”應(yīng)該指的是設(shè)計(jì)師所設(shè)計(jì)的?標(biāo)系統(tǒng)。這條原則?意應(yīng)該是告訴設(shè)計(jì)師在設(shè)計(jì)時(shí)要保持系統(tǒng)的“Simple and Stupid”。這個(gè)原則仔細(xì)分析?下，有兩個(gè)?問題：

?先，“Simple and Stupid”的判斷原則是什么，怎樣才算是“Simple and Stupid”?這是這個(gè)原則中最讓?迷惑的地?，?般?下意識(shí)給出的是??所認(rèn)知的“Simple and Stupid”，這未必是提出這條原則的?所理解的“Simple and Stupid”。比如讓?個(gè)體操隊(duì)員來做?個(gè)后空翻，對(duì)于他來說，這是“Simple and Stupid”。可是讓?個(gè)沒經(jīng)過體操訓(xùn)練的普通?做?個(gè)后空翻，這絕對(duì)不“Simple and Stupid”，可能會(huì)摔斷脖?出?命的。

也就是說“Simple and Stupid”是因??異的，對(duì)于技術(shù)?平不同的?，他會(huì)的或者他能夠熟練掌握的技術(shù)才是“Simple and Stupid”。?個(gè)?平很?的設(shè)計(jì)師，看到?個(gè)系統(tǒng)，他可以給出他設(shè)計(jì)的“Simple and Stupid”?案，可是如果實(shí)現(xiàn)的?水平很糟糕、技術(shù)?準(zhǔn)達(dá)不到，勉強(qiáng)去實(shí)施的話，有可能會(huì)實(shí)現(xiàn)不出來的，哪怕做出來了也?定是問題多多，弄不好要搞出?事情。因此，要設(shè)計(jì)?個(gè)系統(tǒng)，要根據(jù)實(shí)施團(tuán)隊(duì)的?平，做適合他們的架構(gòu)設(shè)計(jì)，這樣才可以算得上是“Simple and Stupid”。

其次，?個(gè)系統(tǒng)的?的是為了給?戶來使?的。?個(gè)設(shè)計(jì)師設(shè)計(jì)了?個(gè)“Simple and Stupid”的系統(tǒng)，那么這個(gè)系統(tǒng)對(duì)?戶來說就?定好?嗎?如果?便了設(shè)計(jì)師，或者說?便了實(shí)施?員，說不定會(huì)影響使?系統(tǒng)的?戶呢?恰恰是讓?戶?起來“Simple and Stupid”的系統(tǒng)，才是?個(gè)好?的系統(tǒng)。那么給系統(tǒng)的設(shè)計(jì)師?個(gè)“Simple and Stupid”的原則，到底是在幫助誰?損害誰?符合業(yè)務(wù)?標(biāo)嗎?許多公司的設(shè)計(jì)師在設(shè)計(jì)系統(tǒng)的時(shí)候，不斷的和業(yè)務(wù)團(tuán)隊(duì)沖突，為了保持設(shè)計(jì)師所持的“Simple and Stupid”理念，很容易會(huì)降低?戶的體驗(yàn)，導(dǎo)致最后??也?點(diǎn)都不“Simple and Stupid”。

可見，這個(gè)設(shè)計(jì)原則?到軟件?業(yè)是有問題的，我們不能夠?yàn)榱恕癝imple and Stupid”去設(shè)計(jì)，不能夠設(shè)計(jì)?個(gè)系統(tǒng)時(shí)，依照“Simple and Stupid”為?標(biāo)去設(shè)計(jì)。因?yàn)樵O(shè)計(jì)?個(gè)系統(tǒng)的?的是為了更好的完成系統(tǒng)所服務(wù)的?戶的訪問，?不是為了設(shè)計(jì)者或者實(shí)施者。考慮設(shè)計(jì)者和實(shí)施者的時(shí)候，是在這個(gè)完成?戶訪問的前提下，怎么做到低成本的、可持續(xù)的迭代。因此，如果?個(gè)設(shè)計(jì)者不能夠理解?戶的需求，不能夠理解?戶通過不同的訪問?命周期來達(dá)到??的?的，是無法設(shè)計(jì)好?個(gè)系統(tǒng)的。

只有通過對(duì)?戶的業(yè)務(wù)?命周期、訪問?命周期進(jìn)?分析，根據(jù)流量的壓?不同，進(jìn)?合理的樹狀拆分，也因此形成不同的系統(tǒng)，那么這些所形成的系統(tǒng)?定是內(nèi)聚的，邊界?定是清晰的，也?定是“Simple and Stupid”。也就是說，只有從業(yè)務(wù)上去分析、去拆分，才能夠得到?個(gè)“Simple and Stupid”的結(jié)構(gòu)，這是?個(gè)副產(chǎn)品，?不是?標(biāo)。如果依照這個(gè)原則為?標(biāo)去設(shè)計(jì)，則可能會(huì)破壞業(yè)務(wù)本身的整體。

這個(gè)原則本身是從軍??業(yè)出來的，說明“Simple and Stupid”含義是有軍?背景的，有軍??業(yè)??的標(biāo)準(zhǔn)，讀者感興趣的話可以去研究?下。不去了解?個(gè)概念的歷史，盲?的直接引?到軟件?業(yè)來，很容易吃虧。?且其中“Stupid”的含義是為了形容系統(tǒng)組件的修理維護(hù)簡單程度，不知道這是不是這個(gè)原則提出者的“Simple and Stupid”的本意。按照這個(gè)意思，如果所設(shè)計(jì)的系統(tǒng)根本不允許或不需要考慮維護(hù)或者修理的話，還需要考慮“Simple and Stupid”嗎?反過來，我們回頭去審查?個(gè)系統(tǒng)的時(shí)候，如果發(fā)現(xiàn)所設(shè)計(jì)的系統(tǒng)對(duì)于?戶訪問的拆分不夠清晰，不是樹狀結(jié)構(gòu)的時(shí)候，那么?定是不夠“Simple and Stupid”的，倒是可以作為?個(gè)架構(gòu)審查的判斷點(diǎn)，幫助改進(jìn)設(shè)計(jì)，但是不能夠作為設(shè)計(jì)的依據(jù)。

?

SOLID 原則

---

SOLID 原則，據(jù) WikiPedia 所說是由 Robert C. Martin 總結(jié)的?向?qū)ο笤O(shè)計(jì)的原則。這個(gè)名字其實(shí)是以下?個(gè)原則的?字母簡寫：

• Single responsibility principle；

• Open/closed principle；

• Liskov substitution principle；

• Interface segregation principle；

• Dependency inversion principle。

“Single responsibility principle” ，翻譯成中?是“單?職責(zé)原則”。這也是?個(gè)缺乏主語的話，但推斷應(yīng)該是指所設(shè)計(jì)的系統(tǒng)吧，這個(gè)系統(tǒng)應(yīng)該是單?職責(zé)的。可是這個(gè)“職責(zé)”的“單?”，如何來判定呢?不同的?會(huì)有不同的認(rèn)知。據(jù)作者原?所給出的參考?章所描述的：“This principle was described in the work of Tom DeMarco and Meilir Page-Jones . They called it cohesion”，原本叫做 Cohesion，翻譯成中?是“內(nèi)聚”。說成內(nèi)聚很容易理解，但是作者給出的解釋是“A class should have only one reason to change”，就很難理解了。據(jù)給出的例?，說的是?個(gè)保齡球的游戲編程，原本 Game 類有兩個(gè)責(zé)任，?個(gè)是負(fù)責(zé)跟蹤當(dāng)前幀，?個(gè)是負(fù)責(zé)計(jì)算分?jǐn)?shù)，最后把這兩個(gè)責(zé)任分別給了兩個(gè)不同的類。作者給出這個(gè)拆分的理由是，“Because each responsibility is an axis of change”，意思是“因?yàn)槊總€(gè)職責(zé)是?個(gè)變化的維度”。猜想作者想表達(dá)的意思是兩個(gè)正交的維度，拆開可以互不影響的意思。

原本現(xiàn)實(shí)?活中打保齡球，可以??算分，也可以讓別?幫忙算。為什么可以拆分開來，這是因?yàn)榇虮｝g球的核??命周期是打球，算分只是?個(gè)游戲規(guī)則，沒有這個(gè)規(guī)則，保齡球也可以打的，因此這個(gè)分?jǐn)?shù)計(jì)算規(guī)則可以拆分出來。并且保齡球游戲產(chǎn)?的結(jié)果是計(jì)算分?jǐn)?shù)的輸入，這兩個(gè)步驟是打保齡球游戲的兩個(gè)連續(xù)的?命周期活動(dòng)，因此非核??命周期可以拆分出去，形成樹狀結(jié)構(gòu)。Game 的原本功能沒變，只不過其中?個(gè)步驟的實(shí)現(xiàn)分離出去，通過?法調(diào)?的?式回歸了?已。這樣 Game 的職責(zé)更專注，分?jǐn)?shù)計(jì)算也更專注，修改時(shí)可以互不影響，確實(shí)叫“內(nèi)聚”比較好。

可是?旦改成“單?職責(zé)”，意思就變化了。后?又把詳細(xì)解釋的內(nèi)容從“an axis of change”改成“one reason to change”，意思進(jìn)?步不同了。“an axis of change”指的是?個(gè)維度，?“one reason to change”指的是?種理由，?者很難等同，應(yīng)該是有很?的爭議的。

那么怎么樣才算“單?”呢?這個(gè)是沒有確定的標(biāo)準(zhǔn)的。Game 包含打球和算分兩個(gè)步驟，難道 Game 就不“單?”了嗎?保齡球要打球和算分的話，這是?個(gè)“單?”的運(yùn)動(dòng)，放在?起并不算職責(zé)不單?，這樣做并不錯(cuò)。但是后續(xù)修改和維護(hù)的角度來看，如果分?jǐn)?shù)計(jì)算規(guī)則要頻繁的修改，但不希望動(dòng) Game 的話，分?jǐn)?shù)計(jì)算可以拆分出來，這是?種架構(gòu)拆分，但并不是因?yàn)椤皢?職責(zé)”的緣由才拆分的。那么打球和分?jǐn)?shù)計(jì)算分離開來了后，難道分?jǐn)?shù)計(jì)算職責(zé)就“單?”了嗎?不?定，如果分?jǐn)?shù)計(jì)算有很多不同規(guī)則，還可以把規(guī)則做架構(gòu)拆分，分?jǐn)?shù)計(jì)算職責(zé)也并不“單?”呀。

因此，我們說“單?”職責(zé)，并不能表述“內(nèi)聚”的含義。?且“單?”是?個(gè)相對(duì)的詞語，要看針對(duì)什么來說是“單?”的。?個(gè)事情分兩個(gè)步驟，并不能說這個(gè)事情不“單?”，這是?個(gè)事情，是單?的。把這兩個(gè)步驟分開后，由兩個(gè)?來分別執(zhí)?，對(duì)于這兩個(gè)?來說，各?的職責(zé)是單?的，但是不能因此否認(rèn)原來這個(gè)事情就不“單?”了，因?yàn)檫@兩個(gè)?各?“單?”職責(zé)的完成，組成了原本的那個(gè)“單?”的事情。其實(shí)從原作者的本意來看，不過是想表述“內(nèi)聚”?已，“內(nèi)聚”這個(gè)詞最貼切。

從“單?”的思路去看，最近出現(xiàn)的 CQRS(Command Query Responsibility Segregation)，“命令查詢責(zé)任分離”，把命令和查詢拆分開來，分開后這個(gè)職責(zé)“單?”吧，可是這個(gè)做法卻完全破壞了業(yè)務(wù)本身的內(nèi)聚。還是前?那個(gè)保齡球的例?，想象?下算分和查詢分?jǐn)?shù)是不同的類，那么?旦算分的規(guī)則發(fā)?變化，那么查詢分?jǐn)?shù)的規(guī)則不?定能夠跟著算分來變化，Bug 就很容易出現(xiàn)。如果這兩個(gè)類分為兩個(gè)不同的?來維護(hù)的話，?旦出現(xiàn)問題的話，這兩個(gè)?就可以沒完沒了的扯?了，責(zé)任也很難分清楚，需要?量的溝通成本，最后?定會(huì)?團(tuán)糟，這就是破壞了業(yè)務(wù)本身的內(nèi)聚所帶來的后果。CQRS 這個(gè)做法往往是?于數(shù)據(jù)讀寫的場景，?于提升讀或?qū)懙男阅?#xff0c;只有當(dāng)讀、寫時(shí)不存在業(yè)務(wù)邏輯的時(shí)候、僅僅是做讀寫通道的拆分的時(shí)候才?的。

Open/closed principle ，也就是“開 / 閉原則”。作者總結(jié)了這個(gè)原則的發(fā)明者 Bertrand Meyer 的觀點(diǎn)“Software Entities (Classes, Modules, Functions, etc.)should be open for extension, but closed for modification.”，作者對(duì)這句話的理解是，?個(gè)模塊同時(shí)要能夠適應(yīng)新的變化，還要不允許修改，這是相沖突的。為解決這個(gè)沖突，作者得出?個(gè)?案，那就是?抽象類來解決這個(gè)問題。?抽象類則會(huì)帶來許許多多的其他問題，但仍然無法完全做到對(duì)修改關(guān)閉。

為什么會(huì)出現(xiàn)這個(gè)原則呢?從這個(gè)原則出現(xiàn)的時(shí)期來看，是在 1980 年代提出來的，猜想是因?yàn)檐浖?程不夠發(fā)達(dá)，開發(fā)?員懼怕改變所導(dǎo)致的。為什么要對(duì)修改關(guān)閉呢?因?yàn)楹ε滦薷乃鶐淼倪B鎖反應(yīng)。在早期的開發(fā)實(shí)踐中，沒有完善的版本控制、依賴管理等的幫助，無法承擔(dān)頻繁的修改所帶來的對(duì)項(xiàng)?的沖擊。另???，可能是想要去修改別?的代碼或者類庫，許多?如此的解釋。或許也有可能也不得?知。如果能夠去修改別?的代碼或者類庫，說明??已經(jīng)有源代碼了，??做好版本控制即可，可以??維護(hù)。如果想讓??的修改還要兼容別?的后續(xù)升級(jí)，無論是??修改還是繼承，都會(huì)遇到兼容的問題，這種情況最好的辦法是去請(qǐng)求原作者來修改，保持權(quán)責(zé)對(duì)等是成本最低的。??修改的話，就要做好??維護(hù)的準(zhǔn)備，并且后續(xù)升級(jí)的代價(jià)會(huì)比較?。可是為什么要去修改別?的代碼或類庫呢?如果是功能不滿?，就不要去?別?的代碼，換?個(gè)別的類庫或者??寫?個(gè)?如果是有 bug，就去請(qǐng)求原作者去修復(fù)，盡量不要??動(dòng)?修改?或者??參加進(jìn)去成為?個(gè)貢獻(xiàn)者也可以。總之要保持代碼創(chuàng)造者對(duì)其代碼的權(quán)責(zé)對(duì)等。

隨著現(xiàn)代開發(fā)理念的發(fā)展，越來越多的?看到了抽象、繼承的壞處，越來越多的?采?組合的?式來協(xié)作，其實(shí)抽象類可以看成是組合的?種特殊情況。?且隨著代碼的變化越來越頻繁，擁抱變化反?成為了?個(gè)風(fēng)?。只要代碼中的類做到了“內(nèi)聚”，只要業(yè)務(wù)代碼能夠做到內(nèi)聚、訪問通道做到不重?，那么要重?的只會(huì)是業(yè)務(wù)代碼，這樣修改的范圍會(huì)?很多，同時(shí)依靠版本與依賴管理，完全可以避免修改所產(chǎn)?的影響。因此這個(gè)“開 / 閉原則”，也需要重新再看待，理性使?。使?開閉原則，就意味著?量的抽象類、?量的繼承，意味著內(nèi)聚的喪失，意味著要付出耦合的代價(jià)。

Liskov substitution principle ，中?是“?氏代換原則”。前?的“開 / 閉原則”導(dǎo)致了抽象與繼承，“?氏代換原則”則是繼承的進(jìn)?步體現(xiàn)，也最終形成了多態(tài)的特性。作者總結(jié)了發(fā)明者 Barbara Liskov 的話“Function that use pointers or references to base class must be able to use objects of derived classes without knowing it”，意思就是?個(gè)功能如果引?的是某個(gè)?類，如果實(shí)際傳的是該?類的?個(gè)?類的話，這個(gè)功能本身的?為不會(huì)發(fā)?變化。這個(gè)原則是很多程序員喜歡抽象的?個(gè)理論來源，這?試著分析?下。

?氏代換原則的本意，應(yīng)該是對(duì)開閉原則的拓展，?來實(shí)現(xiàn)開閉原則。只有能夠??類來代換，才能夠符合開閉原則。但是總不能夠每次修改都創(chuàng)建?個(gè)?類吧?也因此可以看到，開閉原則也是?個(gè)無奈之舉。正確的做法是針對(duì)修改創(chuàng)建不同的版本，針對(duì)不同的版本來進(jìn)?構(gòu)建、發(fā)布。

但是有了這個(gè)代換的辦法，結(jié)果?家倒是不?來遵守開閉原則了，?是?來盡可能的抽象，結(jié)果把本來應(yīng)該內(nèi)聚在?個(gè)類中的?法和屬性，分散到許多不同的?類中去了，這是很?的?個(gè)弊病。記得以前 Java 認(rèn)證考試就專門考繼承時(shí)的變量初始化，許多?掉進(jìn)這個(gè)坑?。并且這種情況非常容易造成?產(chǎn)事故，因?yàn)檫@種錯(cuò)誤只有在運(yùn)?時(shí)才能夠發(fā)現(xiàn)，還不好排查，往往修改?類時(shí)，?類的 bug 就出現(xiàn)了。沒有做到內(nèi)聚的后果是很嚴(yán)重的。

另外?個(gè)問題是?氏代換的時(shí)候，比如?類中有 Instrument.play()?法，可以??類 Piano.play()，Violin.play() 來代換，雖然引??類時(shí)可以?作的很正常，但是 play() 出來的聲?卻是不確定的，因此也不能說?為沒有發(fā)?變化，只能說都能夠 play，但是 play 的結(jié)果是不?樣的。但是當(dāng)實(shí)際業(yè)務(wù)很復(fù)雜，不光要 play，后續(xù)還要調(diào)整具體的樂器的話，這個(gè)抽象就比較麻煩了，因?yàn)椴煌瑯菲髡{(diào)整各式各樣不同，然后就發(fā)現(xiàn)原來的抽象不夠?，要費(fèi)很???去進(jìn)?步抽象。慢慢的在業(yè)務(wù)的變化下，抽象就變成?團(tuán)糟了，最后連??也看不懂代碼了。

可是何必要花??去抽象呢?直接引?實(shí)際的樂器就好了。除非能夠做到?次抽象能夠適應(yīng)以后所有的變化，否則還是??實(shí)實(shí)的?對(duì)實(shí)際情況吧，哪怕有多個(gè)樂器需要選擇，寫個(gè) if-else 就好了，沒??代碼，并且還是可測試的，并且錯(cuò)誤是編譯期可以發(fā)現(xiàn)的，以后修改、擴(kuò)展也容易。為了這??代碼，引入那么多抽象，破壞“內(nèi)聚”不說，?氏代換時(shí)，?般都是運(yùn)?時(shí)才能確定的，反?導(dǎo)致運(yùn)?時(shí)探查問題的麻煩，同時(shí)，代碼也很難閱讀，沒?敢去修改，影響?活質(zhì)量。

Interface segregation principle ，即“接口隔離原則”。這個(gè)原則相當(dāng)于是預(yù)設(shè)了調(diào)?者與被調(diào)?者兩?的前提，對(duì)于調(diào)?者來講，被調(diào)?者的接口數(shù)量應(yīng)該最?化。這個(gè)原則其實(shí)就是通道訪問的隔離。在訪問通道上，不同的客戶端，不可以使?同樣的訪問通道，因?yàn)闀?huì)導(dǎo)致它們之間的訪問互相影響，這是很簡單的道理。比如?個(gè)居民?區(qū)的車道和??道必須要分離，否則兩者通道混雜的話，?定會(huì)出事情的，?會(huì)很容易有?命危險(xiǎn)，產(chǎn)?額外的問題。

可是為什么會(huì)變成?個(gè)?接口呢?恰恰就是為了要重?這個(gè)接口，以便讓各種不同的調(diào)?者來訪問。所以訪問通道上的重?是萬萬不可的，因此也會(huì)導(dǎo)致服務(wù)端會(huì)變成?個(gè)?接口，從?慢慢會(huì)變成團(tuán)隊(duì)之間的糾紛點(diǎn)，故障點(diǎn)。

Dependency inversion principle ，即“依賴倒置原則”。作者舉了?個(gè) Copy 的例?，本來是把字符從鍵盤 copy 到打印機(jī)，后來增加了需求要 copy 到磁盤，因此要重?Copy 的?法，以后可能還要有多個(gè)設(shè)備要讀寫，不希望 Copy 程序依賴設(shè)備，因此引入了?個(gè)抽象類，放在 Copy 程序和具體的設(shè)備之間。

其實(shí)這個(gè)例?的業(yè)務(wù)背景只是利?Copy 程序作了?個(gè)字符傳遞的通道，這個(gè)通道本身是沒有任何邏輯的。作者強(qiáng)制性的把不同設(shè)備之間的通道綁在了?起，相當(dāng)于是共享了設(shè)備之間 copy 的訪問通道，在業(yè)務(wù)上來說，這是不符合通道獨(dú)?的原則的，因?yàn)檫@些不同的通道可能是屬于不同的業(yè)務(wù)與不同的?戶，他們之間的需求后續(xù)可能會(huì)不?致，很有可能因?yàn)槟硞€(gè)通道的修改，導(dǎo)致其他的通道受到影響。

?這個(gè)例?僅僅是為了在編譯期間不依賴于設(shè)備?已，為了這個(gè)?的?花這么?的代價(jià)，有什么?的意義嗎?最終運(yùn)?期間對(duì)設(shè)備的依賴是逃不掉的。其實(shí)訪問通道依賴于設(shè)備是沒有關(guān)系的，因?yàn)橥ǖ罌]有邏輯，不需要測試。所以這種通道的共享是?個(gè)過度設(shè)計(jì)，根本沒有必要。?旦 copy 有??的邏輯、?且這個(gè)邏輯可能還與通道有關(guān)的話，那么這么多通道混雜在?起，反?額外的增加了復(fù)雜度。并且這個(gè) Copy 程序根本沒有必要重?，因?yàn)闆]有邏輯就沒有重?的價(jià)值。如果要從鍵盤寫到磁盤，不如重新寫?個(gè) CopytoDisk 更簡單，因?yàn)?戶可能不?樣，?起來也更簡單，也更獨(dú)?。

作者這個(gè) Copy 程序例?的場景可能舉的不好，但是依賴倒置也是有??的場景的，不是什么時(shí)候都需要。依賴倒置的做法，無非是在兩個(gè)步驟之間增加?個(gè)節(jié)點(diǎn)，其實(shí)就是作了?個(gè)架構(gòu)拆分，形成了?個(gè)新的訪問通道，形成了樹狀的結(jié)構(gòu)。這個(gè)依賴叫“倒置”也不太對(duì)，只不過變成了依賴中間增加的那個(gè)節(jié)點(diǎn)，避免了直接依賴?已，但是間接依賴還是在的。真正正確的架構(gòu)拆分，其依賴?定是樹狀的，從拆分的起點(diǎn)開始往樹的下層依賴，不會(huì)出現(xiàn)下層依賴上層的情況，甚至不會(huì)出現(xiàn)兄弟節(jié)點(diǎn)之間的依賴，因?yàn)樗麄兌际菑捻攲硬鸱窒聛淼?#xff0c;是?個(gè)訪問通道上的不同節(jié)點(diǎn)。

?旦發(fā)?架構(gòu)拆分，就意味著要管理這個(gè)新增加節(jié)點(diǎn)的?命周期，也意味著額外的成本。只有相依賴的兩?會(huì)對(duì)對(duì)?的?作造成影響的時(shí)候，才需要通過拆分增加?個(gè)節(jié)點(diǎn)，以便讓兩?可以獨(dú)?的?作，互不影響。并且增加的這個(gè)節(jié)點(diǎn)不?定是 Abstract 的，也可以是?個(gè)實(shí)體。?且建議?實(shí)體，不要?Abstract，因?yàn)橐蕾囉?Abstract 意味著依賴?個(gè)繼承樹，成本太?。?通俗的話說，盡量去?對(duì)正規(guī)公司，不要去依賴?包公司，層級(jí)越少，溝通越少，效率越?。所以，不要?開始就去架構(gòu)拆分，要根據(jù)當(dāng)時(shí)所?對(duì)的情況，合理的采?。

所以，對(duì)于 SOLID 原則，第?個(gè)其實(shí)是說內(nèi)聚，只是“單?職責(zé)”的提法不好。第?、第三個(gè)說的是繼承的問題，這是?向?qū)ο笳Z?的特性。繼承會(huì)有很多的坑，會(huì)破壞內(nèi)聚，也不?定合適。第四、第五個(gè)，其實(shí)說的是訪問通道的問題，只要做好訪問通道的隔離就不會(huì)有問題。如果?家從這些原則字?上的意思去理解，怕是要?入誤區(qū)了。

?

業(yè)務(wù)內(nèi)聚與訪問通道內(nèi)聚

---

當(dāng)然，很多?也會(huì)提到“?內(nèi)聚、低耦合”的原則。這個(gè)“?、低”的說法不夠嚴(yán)謹(jǐn)。只要某個(gè)業(yè)務(wù)的?命周期活動(dòng)不在?個(gè)類中確定，那么這個(gè)類就沒有形成內(nèi)聚，反之就是做到了內(nèi)聚。只要做到內(nèi)聚，就沒耦合了，就只有依賴關(guān)系，?且這個(gè)依賴是?個(gè)樹狀的結(jié)構(gòu)；只要沒做到內(nèi)聚，肯定耦合了，沒有?低之分，最后都會(huì)帶來麻煩，區(qū)別在于帶來麻煩的多少?已。所以?個(gè)應(yīng)?要么沒有內(nèi)聚，只有耦合，要么只有內(nèi)聚，沒有耦合，只有其中?個(gè)情況。

可是要做到業(yè)務(wù)的內(nèi)聚，卻離不開業(yè)務(wù)訪問通道的隔離，這個(gè)原則我把它稱作“訪問通道不重?”原則。觀察?者的關(guān)系可以發(fā)現(xiàn)，重?業(yè)務(wù)與重?訪問通道?者，只能夠選?個(gè)。因?yàn)橹?訪問通道會(huì)導(dǎo)致業(yè)務(wù)無法內(nèi)聚、也就無法重?；重?業(yè)務(wù)則會(huì)導(dǎo)致訪問通道無法重?。如果想兩者都達(dá)成，那么最后的結(jié)果?定是只成功的重?了訪問通道，?業(yè)務(wù)內(nèi)聚則?定會(huì)被破壞。

為什么會(huì)是這樣呢?因?yàn)?個(gè)事物對(duì)物理空間的占有是獨(dú)享的，?訪問通道則是事物跨越物理空間的通路。必須確保?戶對(duì)?個(gè)事物的訪問通道是獨(dú)享的，才能夠保證這個(gè)訪問通道是內(nèi)聚的。如果不同類型?戶的共享同?個(gè)訪問通道，就意味著訪問通道不再是獨(dú)占的了，這就是對(duì)訪問通道內(nèi)聚的破壞，最終這個(gè)訪問通道就變成?個(gè)不確定的通路，內(nèi)步?jīng)_突不斷、阻礙重重，?定會(huì)反應(yīng)到對(duì)業(yè)務(wù)內(nèi)聚的破壞。

比如?們做公共的交通?具，往往不允許帶寵物，這就是要遵守寵物和?類的訪問通道內(nèi)聚原則，因?yàn)閷櫸锖?類在狹窄的空間?共存，會(huì)產(chǎn)出非常多額外、不必要的沖突。所以我們說“內(nèi)聚”，絕對(duì)不能只提業(yè)務(wù)的內(nèi)聚，訪問也是?種獨(dú)特的業(yè)務(wù)，也需要達(dá)到內(nèi)聚的原則。也就是說，“訪問通道不重?”原則其實(shí)說的就是“訪問通道的內(nèi)聚”。

如果做好了業(yè)務(wù)的內(nèi)聚，并隔離不同類型客戶端對(duì)業(yè)務(wù)的訪問通道，形成訪問通道的內(nèi)聚，基本上程序就不會(huì)太差，代碼就會(huì)很穩(wěn)定。有了這個(gè)基礎(chǔ)，再根據(jù)運(yùn)營過程中所產(chǎn)?的瓶頸點(diǎn)，有針對(duì)性的做業(yè)務(wù)架構(gòu)拆分或訪問通道架構(gòu)拆分就很容易了。做為?個(gè)架構(gòu)設(shè)計(jì)師或者程序員，如果不把“內(nèi)聚”放在最重要的位置，最終?定會(huì)被需求給淹沒的。

因此，架構(gòu)設(shè)計(jì)的的核?原則就是“內(nèi)聚”，任何架構(gòu)原則都不能違反此原則。這個(gè)“內(nèi)聚”包括兩部分：“業(yè)務(wù)內(nèi)聚”，“業(yè)務(wù)訪問通道內(nèi)聚”。所以，對(duì)于我們遇到的任何?個(gè)架構(gòu)原則都可以這樣去判斷：如果發(fā)現(xiàn)它違反了“業(yè)務(wù)內(nèi)聚”原則，我們都要三思，因?yàn)闀?huì)導(dǎo)致業(yè)務(wù)分散、無法重??如果它違反“業(yè)務(wù)訪問通道內(nèi)聚”原則，也就是“業(yè)務(wù)訪問通道不重?”原則，我們也要三思，不要去追求訪問通道重?。

“訪問通道內(nèi)聚”原則是軟件?業(yè)普遍忽視的，這個(gè)原則太不起眼，也太容易被破壞，?家都忽視了。“訪問通道內(nèi)聚”的缺失?定會(huì)導(dǎo)致“業(yè)務(wù)內(nèi)聚”原則的破壞，導(dǎo)致業(yè)務(wù)無法重?。于是，系統(tǒng)就開始陷入困境了。

總結(jié)

以上是生活随笔為你收集整理的对一些架构设计原则的反思的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。