設計模式之六大設計原則

設計模式之六大設計原則

• 單一職責原則（Single Responsibility Principle - SRP）
  有且僅有一個緣由引發類的變動。即一個類只負責一項職責。
  • 類的複雜性下降
  • 可讀性提升
  • 可維護性提升
  • 變動引發的風險下降
• 里氏替換原則（Liskov Substitution Principle - LSP）
  子類能夠擴展父類的功能，但不能改變父類原有的功能。
  • 子類能夠實現父類的抽象方法，但不能覆蓋父類的非抽象方法
  • 子類中能夠增長本身特有的方法
  • 當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆
  • 當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比分類更嚴格
• 依賴倒置原則（Dependence Inversion Principle）
  高層模塊不該該依賴低層模塊，兩者都應該依賴其抽象；抽象不該該依賴細節；細節應該依賴抽象。核心就是面向接口編程。
  • 低層模塊儘可能都要有抽象類或者接口，或者二者都有
  • 變量的聲明類型儘可能是抽象類或接口
  • 使用繼承時遵循里氏替換原則
• 接口隔離原則（Interface Segregation Principle）
  客戶端不該該依賴它不須要的接口；一個類對另外一個類的依賴應該創建在最小的接口上。
  • 接口儘可能要小。根據接口隔離原則拆分接口時，必須首先知足單一職責原則。
  • 接口要高內聚。提升接口、類、模塊的處理能力，減小對外的交互。
  • 定製服務。只暴露給調用的類它須要的方法，它不須要的方法則隱藏起來。只有專一地爲一個模塊提供定製服務，才能創建最小的依賴關係。
  • 接口設計是有限度的。接口的設計粒度越小系統越靈活，這是不爭的事實，但這就帶來結構的複雜化，開發難度增長，維護性下降，因此必定要適度。 接口和類都儘可能使用原子接口或原子類來組裝。
    • 原子劃分規則：
      • 一個接口只服務於一個子模塊或者業務邏輯
      • 經過業務邏輯壓縮接口中的public方法
      • 已經被污染了的接口，儘可能去修改，若變動的風險較大，則採用適配器模式進行轉換處理
      • 瞭解環境，拒絕盲從。環境不一樣，接口拆分的標準就不一樣，深刻了解業務邏輯才能更好地設計原子
• 迪米特法則（Low Of Demeter）
  一個對象應該對其餘對象保存最少的瞭解。迪米特法制也叫最少知道原則（Least Knowledge Principle，簡稱LKP）。一個類對本身依賴的類知道的越少越好。其實就是實現類的高內聚，低耦合。
  • 只和直接的朋友通訊。出現成員變量、方法參數、方法返回值中的類爲直接朋友。
  • 朋友間也是有距離的。迪米特法制要求類「小氣」一點，儘可能不要對外公佈太多的public方法和非靜態的public變量，儘可能內斂，多使用private，package-private，protected等訪問權限。
• 開閉原則（Open Close Principle）
  類、模塊和函數應該對擴展開放，對修改關閉。用抽象構建框架，用實現擴展細節。
• 總結
  • 單一職責原則：實現類要職責單一
  • 里氏替換原則：不要破壞繼承體系
  • 依賴倒置原則：面向接口編程
  • 接口隔離原則：設計接口要精簡單一
  • 迪米特法制：要下降耦合
  • 開閉原則：對擴展開放，對修改關閉