第4部分 組件構建原則

如果說SOLID原則是用于指導我們如何將磚塊砌成墻與房間的，那么組件構建原則就是用來指導我們如何將這些房間組合成房子的，

第12章 組件

組件是軟體的部署單元，是整個軟體系統在部署程序中可以獨立完成部署的最小物體，

在編譯運行語言中，組件是一組二進制檔案的集合，而在解釋運行語言中，組件則是一組源代碼檔案的集合，無論采用什么編程語言來開發軟體，組件都是該軟體在部署程序中的最小單元，

但無論采用哪種部署形式，設計良好的組件都應該永遠保持可被獨立部署的特性，這同時也意味著這些組件應該可以被單獨開發，

程式的規模會一直不斷地增長下去，直到將有限的編譯和鏈接時間填滿為止，

我們常常會在程式運行時插入某些動態鏈接檔案，這些動態鏈接檔案所使用的就是軟體架構中的組件概念，

組件化的插件式架構已經成為我們習以為常的軟體構建形式了，

第13章 組件聚合

與構建組件相關的三個基本原則：

• REP：復用/發布等同原則，
• CCP：共同閉包原則，
• CRP：共同復用原則，

復用/發布等同原則(REP)

軟體復用的最小粒度應等同于其發布的最小粒度，

從軟體設計和架構設計的角度來看，REP原則就是指組件中的類與模塊必須是彼此緊密相關的，也就是說，一個組件不能由一組毫無關聯的類和模塊組成，它們之間應該有一個共同的主題或者大方向，

共同閉包原則(CCP)

我們應該將那些會同時修改，并且為相同目的而修改的類放到同一個組件中，而將不會同時修改，并且不會為了相同目的而修改的那些類放到不同的組件中，

CCP原則也認為一個組件不應該同時存在著多個變更原因，

CCP的主要作用就是提示我們要將所有可能會被一起修改的類集中在一處，也就是說，如果兩個類緊密相關，不管是源代碼層面還是抽象理念層面，永遠都會一起被修改，那么它們就應該被歸屬為同一個組件，

與SRP的相似點：在SRP原則的指導下，我們將會把變更原因不同的函式放入不同的類中，而CCP原則指導我們應該將變更原因不同的類放入不同的組件中，簡而言之，這兩個原則都可以用以下一句簡短的話來概括：將由于相同原因而修改，并且需要同時修改的東西放在一起，將由于不同原因而修改，并且不同時修改的東西分開，

共同復用原則(CRP)

不要強迫一個組件的用戶依賴他們不需要的東西，

CRP原則實際上是在指導我們：不是緊密相連的類不應該被放在同一個組件里，

與與ISP原則的關系：ISP原則是建議我們不要依賴帶有不需要的函式的類，而CRP原則則是建議我們不要依賴帶有不需要的類的組件，上述兩條建議實際上都可以用下面一句話來概括：不要依賴不需要用到的東西，

組件聚合張力圖

一般來說，一個軟體專案的重心會從該三角區域的右側開始，先期主要犧牲的是復用性，然后，隨著專案逐漸成熟，其他專案會逐漸開始對其產生依賴，專案重心就會逐漸向該三角區域的左側滑動，換句話說，一個專案在組件結構設計上的重心是根據該專案的開發時間和成熟度不斷變動的，我們對組件結構的安排主要與專案開發的進度和它被使用的方式有關，與專案本身功能的關系其實很小，

本章小結

在決定將哪些類歸為同一個組件時，必須要考慮到研發性與復用性之間的矛盾，并根據應用程式的需要來平衡這兩個矛盾，

這種平衡本身也在不斷變化，也就是說，當下適用的分割方式可能明年就不再適用了，所以，組件的構成安排應隨著專案重心的不同，以及研發性與復用性的不同而不斷演化，

第14章 組件耦合

三條組件之間關系的原則:

• 無依賴環原則
• 穩定依賴原則
• 穩定抽象原則

無依賴環原則

組件依賴關系圖中不應該出現環，

