一個出發(fā)點(diǎn)

當(dāng)談起軟件設(shè)計(jì)的目的時(shí)，能夠獲得所有人認(rèn)同的答案只有一個：功能實(shí)現(xiàn)。 因?yàn)檫@是一個軟件存在的根本原因。

而在計(jì)算機(jī)軟件發(fā)展的初期，這一點(diǎn)也正是所有人做軟件設(shè)計(jì)的唯一動機(jī)。因而，很自然的，整個軟件都被放在單一過程中，然后用到處存在的goto語句控制流程。

盡管理論上講，任意復(fù)雜的系統(tǒng)都可以被放入同一個函數(shù)里。但隨著軟件越來復(fù)雜，即便是智商最為發(fā)達(dá)的程序員也發(fā)現(xiàn)，單一過程的復(fù)雜度已經(jīng)超出他的掌控極限。這逼迫人們必須對大問題進(jìn)行分解，分而治之。

時(shí)至今日，盡管超大函數(shù)，上帝類依然并不罕見，但當(dāng)大到一定程度，上帝類的創(chuàng)造者最終也會發(fā)現(xiàn)自己終究沒有上帝般的掌控力。因而，哪怕是軟件設(shè)計(jì)素養(yǎng)為負(fù)值的開發(fā)者，或多或少也會對一個復(fù)雜系統(tǒng)進(jìn)行一定程度的拆分。

這就是模塊化設(shè)計(jì)的最初動機(jī)。

兩個問題

一旦人們開始進(jìn)行進(jìn)行模塊化拆分，就必須解決如下兩個問題:

1. 究竟軟件模塊該怎樣劃分才是合理的?
2. 將一個大單元劃分為多個小單元之后，它們之間必然要通過銜接點(diǎn)進(jìn)行合作。如果我們把這些銜接點(diǎn)看作API，那么問題就變?yōu)椋涸鯓佣xAPI才是合理的?

更簡單的說：怎么分？然后再怎么合？

分工與合作

而這兩個問題的答案，正是現(xiàn)代軟件設(shè)計(jì)的核心關(guān)注點(diǎn)。

三方關(guān)系

為了找到這兩個問題的答案，我們需要重新回到最初的問題：為何要做軟件設(shè)計(jì)?

Kent Beck給出的答案是：軟件設(shè)計(jì)是為了在讓軟件在長期范圍內(nèi)容易應(yīng)對變化。

在這個精煉的定義中，包含著三個關(guān)鍵詞：長期，容易，變化。這意味著:

1. 越是需要長期維護(hù)的項(xiàng)目，變化更多，也更難預(yù)測變化的方式;
2. 軟件設(shè)計(jì)，事關(guān)成本;
3. 如何在難以預(yù)測的千變?nèi)f化中，保持低廉的變更成本，正是軟件設(shè)計(jì)要解決的問題。

對此，Kent Beck提出了一個更為精煉的原則：局部化影響。意思是說：我們希望，任何一個變化，對于我們當(dāng)前的軟件設(shè)計(jì)影響范圍都可以控制在一個盡量小的局部。

這當(dāng)然是所有嚴(yán)肅的軟件從業(yè)者都夢寐以求的。

可問題在于，如何才能做到?

內(nèi)聚與耦合

每個讀過基礎(chǔ)軟件工程教程的人都知道：一個易于應(yīng)對變化的軟件設(shè)計(jì)應(yīng)該遵從高內(nèi)聚，低耦合原則。

所謂內(nèi)聚性，關(guān)注的是一個軟件單位內(nèi)部的關(guān)聯(lián)緊密程度。因而高內(nèi)聚追求的是關(guān)聯(lián)緊密的事物應(yīng)該被放在一起，并且只有關(guān)聯(lián)緊密的事物才應(yīng)該被放在一起。簡單說，就是Unix的設(shè)計(jì)哲學(xué)：

Do One Thing, Do It Well。

而耦合性，則是強(qiáng)調(diào)兩個或多個軟件單位之間的關(guān)聯(lián)緊密程度。因而低耦合追求的是，軟件單位之間盡可能不要相互影響。

這樣的解釋，對于很多人而言，依然會感到過于抽象。但如果我們進(jìn)一步思考，就會意識到：看似神秘的內(nèi)聚與耦合，正好對應(yīng)最初的兩個問題:

