設計模式 0 章-概要

設計模式的目的:抵禦變化,達成復用

理解面向對象

隔離變化:

  1. 將變化帶來的影響降到最小

各司其職:

  1. 強調類的責任
  2. 由於需求變化帶來的新增類型不應該影響原來類型的實現,各負其責

對象是什麼:

  1. 語言層面:封裝了代碼和數據
  2. 規格層面:一系列可被使用的公共介面
  3. 概念層面:擁有某種責任的抽象

面向對象設計原則

  1. 依賴倒置原則(DIP)
    1. 高層模塊(穩定)不應該依賴(編譯時)於低層模塊(變化),二者都應該依賴於抽象(穩定)
    2. 抽象(穩定)不應該依賴(編譯時)實現細節(變化)
  2. 開放封閉原則(OCP)
    1. 對擴展開放,對更改封閉
    2. 類模塊應該是可擴展的,但是不可更改
  3. 單一職責原則(SRP)
    1. 一個類應該只有一個引起它變化的原因
    2. 變化的方向隱含著類的責任
  4. Liskov 替換原則(LSP)
    1. 子類必須能替換他們的基類(IS-A)
    2. 繼承表達類型抽象
  5. 介面隔離原則(ISP)
    1. 不應該強制調用方依賴他們不用的方法
    2. 介面應該小而完備
  6. 優先使用對象組合,而不是類繼承
    1. 類繼承通常為『白箱復用』,對象組合通常為『黑箱復用』
    2. 繼承在某種程度上破壞了封裝性,子類父類耦合度高
    3. 對象組合只需求被組合的對象具有良好定義的介面,耦合度低
  7. 封裝變化點
    1. 使用封裝創建對象之間的分界層,讓設計者可以在分界層的一側進行修改,而不會對另一側產生不良影響,實現松耦合
  8. 針對介面編程,而不是針對實現編程
    1. 不將變數類型聲明為某個特定具體的類,而是聲明為某個介面
    2. 調用方無需獲知對象的具體類型,只需要知道對象所具有的介面
    3. 減少系統中各個部分的依賴關係,從而實現『高內聚,松耦合』的類型設計方案
    4. 介面標準化是產業強盛的標誌

重構獲得模式

  1. 滿足『應對變化,提高復用』才是好的設計
  2. 設計模式的要點是『尋找變化點,在變化點出應用設計模式』,什麼時候,什麼地點應用比理解設計模型本身結構更重要
  3. 應用設計模式不要先入為主,一上來就用設計模式是最大的誤區,應該『Refactoring to Patterns』

重構技法

  1. 靜態 => 動態
  2. 早綁定 => 晚綁定
  3. 繼承 => 組合
  4. 編譯時依賴 => 運行時依賴
  5. 緊耦合 => 松耦合

推薦閱讀:

《Node.js設計模式(第2版)》試讀 & 送書活動
面向對象&設計模式
類的設計原則
設計模式之「Decorator」註疏#02
遊戲開發與程序設計知識總結01——設計模式

TAG:設計模式 | 編程 | 架構 |