https:///entry/5bdf0b86e51d457ccd3f6498?utm_source=gold_browser_extension

組件耦合

上回說到組件聚合，反映的是組件內(nèi)部的“基本元素”的選擇標(biāo)準。第14章介紹的組件耦合則是指組件和組件之間的關(guān)系，這些依賴關(guān)系有些是好的，有些是不好的，我們即將看到的這些原則就是在澄清什么是好的依賴標(biāo)準。

本章關(guān)鍵點

1. ADP（Acyclic Dependencies Principle 無依賴環(huán)原則）
2. SDP（Stable Dependencies Principle 穩(wěn)定依賴原則）
3. SAP（Stable Abstractions Principle 穩(wěn)定抽象原則）

依賴即信任

依賴關(guān)系其實就是一種信任關(guān)系這句話是我總結(jié)出來的。為什么大家篤信一個事實——當(dāng)很多比你聰明的人都開始投身某個新領(lǐng)域時，沒錯，我說的是區(qū)塊鏈，這個領(lǐng)域一定會成為未來。因為在我看來，每個投身其中的聰明人都在筑成一條新的依賴關(guān)系，依賴愈來愈多，底層建筑就會愈加穩(wěn)定，穩(wěn)定是信任的基礎(chǔ)，進而會吸引更多的優(yōu)秀人才投身其中，形成規(guī)模效應(yīng)。就像為什么那么多人敢用支付寶和微信支付？這種信任感不僅僅來源于背后的大廠品牌，還來自于廣泛的用戶群體。每次用戶完成的安全支付，其實都在加固信任感。

區(qū)塊鏈，所謂的降本增效，構(gòu)建完善的征信體系，也是同樣的道理。一次不可篡改的交易積累不出信任感，但是一千次，一百萬次，以至于每個人一生中所有的交易記錄都不可篡改地被記錄下來，那么這個人的信譽體系就建立起來了。當(dāng)一個行業(yè)，甚至國家的所有交易數(shù)據(jù)都被記錄下來，征信體系自然而然就完善了。

這樣的例子，我還可以舉出很多，放到軟件開發(fā)行業(yè)更加淺顯易懂。我見過兩個不同團隊構(gòu)建了具有依賴關(guān)系的兩個微服務(wù)，雖然服務(wù)可以輕松通過API的方式進行通訊，但是因為雙方對彼此服務(wù)可用性的不信任，他們選擇在兩個服務(wù)之間建立高可用的消息隊列。一個服務(wù)發(fā)布數(shù)據(jù)消息，另一個訂閱。這個看似良好解耦的方案其實不過是妥協(xié)的結(jié)果。因為不信任所以不去依賴，不去依賴導(dǎo)致根本不肯信任，就這樣形成了惡性循環(huán)。

還有上回在組件聚合原則中提到REP（復(fù)用發(fā)布等同原則），其實組件的發(fā)布也類似一種發(fā)布、訂閱模式。這種模式將緊耦合的源代碼級別的依賴，轉(zhuǎn)換成了對版本號、發(fā)布文檔的依賴關(guān)系。發(fā)布團隊可以在自己的私有倉庫里繼續(xù)開發(fā)，而訂閱團隊則可以自行決定升級與否。這種做法本質(zhì)上是把對代碼的依賴反轉(zhuǎn)到對版本發(fā)布的依賴上。發(fā)布的產(chǎn)出物是穩(wěn)定的，因此值得信任，所以才可以安全地放到自己的代碼中。

現(xiàn)在的軟件開發(fā)過程，引用第三方組件已經(jīng)是司空見慣的事情，而且必不可少，這也是軟件復(fù)用的初衷。稍微開發(fā)大型的軟件系統(tǒng)，就會涉及依賴多種組件，這些關(guān)系有時候會變得錯綜復(fù)雜，處理起來也是一件麻煩事。比如，在Java工程中，偶爾會處理某個組件的多版本沖突。這個問題是由于Maven等依賴管理工具允許傳遞依賴（transitive depenency）造成的，一般解決方案是將某個版本從依賴它的組件內(nèi)部排除掉。眾多依賴的問題中，最不能接受的是循環(huán)依賴。

