我用過的設計模式（1）-- 本門心法

單一職責原則

什么是“單一職責原則”？

如果要理解為：一個類只有一個職責，當然也是可以的，簡單化嘛，
單一職責的原話解釋是這樣的：There should never be more than one reason for a class to change.
什么意思？那里，應該，沒有，多于，一個，原因，使得，類，去，改變，
啊，咱這蹩腳英語，勉強能翻譯啊，

不過，能看懂是一回事，具體實作就是另一個故事了，，，

飽受爭議的原則

為什么飽受爭議呢？看著多單純一原則啊，
這樣，我們來看一個打電話的程序：

class 電話{
public:
void 撥出電話(string 電話號碼);
void 瞎比比(Object *嗶嗶類物件); //總不能傳個string吧，說一句就沒啦？
void 掛電話();
}；

這個有沒有問題？是有那么小問題的嘞，
你說我哪天，撥號的方法要改一下，我變成撥不通就一直撥，那這個類變一下，
然后我通信的方法再改一下，我現在不允許兩個人同時說話，一個說完另一個再說，那這個類再變一下，

這個類，有兩個職責：協議管理和資料傳送，

那怎么搞？把那倆介面獨立出來唄，然后將兩個職責融合在一個類中，

現在變成了一個類融合了兩個介面，確實那個實作類還是有兩個原因引起變化，但是別忘了，我們是面向介面編程（后面會提到，依賴倒置原則），我們對外公布的是介面，又不是實作類，

如果你非要對這個栗子實作單一原則，也可以，你要有那個權力或精力（因為我估計沒人愿意陪你這樣玩），

“單一職責原則”的優勢

• 類的復雜性降低，實作什么職責都有明確的定義， 這是最首要的，如果不能降低復雜度，那就別分開
• 可讀性提高
• 可維護性提高
• 變更引起的風險降低

怎么用？自己看著辦

對于介面，我們在實作的時候一定要做到單一，但是對于實作類就需要多方面考慮了，
生搬硬套的話會有什么不良反應，去試試就知道了，

單一職責很難在專案中得到體現，就拿上面那栗子來說，能把介面分開就謝天謝地吧，
當然，單一職責也可以用于類方法，說來慚愧，我曾經用一個類方法實作五個功能（通過巧妙設定引數），，，，
現在想想，真是好笑啊，

里氏替換原則

什么是“里氏替換原則”？

這個原則，說簡單也簡單，說拗口也拗口，

是這樣說的：Function that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
所有參考基類的地方，必須能透明的使用其子類物件，

什么意思呢？就是子類必須實作父類的所有方法，有父類出現的地方，子類就可以出現，

關于里氏替換原則

關于里氏替換原則，我并不想講太多，無非就是父類弄成純虛基類，然后客端呼叫的時候以子類來new出父類宣告的物件：父類 * 物件 = new 某子類();
這種格式后面會常見，見到的時候自然就明白了，

依賴倒置原則

什么是“依賴倒置原則”

這是我最喜歡的一個原則，也是受益最大的，
它的定義是：High level modules should not depend upon low level modules. Both should depend upon abstractions. Absteactions should not depend upon details.Details should depend upon abstractions.

• 高層模塊不應該依賴于低層模塊，二者都應該依賴于抽象，
• 抽象不應該依賴于細節，
• 細節應該依賴于抽象，

關于依賴倒置原則的小故事

故事是別人的，不過放在這里也是很應景啦，
故事是這樣的：
有個適齡小伙子，他還單著，有一天，他喜歡的那個姑娘突然給他打電話，說她的電腦壞了，一用就藍屏警告，姑娘講著講著就要哭出來了，小伙子那個急啊，他心疼啊，所幸，小伙子憑借高超的技術，當機立斷：記憶體潭訓了，但是又苦于所愛隔山水啊，所以他只能當遠程指揮官了，他指導姑娘：扒開電腦主機后蓋，把記憶體條扯出來，然后開機看看，如果還藍屏，那就把那條記憶體條插回去，把另一條拔出來，一頓操作猛如虎，姑娘在小伙無私又認真的指揮下，把電腦修好了，
過兩天，姑娘又打電話給小伙子，說她收音機壞了，希望小伙能再遠程指導一次，但是這次小伙無能了，他不行了，他不會，太難了，他放棄了，他把電話掛了，姑娘很失望，

但是姑娘不知道，電腦，是松耦合，強內聚的，哪個部件壞了就換哪個，但是收音機不一樣，收音機是緊耦合的，牽一發而動全身，收音機沒聲音，可能是擴音器壞了，可能是信號接收其壞了，可能是解頻罷工了···畢竟她是外行嘛，悲催的小伙子，