1. 當(dāng)我們劃分模塊時(shí)，要讓每個模塊都盡可能高內(nèi)聚;
2. 而當(dāng)我們定義模塊之間的API時(shí)，需要讓雙方盡可能低耦合。

如果用圖來展現(xiàn)，就是下面的過程與關(guān)系:

高內(nèi)聚，低耦合

這幅圖揭示了模塊化設(shè)計(jì)的全部：首先將一個低內(nèi)聚的模塊首先拆分為多個高內(nèi)聚的模塊；然后再考慮這多個模塊之間的API設(shè)計(jì)，以降低這些高內(nèi)聚的軟件單元之間的耦合度。

除了內(nèi)聚與耦合之外，上面這幅圖還揭示了另外一種關(guān)系：正交。具備正交關(guān)系的兩個模塊，可以做到一方的變化不會影響另外一方的變化。換句話說，雙方各自獨(dú)自變化，互不影響。

而這幅圖的右側(cè)，正是我們模塊化的目標(biāo)。它描述了永恒的三方關(guān)系：客戶，API，實(shí)現(xiàn)，以及它們之間的關(guān)系。這個三方關(guān)系圖清晰的指出了我們應(yīng)該關(guān)注的內(nèi)聚性，耦合性，以及正交性都發(fā)生在何處。

四個策略

相對于局部化影響，高內(nèi)聚,低耦合原則已經(jīng)清晰和具體許多。但依然更像是在描述目標(biāo)或結(jié)果，而沒有指明該如何達(dá)成的方法。雖然《代碼大全》列舉了那么多的內(nèi)聚性和耦合性的分類，但對于想應(yīng)用它們的軟件設(shè)計(jì)人員，依然感覺如隔靴撓癢，不得要領(lǐng)。

因而，我們需要從它推導(dǎo)出更為明確，更具指導(dǎo)性和操作性的設(shè)計(jì)原則。

為了做到這一點(diǎn)，我們必須首先搞清楚：內(nèi)聚與耦合，和變化之間的關(guān)系是怎樣的，以至于高內(nèi)聚、低耦合的模塊化方式能夠更容易應(yīng)對變化？

我們再次回顧內(nèi)聚與耦合的定義：它們是用來衡量代碼元素之間的關(guān)聯(lián)緊密程度。很容易得知：元素之間的關(guān)聯(lián)緊密程度越高，一個變化引起它們相互之間都發(fā)生變化的可能性就越高。反之，關(guān)聯(lián)程度越弱，變化引起的連鎖變化的概率就越低。

因而，我們要把容易互相影響的、關(guān)聯(lián)程度緊密的元素，都封裝在一個模塊內(nèi)部（而這正是我們老生常談的封裝變化的動機(jī)）；同時(shí)讓模塊之間的關(guān)聯(lián)緊密程度盡可能降低，以讓模塊間盡可能不要相互影響。從而最終做到局部化影響。

因而，Uncle Bob說：一個類只應(yīng)該有一個變化原因。他進(jìn)一步談到：所謂一個變化原因，指一個變化會導(dǎo)致整個類所包含的各個元素都要發(fā)生變化。為何會如此？因?yàn)樗鼈兊年P(guān)聯(lián)程度太緊密(因而高內(nèi)聚)，以至于牽一發(fā)而動全身。

因此，Uncle Bob將職責(zé)定義為變化原因。

在一些時(shí)候，我們可以直接判定一個模塊是否包含多重職責(zé)。因?yàn)樗鼈兇_實(shí)包含著明顯沒有什么關(guān)聯(lián)的兩組代碼元素。

但在另外一些場景下，我們則無法清晰的判定：一個模塊是否真的包含多重變化原因，或多重職責(zé)。比如如下代碼:

struct Student 
{
  char name[MAX_NAME_LEN];
  unsigned int height; 
};

void sort_students_by_height(Student students[], size_t num_of_students) 
{
  for(size_t y=0; y < num_of_students-1; y++) 
  {
    for(size_t x=1; x < num_of_students - y; x++) 
    {
      if(students[x].height > students[x-1].height) 
      { 
        SWAP(students[x], students[x-1]);
      } 
    }
  } 
}