ADP 無依賴環(huán)原則

組件依賴關(guān)系圖中不應(yīng)該出現(xiàn)環(huán)

在組件之間，循環(huán)依賴導(dǎo)致的問題是任何組件的變更必然導(dǎo)致其它組件同時變更。我們試想一種組件之間沒有依賴的場景，每個組件在這里都能獨立的變更而不影響其它組件。再試想一種只有單向的依賴的場景，被依賴的組件發(fā)生變更勢必會影響依賴它的組件，所以我們會小心翼翼，盡量減少這種組件發(fā)布的頻率。而此時，依賴方的變更卻是自由的。在雙向（循環(huán)）依賴存在的場景中，任何一方的變更導(dǎo)致的影響幾乎相當(dāng)于粒子回旋加速器造成的動能，這樣的結(jié)果是幾乎無法得到任何一個組件穩(wěn)定可用的版本。

我們知道，在編碼時，類與類之間是不應(yīng)該有互相依賴的，因為循環(huán)依賴往往會導(dǎo)致類加載器陷入加載的死循環(huán)，它相當(dāng)于遇到了先有雞，還是先有蛋的難題。不過，循環(huán)依賴問題是可以消除的，而這恰恰是DIP（依賴反轉(zhuǎn)原則）大顯身手的地方。

DIP原則指導(dǎo)我們在組件出現(xiàn)循環(huán)依賴的時候可以有兩種消除方式。

第一種是產(chǎn)生循環(huán)依賴的組件內(nèi)聲明接口，將它依賴的組件反轉(zhuǎn)成依賴自己的接口。這種方式，不僅破除了循環(huán)依賴，同時也避免生成新的組件。

第二種是生成新的組件，讓互相依賴的雙方都來指向它。適配器模式就是一個很好的詮釋。何時生成一個新的組件？這種問題需要利用上回提到的組件聚合原則^[1]來解答，此處不再贅述。

SDP 穩(wěn)定依賴原則

依賴關(guān)系必須指向更穩(wěn)定的方向

穩(wěn)定是相對于不穩(wěn)定而言，不穩(wěn)定是因為組件老是要變更，如果用根因分析，頻繁變更的很快就會上升到需求易變PM不是人的高度。不過，一定需要澄清的是：需求總歸是要變的。不能快速響應(yīng)需求變更的軟件架構(gòu)是一潭死水，也就沒有實施任何設(shè)計原則的必要了。

既然“向外求玄”不可得，那么“反求諸己”好歹也是條路。鮑勃大叔說，穩(wěn)定是因為依賴的足夠多。你先撇開一臉黑線和心中的碎碎念：我考察“什么是穩(wěn)定”的目的是想找到穩(wěn)定的方向再去依賴它，你這會兒告訴我，依賴的足夠多就穩(wěn)定了？那么問題來了，先有雞，還是先有蛋？

我當(dāng)時也被這種觀點嚇得虎軀一震，心中一陣翻滾。鮑勃大叔提出這種觀點的自信到底從何而來？稍微靜下心，我們捋一捋他的思路。在闡述上述ADP原則時，鮑勃大叔從消除循環(huán)依賴的過程中總結(jié)出一個有點遺憾的結(jié)論：組件結(jié)構(gòu)圖不可能自上而下被設(shè)計出來。原因是它必須跟隨軟件系統(tǒng)的變化而變化和擴張。雖然人們普遍以為項目組粒度的組件分組規(guī)則所產(chǎn)生的就是組件的依賴結(jié)構(gòu)，但事實上，組件依賴結(jié)構(gòu)圖并不是用來描述應(yīng)用程序功能的，它更像是應(yīng)用程序在構(gòu)建性和維護性方面的一張地圖。結(jié)合我前面提到的依賴即信任的觀點，不難發(fā)覺穩(wěn)定是軟件系統(tǒng)變化過程中逐漸沉淀出來的，組件不斷被拆合，依賴不斷被分解，被依賴的最多的組件才會慢慢浮現(xiàn)。

怎么界定組件的穩(wěn)定程度呢？既然利用了依賴多寡的指標(biāo)，那就可以很方便的構(gòu)造出一個不穩(wěn)定函數(shù)：