不管我們從該圖中的哪個節點開始，都不能沿著這些代表了依賴關系的邊最終走回到起始點，也就是說，這種結構中不存在環，我們稱這種結構為有向無環圖（Directed AcyclicGraph，簡寫為DAG），

只有消除回圈依賴，才能消除團隊之間相互依賴的情況，進而進行獨立開發，

打破回圈依賴

下面是一個回圈依賴的例子，右下角的Authorizer, Interactors, Entities形成了回圈依賴，

目前有以下兩種主要機制可以做到這件事情，

• 1．應用依賴反轉原則（DIP）

將Entities與Authorizer之間的依賴關系反轉，

• 2.創建一個新的組件，并讓Entities與Authorize這兩個組件都依賴于它，
  

自上而下的設計

組件結構圖是不可能自上而下被設計出來的，它必須隨著軟體系統的變化而變化和擴張，而不可能在系統構建的最初就被完美設計出來，

組件依賴結構圖并不是用來描述應用程式功能的，它更像是應用程式在構建性與維護性方面的一張地圖，這就是組件的依賴結構圖不能在專案的開始階段被設計出來的原因——當時該專案還沒有任何被構建和維護的需要，自然也就不需要一張地圖來指引，

組件結構圖中的一個重要目標是指導如何隔離頻繁的變更，我們不希望那些頻繁變更的組件影響到其他本來應該很穩定的組件，

組件依賴關系是必須要隨著專案的邏輯設計一起擴張和演進的，

穩定依賴原則（SDP）

依賴關系必須要指向更穩定的方向，

通過遵守穩定依賴原則（SDP），我們就可以確保自己設計中那些容易變更的模塊不會被那些難于修改的組件所依賴，

穩定性

讓軟體組件難于修改的一個最直接的辦法就是讓很多其他組件依賴于它，帶有許多入向依賴關系的組件是非常穩定的，因為它的任何變更都需要應用到所有依賴它的組件上，

在圖14.5中，X不依賴于任何組件，所以不會有任何原因導致它需要被變更，我們稱它為“獨立”組件，

圖14.6中，Y同時依賴于三個組件，所以它的變更就可能由三個不同的源產生，這里就說Y是有依賴性的組件，

穩定性指標

究竟該如何來量化一個組件的穩定性呢？其中一種方法是計算所有入和出的依賴關系，通過這種方法，我們就可以計算出一個組件的位置穩定性（positionalstability），

• Fan-in：入向依賴，這個指標指代了組件外部類依賴于組件內部類的數量，
• Fan-out：出向依賴，這個指標指代了組件內部類依賴于組件外部類的數量，
• I：不穩定性

I=Fan-out/（Fan-in + Fan-out），

該指標的范圍是[0,1], I=0意味著組件是最穩定的，I=1意味著組件是最不穩定的，

當I指標等于1時，說明沒有組件依賴當前組件（Fan-in=0），同時該組件卻依賴于其他組件（Fan-out＞0），這是組件最不穩定的一種情況，我們認為這種組件是“不負責的（irresponsible）、對外依賴的（dependent）”由于這個組件沒有被其他組件依賴，所以自然也就沒有力量會干預它的變更，同時也因為該組件依賴于其他組件，所以就必然會經常需要變更，

當I=0的時候，說明當前組件是其他組件所依賴的目標（Fan-in＞0），同時其自身并不依賴任何其他組件（Fan-out=0），我們通常認為這樣的組件是“負責的（responsibile）、不對外依賴的（independent）”，這是組件最具穩定性的一種情況，其他組件對它的依賴關系會導致這個組件很難被變更，同時由于它沒有對外依賴關系，所以不會有來自外部的變更理由，

穩定依賴原則（SDP）的要求是讓每個組件的I指標都必須大于其所依賴組件的I指標，也就是說，組件結構依賴圖中各組件的I指標必須要按其依賴關系方向遞減，

并不是所有組件都應該是穩定的

如果一個系統中的所有組件都處于最高穩定性狀態，那么系統就一定無法再進行變更了，這顯然不是我們想要的，事實上，我們設計組件架構圖的目的就是要決定應該讓哪些組件穩定，讓哪些組件不穩定，