這是一個對學(xué)生按照身高從低到高進(jìn)行排序的算法。對于這段代碼，如果我們進(jìn)行猜測，會發(fā)現(xiàn)很多點(diǎn)都有變化的可能，如果對這些變化都進(jìn)行分離和管理，確實(shí)會提高系統(tǒng)的內(nèi)聚度。但如果我們現(xiàn)在就將整個系統(tǒng)每個可能的變化點(diǎn)都分離出來，無疑會讓整個系統(tǒng)陷入無邊無際的不必要的復(fù)雜度。

破解這類難題的方法是：既然我們知道高內(nèi)聚，低耦合的設(shè)計(jì)是為了軟件更容易應(yīng)對變化的，那么我們?yōu)楹尾环催^來，讓實(shí)際發(fā)生的需求變化來驅(qū)動我們識別變化，管理變化，從而讓我們的系統(tǒng)達(dá)到恰如其分的內(nèi)聚度和耦合度?

策略一：消除重復(fù)

首先進(jìn)入我們射程的就是重復(fù)代碼。編寫重復(fù)代碼不僅僅會讓有追求的程序員感到乏味。真正致命的是：“重復(fù)”極度違背高內(nèi)聚、低耦合原則，從而會大幅提升軟件的長期維護(hù)成本。

我們之前已經(jīng)討論過，所謂高內(nèi)聚，指的是關(guān)聯(lián)緊密的事物應(yīng)該被放在一起。沒有比兩段完全相同的代碼關(guān)聯(lián)更為緊密。因而重復(fù)代碼意味著低內(nèi)聚。

而更為糟糕的是，本質(zhì)重復(fù)的代碼，其實(shí)都在表達(dá)（即依賴）同一項(xiàng)知識。如果它們表達(dá)（即依賴）的知識發(fā)生了變化，這些重復(fù)的代碼統(tǒng)統(tǒng)都要修改。因而, 重復(fù)代碼也意味著高耦合。

重復(fù)代碼意味著耦合

因而，對于完全重復(fù)的代碼進(jìn)行消除，合二為一，會讓系統(tǒng)更加高內(nèi)聚、低耦合。

而更為關(guān)鍵的是：如果兩個模塊之間是部分重復(fù)的，則發(fā)出了一個重要的信號：這兩個模塊都至少存在兩個變化原因，或兩重職責(zé)。

如下圖所示，兩個模塊存在著部分重復(fù)。站在系統(tǒng)的角度看，它們之間存在著不變的部分（即重復(fù)的部分）；也存在變化的部分（即差異的部分）。這意味著這兩個模塊都存在兩個變化原因。

變化與不變：多重職責(zé)

對于這一類型的重復(fù)，比較典型的情況有兩種：調(diào)用型重復(fù)，以及回調(diào)型重復(fù)。它們的命名來源于：在重復(fù)消除后，重復(fù)與差異之間的關(guān)系是調(diào)用，還是回調(diào)。

調(diào)用型重復(fù)

回調(diào)型重復(fù)

由此，我們得到了第一個策略：消除重復(fù)。

這個策略，非常明確，極具可操作性：當(dāng)你看到重復(fù)時(shí)，盡力消除它。

這個策略，明顯提高系統(tǒng)的內(nèi)聚性，降低了耦合性。除此之外,還得到一個重大收益：可重用性。事實(shí)上，消除重復(fù)的過程，正是一個提高系統(tǒng)可重用性的過程。

另外對于回調(diào)型重復(fù)的消除，也是一個提高系統(tǒng)可擴(kuò)展性的過程。

策略二：分離不同的變化方向

除了重復(fù)代碼外，另外一個驅(qū)動系統(tǒng)朝向高內(nèi)聚方向演進(jìn)的信號是：我們經(jīng)常需要因?yàn)?em>同一類原因，修改某個模塊。而這個模塊的其它部分卻保持不變。

比如，在之前我們對學(xué)生按照身高從低到高排序的例子中，如果現(xiàn)在我們需要增加對老師按照身高從低到高排序的需求，我們就知道，排序?qū)ο?/strong>是一個新的變化方向。于是，我們將代碼重構(gòu)為:

template 
void bulb_sort(T objects[], size_t num_of_objects) 
{
  for(size_t y=0; y < num_of_objects - 1; y++) 
  {
    for(size_t x=1; x < num_of_objects - y; x++) 
    {
      if(objects[x].height > objects[x-1].height) 
      {
         SWAP(objects[x], objects[x-1]);
      }
    } 
  }
}

template 
void bulb_sort(T objects[], size_t num_of_objects) 
{
  for(size_t y=0; y < num_of_objects - 1; y++) 
  {
    for(size_t x=1; x < num_of_objects - y; x++) 
    {
      if(objects[x] > objects[x-1]) 
      {
        SWAP(objects[x], objects[x-1]);
      }
    } 
  }
}

分離不同變化方向，目標(biāo)在于提高內(nèi)聚度。因?yàn)?strong>多個變化方向，意味著一個模塊存在多重職責(zé)。將不同的變化方向進(jìn)行分離，也意味著各個變化方向職責(zé)的單一化。

從這個例子可以看出，此策略的應(yīng)用時(shí)機(jī)也非常明確：當(dāng)你發(fā)現(xiàn)需求導(dǎo)致一個變化方向出現(xiàn)時(shí)，將其從原有的設(shè)計(jì)中分離出去。

分離新的變化方向

對于變化方向的分離，也得到了另外一個我們追求的目標(biāo)：可擴(kuò)展性。

如果我們足夠細(xì)心，會發(fā)現(xiàn)策略消除重復(fù)和分離不同變化方向是兩個高度相似和關(guān)聯(lián)的策略:

它們都是關(guān)注于如何對原有模塊進(jìn)行拆分，以提高系統(tǒng)的內(nèi)聚性。(雖然同時(shí)也往往伴隨著耦合度的降低，但這些耦合度的降低都發(fā)生在別處，并未觸及該如何定義API以降低客戶與API之間耦合度)。

另外，如果兩個模塊有部分代碼是重復(fù)的，往往意味著不同變化方向。

盡管如此，我們依然需要兩個不同的策略。這是因?yàn)椋鹤兓较?，并不總是?strong>重復(fù)代碼的形式出現(xiàn)的（其典型癥狀是散彈式修改，或者if-else、switch-case、模式匹配）；盡管其背后往往存在一個以重復(fù)代碼形式表現(xiàn)的等價(jià)形式（這也是為何copy-paste-modify如此流行的原因）。

策略三：縮小依賴范圍

前面兩個策略解決了軟件單元該如何劃分的問題。現(xiàn)在我們需要關(guān)注模塊之間的粘合點(diǎn)——即API——的定義問題。

需要強(qiáng)調(diào)的是：兩個模塊之間并不存在耦合，它們的都共同耦合在API上。因而 API如何定義才能降低耦合度，才是我們應(yīng)該關(guān)注的重點(diǎn)。

耦合點(diǎn)：API

從這幅圖可以看出，對于API定義所帶來的耦合度影響，需要遵循如下原則：

• 首先，客戶和實(shí)現(xiàn)模塊的數(shù)量，會對耦合度產(chǎn)生重大的影響。它們數(shù)量越多，意味著 API 變更的成本越高，越需要花更大的精力來仔細(xì)斟酌。
• 其次，對于影響面大的API（也意味著耦合度高），需要使用更加彈性的API定義框架，以有利于向前兼容性。

而具體到策略縮小依賴范圍，它強(qiáng)調(diào):

1. API 應(yīng)包含盡可能少的知識。因?yàn)槿魏我豁?xiàng)知識的變化都會導(dǎo)致雙方的變化;
2. API 也應(yīng)該高內(nèi)聚，而不應(yīng)該強(qiáng)迫API的客戶依賴它不需要的東西。

策略四：向著穩(wěn)定的方向依賴

但是，無論我們?nèi)绾?strong>縮小依賴范圍，如果兩個模塊需要協(xié)作，它們之間必然存在耦合點(diǎn)(即API)。降低耦合度的努力似乎已經(jīng)走到了盡頭。

我們知道，耦合的最大問題在于：耦合點(diǎn)的變化，會導(dǎo)致依賴方跟著變化。但這也意味著，如果耦合點(diǎn)從來不會變化，那么依賴方也就不會因此而變化。換句話說，耦合點(diǎn)越穩(wěn)定，依賴方受耦合變化影響的概率就越低。