Fan-in指的是外部指向組件的類的數(shù)量，相反，F(xiàn)an-out指的是組件內(nèi)部指向外部組件的類的數(shù)量。用圖相關(guān)的知識解釋，F(xiàn)an-in是節(jié)點的入度，F(xiàn)an-in是節(jié)點的出度。當(dāng)I=0時，表示組件最穩(wěn)定，因為只有入度沒有出度；I=1時，組件最不穩(wěn)定，此時只有出度而沒有入度。

SAP 穩(wěn)定抽象原則

一個組件的抽象化程度應(yīng)該與其穩(wěn)定性保持一致

軟件系統(tǒng)中，總有一部分內(nèi)容不應(yīng)該經(jīng)常發(fā)生變化，比如：DDD方法論中領(lǐng)域和子域。這部分應(yīng)該放到較為穩(wěn)定的組件里被其它組件依賴。但是這也導(dǎo)致一個很棘手的問題，如果這部分發(fā)生了變化，那影響的范圍將是巨大的。

怎么辦？OCP原則閃亮登場，既然我們知道對修改封閉，對擴展開放，擴展也是擁抱變化的一種手段。所以穩(wěn)定和抽象具有一種妙不可言的聯(lián)系，這種聯(lián)系要求穩(wěn)定的組件也應(yīng)該是抽象的，雖然不易修改，但是容易擴展。

SDP和SAP合到一起就是DIP在組件級別的詮釋。SDP告訴我們要朝著穩(wěn)定的方向依賴，而SAP則告訴我們穩(wěn)定的方向蘊含著抽象的要求。所以依賴也應(yīng)該朝著抽象的方向。

如何衡量組件的抽象化程度？抽象類和接口的占比就是很好的指標(biāo)：

其中，A是抽象化程度函數(shù)。Na是組件中抽象類和接口的數(shù)量，Nc是組件中所有類的數(shù)量。當(dāng)A=0時，表明組件抽象程度最低，沒有抽象類；A=1時，表明組件抽象程度最高，因為內(nèi)部全是抽象類或接口。

既然依賴應(yīng)該朝著穩(wěn)定和抽象的方向，那么這兩方面制約因素就要求組件的穩(wěn)定性和抽象程度具有合力。這個合力的最優(yōu)位置就是上圖中斜率為-1的那條直線上。

我們注意，坐標(biāo)(0, 0)表示組件無抽象但穩(wěn)定。穩(wěn)定意味著很難修改，再加上不夠抽象，所以也無法擴展。這往往是軟件系統(tǒng)維護難以為繼的根源。所以那塊區(qū)域被稱為痛苦區(qū)。

坐標(biāo)(1, 1)表明組件很抽象但極不穩(wěn)定，不穩(wěn)定就是說它只會依賴其它組件但不被任何組件依賴，那么這種情況下的抽象通常是無用的。最典型的例子就是某些抽象類孤零零地躺在代碼的角落里，無人問津，美其名曰方便以后擴展，但是我們深刻地知道，YAGNI（You Ain't Gonna Need It）。所以那塊區(qū)域被叫做無用區(qū)。

小結(jié)

組件之間的耦合應(yīng)該遵循上述原則的約束，所謂原則就是優(yōu)秀架構(gòu)應(yīng)該有的模樣。同時，我們也解答了“自頂而下”的設(shè)計不靠譜的深層次原因。

其實，在我看來，組件的耦合和聚合并不是一刀切的關(guān)系，SAP原則同樣指導(dǎo)了每個組件內(nèi)部應(yīng)該具備怎樣的抽象程度，它也更加鞏固了組件結(jié)構(gòu)圖一定會不斷演化的觀點。

我們講了這么多回，從基礎(chǔ)構(gòu)件^[2]談到組件，就好比有了磚頭，切成了一個個獨立的房間，那么如何安排這些房間構(gòu)造出一幢幢高樓大廈就是下回需要聊到的話題。想知道，什么是軟件架構(gòu)？且聽下回分解。

于 2018-11-04

1. 架構(gòu)整潔之道導(dǎo)讀（二）組件聚合 ?

2. 架構(gòu)整潔之道導(dǎo)讀（一）編程范式 ?