那么，就要切入到我們的正題了，松耦合、強內聚的電腦，是怎么組裝的呢？

像記憶體條這種東西啊，管你是哪家生產的，只要符合規格，再比如滑鼠、鍵盤、電池（電池得配套），反正哪個部件壞了就換哪個部件，為什么這些部件不論插在哪一臺電腦上都能使用呢？是這些部件配合電腦主板設計，還是電腦主板配合這些零部件設計呢？

想來答案已經很明確了，就拿CPU來說，CPU的對外都是針腳式或觸點式的標準介面，只要介面設計好，內部再復雜和外界也沒有關系，哪個主板要插CPU，那就得和CPU的介面對上，那么這時候如果電腦的記憶體潭訓了，就不該成為你更換麥克風的理由，這不是開玩笑，要是收音機的外放壞了，可能得整部收音機脫胎換骨了，

PC的介面始終是有限的，但是軟體設計得好，卻可以不斷地拓展的，

依賴倒置，讓專案并駕齊驅

我們來思考一下依賴倒置對并行開發的影響，
如果兩個類之間有依賴關系，只要定制出兩者之間的介面（或抽象類），就可以獨立開發了，就像我最近做的一個圖書管理專案，只要合理地運用依賴倒置，便可以很好的將界面與后臺資料訪問解耦合，從而實作并行開發，

最佳實踐

依賴倒置原則的本質就是通過抽象使得各個類或模塊的實作彼此獨立，不互相影響，實作模塊之間的松耦合，我們怎么在專案中使用這個規則呢？只要通過以下的幾個規則：

• 每個類盡量都有介面或抽象類，或者抽象和介面二者都具備，
• 變數的表面型別盡量是介面或者抽象類，
• 任何類都不應該從具體類派生，
• 盡量不要覆寫基類的方法，
• 結合里氏替換原則，

反正我以前是一條都沒對上，

“依賴倒轉原則”在小專案上很難體現出來，

介面隔離原則

什么是“介面隔離原則”？

它建立在“依賴倒置原則”之上，
它的定義有倆：

• Client should not be forced to depend upon interfaces that they don’t use.
• 客戶端不應該依賴于它不需要的介面，
• The dependency of one class to another one should depend on the smallest possible interface.
• 類之間的依賴關系應該建立在最小的介面上，

簡單易懂啊，如果對前面那個原則有一定的把握，

建立單一介面，介面盡量細化，

介面要高內聚

什么是高內聚？高內聚就是提高介面、類、模塊的處理能力，減少對外的互動，比如說你告訴你的保鏢，今天去給我買一打愛馬仕，他就去了，你也不用問他花了多少錢，他也不用問你是不是抽風了，這種不問條件執行的行為就是高內聚，
介面是對外的承諾，承諾越少對系統的開發越有利，變更的風險也越大，同時也有利于降低成本，

最佳實踐

 - 一個介面只服務于一個子模塊或業務邏輯
 - 通過業務邏輯壓縮介面中的public方法，介面要勤快點重構
 - 已經被污染的介面，盡量去修改
 - 了解環境，拒絕盲從

迪米特法則

松耦合的法則：迪米特法則

英文解釋：Only talk to your immedate friends.
只與直接的朋友通信，

如果兩個類之間不能直接通信，那么這兩個類就不應該發生直接的相互作用，如果其中一個類需要呼叫另一個類的某一個方法的話，可以通過第三者轉發這個呼叫，

迪米特法則首先強調在類的設計上，每一個類都應該盡量降低成員的訪問權限，強調了類之間的松耦合，

類之間的耦合越弱，越有利于重復利用，一個處在弱耦合的類被修改，不會對相關類造成波及，

開-閉原則

何為“開閉原則”

Software entities like classes, modules and functions should be open for extension but closed for modifications.
一個軟體物體，應該對拓展開放，對修改關閉，

抽象物體：

專案或軟體產品中按照一定的邏輯規則劃分的模塊，
抽象類
方法

這個原則很重要，后面會很經常見，
多說無益，我就稍微說兩句，后面慢慢看它真面目，

如何應對需求變化？

既然說，對修改要關閉，那需求變化了怎么辦？
有如下方法：

1、修改介面
2、修改實作類
3、通過拓展實作變化

至于為什么需要這個原則、如何使用、何時使用這個原則，跟著我的步伐，往后看，

今天的分享到此告一段落，算是我回歸設計模式模塊的禮物，