抽象組件

抽象組件通常會非常穩定，可以被那些相對不穩定的組件依賴，

穩定抽象原則（SAP）

一個組件的抽象化程度應該與其穩定性保持一致，

高階策略應該放在哪

代表了系統高階策略的組件應該被放到穩定組件（I=0）中，而不穩定的組件（I=1）中應該只包含那些我們想要快速和方便修改的部分，

如何才能讓一個無限穩定的組件（I=0）接受變更呢？開閉原則（OCP）為我們提供了答案，這個原則告訴我們：創造一個足夠靈活、能夠被擴展，而且不需要修改的類是可能的，而這正是我們所需要的，哪一種類符合這個原則呢？答案是抽象類，

穩定抽象原則簡介

穩定抽象原則（SAP）為組件的穩定性與它的抽象化程度建立了一種關聯，一方面，該原則要求穩定的組件同時應該是抽象的，這樣它的穩定性就不會影響到擴展性，另一方面，該原則也要求一個不穩定的組件應該包含具體的實作代碼，這樣它的不穩定性就可以通過具體的代碼被輕易修改，

如果一個組件想要成為穩定組件，那么它就應該由介面和抽象類組成，以便將來做擴展，

將SAP與SDP這兩個原則結合起來，就等于組件層次上的DIP，因為SDP要求的是讓依賴關系指向更穩定的方向，而SAP則告訴我們穩定性本身就隱含了對抽象化的要求，即依賴關系應該指向更抽象的方向，

衡量抽象化程度

假設A指標是對組件抽象化程度的一個衡量，它的值是組件中抽象類與介面所占的比例，

• Nc：組件中類的數量，
• Na：組件中抽象類和介面的數量，
• A：抽象程度

A = Na / Nc

A指標的取值范圍是從0到1，值為0代表組件中沒有任何抽象類，值為1就意味著組件中只有抽象類，

主序列

下面的I/A圖中，最穩定的、包含了無限抽象類的組件應該位于左上角（0,1），最不穩定的、最具體的組件應該位于右下角（1,0），

14.13為I/A圖中的區域劃分

痛苦區

假設某個組件處于（0,0）位置，那么它應該是一個非常穩定但也非常具體的組件，這樣的組件在設計上是不佳的，因為它很難被修改，這意味著該組件不能被擴展，這樣一來，因為這個組件不是抽象的，而且它又由于穩定性的原因變得特別難以被修改，我們并不希望一個設計良好的組件貼近這個區域，因此（0,0）周圍的這個區域被我們稱為痛苦區（zone of pain），

不可變組件落在（0,0）這一區域中是無害的，因為它們不太可能會發生變更，正因為如此，只有多變的軟體組件落在痛苦區中才會造成麻煩，而且組件的多變性越強，造成的麻煩就會越大，

無用區

靠近（1,1）這一位置點的組件不會是我們想要的，因為這些組件通常是無限抽象的，但是沒有被其他組件依賴，這樣的組件往往無法使用，因此我們將這個區域稱為無用區，

主序列線（mainsequence）

在整條主序列線上，組件所能處于最優的位置是線的兩端，一個優秀的軟體架構師應該爭取將自己設計的大部分組件盡可能地推向這兩個位置，

離主序列線的距離

D指標：

距離 D=|A+I-1|

該指標的取值范圍是[0,1]，值為0意味著組件是直接位于主序列線上的，值為1則意味著組件在距離主序列最遠的位置，

通過計算每個組件的D指標，就可以量化一個系統設計與主序列的契合程度了，另外，我們也可以用D指標大于0多少來指導組件的重構與重新設計，

對于一個良好的系統設計來說，D指標的平均值和方差都應該接近于0，

在圖14.14中，我們可以看到大部分的組件都位于主序列附近，但是有些組件處于平均值的標準差（Z=1）以外，這些組件值得被重點分析，它們要么過于抽象但依賴不足，要么過于具體而被依賴得太多，

D指標的另外一種用法是按時間來跟蹤每個組件的值，如果某個組件在某版本時的D值超過了達標紅線，則需要進行重點關注，