由此，我們得到最后一個策略：向著穩(wěn)定的方向依賴。

那么，究竟什么樣的API更傾向于穩(wěn)定？不難知道，站在What，而不是How的角度；即
站在需求的角度，而不是實(shí)現(xiàn)方式的角度定義API，會讓其更加穩(wěn)定。

而需求的提出方，一定是客戶端，而不是實(shí)現(xiàn)側(cè)。這就意味著，我們在定義接口時(shí)，應(yīng)該站在客戶的角度，思考用戶的本質(zhì)需要，由此來定義API。而不是站在技術(shù)實(shí)現(xiàn)的方便程度角度來思考API定義。

而這正是封裝或信息隱藏的關(guān)鍵。

小結(jié)

這四個策略，前兩者聚焦于如何劃分模塊，后兩個聚焦于如何定義模塊間的API。換句話說，前兩者關(guān)注于“如何分”，后兩條聚焦于“怎么合”。

這四個策略的背后動力非常明確：變化。前兩者，都是在明確的變化方向被第一次識別之后（所謂第一顆子彈），進(jìn)行策略運(yùn)用，以讓模塊在變化面前越來越高內(nèi)聚。而后兩者，則是在模塊職責(zé)分離之后，需要定義模塊間API時(shí)，盡可能考慮不同的API定義方式對于依賴雙方的影響，以達(dá)到低耦合。

由于這四個策略致力于讓系統(tǒng)朝著更具正交性的方向演進(jìn)，因而它們也被稱做正交策略，或者正交四原則。

總結(jié)

本文首先從一個出發(fā)點(diǎn)出發(fā)：為了降低軟件復(fù)雜度，提升可重用性，我們需要模塊化。

由此得到了兩個問題：模塊劃分必然要解決如何劃分，以及模塊間如何協(xié)作（API 定義）的問題。

基于軟件易于應(yīng)對變化的角度出發(fā)。高內(nèi)聚、低耦合原則是最為核心和關(guān)鍵的高層原則。基于此我們得到了在模塊化過程中，我們真正需要關(guān)注的三方關(guān)系。

為了讓高內(nèi)聚、低耦合更具指導(dǎo)性和操作性，我們提出了四個策略。它們以變化驅(qū)動，讓系統(tǒng)逐步向更好的正交性演進(jìn)的策略，因此也被稱做正交策略或正交原則。

我們已經(jīng)在多個系統(tǒng)的設(shè)計(jì)和開發(fā)中，以這四個原則來驅(qū)動我們的軟件設(shè)計(jì)，不僅讓我們的系統(tǒng)在保持簡單的同時(shí)，具備所有必要的靈活性。也讓設(shè)計(jì)和開發(fā)活動變得高度有章可循，讓團(tuán)隊(duì)生產(chǎn)率得以大幅提升。

最后，推薦劉光聰的文章《實(shí)戰(zhàn)正交設(shè)計(jì)》。這篇文章通過一個例子，來展示了正交策略是如何驅(qū)動出更加正交的設(shè)計(jì)的。

而正交設(shè)計(jì)與SOLID的關(guān)系，可參閱《正交設(shè)計(jì)，OO與SOLID》。

附錄

而我的朋友及前同事李光磊對此精煉的總結(jié)道：

變化導(dǎo)致的修改有兩類：

1. 一個變化導(dǎo)致多處修改（重復(fù)）；
2. 多個變化導(dǎo)致一處修改（多個變化方向）；
   由此得到前兩個策略：消除重復(fù)；分離不同變化方向。

除此之外，我們要努力消除變化發(fā)生時(shí)不必要的修改，也有兩種方式：

1. 不依賴不必要的依賴；
2. 不依賴不穩(wěn)定的依賴；
   這就是后面兩個策略：縮小依賴范圍，向著穩(wěn)定的方向依賴。

從光磊這個精彩總結(jié)中可以清晰的看出：

1. 一切圍繞著變化：由變化驅(qū)動，反過來讓系統(tǒng)演進(jìn)的更容易應(yīng)對變化；
2. 這四個策略都是在讓系統(tǒng)更加局部化影響。
3. 這四個策略的完備性。