架構師內功心法之設計原則

一.架構師內功心法之設計原則

1.爲何要學習軟件架構設計原則

1.1.課程目標

1. 經過對節課內容的學習，瞭解設計原則的重要性。
2. 掌握七大設計原則的具體內容。

1.2.內容定位

學習設計原則，學習設計模式的基礎。在實際開發過程當中，並非必定要求全部代碼都遵循設計原則，咱們要考慮人力、時間、成本、質量，不是刻意追求完美，要在適當的場景遵循設計原則，體現的是一種平衡取捨，幫助咱們設計出更加優雅的代碼結構。

1.3.七大設計原則

• [x] 第1章 Open-Closed Principle 開閉原則
• [x] 第2章 Dependence Inversion Principle 依賴倒置原則
• [x] 第3章 Simple Responsibility Principle 單一職責原則
• [x] 第4章 Interface Segregation Principle 接口隔離原則
• [x] 第5章 Law of Demeter 迪米特法則
• [x] 第6章 Liskov Substitution Principle 里氏替換原則
• [x] 第7章 Composite&Aggregate Reuse Principle 合成複用原則

1.3.1.開閉原則

• 定義

  • 開閉原則（Open-Closed Principle, OCP）是指一個軟件實體如類、模塊和函數應該對擴展開放，
    對修改關閉。所謂的開閉，也正是對擴展和修改兩個行爲的一個原則。強調的是用抽象構建框架，用實現擴展細節。
  • 開閉原則，是面向對象設計中最基礎的設計原則。它指導咱們如何創建穩定靈活的系統，例如：咱們版本更新，我儘量不修改源代碼，可是能夠增長新功能。
  • 實現開閉原則的核心思想就是面向抽象編程。

• 總結

  • 對修改關閉，對擴展開放
  • 簡單說：就是不修改原有實現類，而是新寫實現類。
  • 缺點：會致使代碼臃腫。

1.3.2.依賴倒置原則

• 定義

  • 依賴倒置原則（Dependence Inversion Principle,DIP）是指設計代碼結構時，高層模塊不該該依
    賴底層模塊，兩者都應該依賴其抽象。抽象不該該依賴細節；細節應該依賴抽象。經過依賴倒置，能夠
    減小類與類之間的耦合性，提升系統的穩定性，提升代碼的可讀性和可維護性，並可以下降修改程序所形成的風險。
  • 以抽象爲基準比以細節爲基準搭建起來的架構要穩定得多，所以你們在拿到需求以後，要面向接口編程，先頂層再細節來設計代碼結構。

• 總結

  • 倒置：先框架，後細節。

1.3.3.單一職責原則

• 定義

  • 單一職責（Simple Responsibility Principle，SRP）是指不要存在多於一個致使類變動的緣由。假
    設咱們有一個Class負責兩個職責，一旦發生需求變動，修改其中一個職責的邏輯代碼，有可能會致使
    另外一個職責的功能發生故障。這樣一來，這個Class存在兩個致使類變動的緣由。如何解決這個問題呢？
    咱們就要給兩個職責分別用兩個 Class來實現，進行解耦。後期需求變動維護互不影響。這樣的設計，
    能夠下降類的複雜度，提升類的可讀性，提升系統的可維護性，下降變動引發的風險。整體來講就是一
    個Class/Interface/Method只負責一項職責。

• 總結

  • 職責單一
  • 一個類只作一件事

1.3.4.接口隔離原則

• 定義

  • 接口隔離原則（Interface Segregation Principle, ISP）是指用多個專門的接口，而不使用單一的總接口，客戶端不該該依賴它不須要的接口。這個原則指導咱們在設計接口時應當注意一下幾點：

    1. 一個類對一類的依賴應該創建在最小的接口之上。
    2. 創建單一接口，不要創建龐大臃腫的接口。
    3. 儘可能細化接口，接口中的方法儘可能少（不是越少越好，必定要適度）。
  • 接口隔離原則符合咱們常說的高內聚低耦合的設計思想，從而使得類具備很好的可讀性、可擴展性
    和可維護性。咱們在設計接口的時候，要多花時間去思考，要考慮業務模型，包括之後有可能發生變動
    的地方還要作一些預判。因此，對於抽象，對業務模型的理解是很是重要的。

• 總結

  • 接口隔離原則和單一職責原則區別？
  • 接口隔離：指的接口
  • 單一職責：指的是類和方法

1.3.5.迪米特法則

• 定義

  • 迪米特原則（Law of Demeter LoD）是指一個對象應該對其餘對象保持最少的瞭解，又叫最少知道原則（Least Knowledge Principle,LKP），儘可能下降類與類之間的耦合。迪米特原則主要強調只和朋友交流，不和陌生人說話。出如今成員變量、方法的輸入、輸出參數中的類均可以稱之爲成員朋友類，
    而出如今方法體內部的類不屬於朋友類。

• 總結

  • 參照訪問修飾符

• 聚合vs組合

  • 聚合：個體與羣體
  • 組合：頭和身體，相同生命週期

1.3.6.里氏替換原則

• 定義

  • 里氏替換原則（Liskov Substitution Principle,LSP）是指若是對每個類型爲 T1 的對象 o1,都有
    類型爲T2 的對象 o2,使得以T1 定義的全部程序 P 在全部的對象o1都替換成 o2時，程序 P 的行爲沒
    有發生變化，那麼類型T2是類型T1的子類型。
  • 能夠理解爲一個軟件實體若是適用一個父類的話，
    那必定是適用於其子類，全部引用父類的地方必須能透明地使用其子類的對象，子類對象可以替換父類
    對象，而程序邏輯不變。

  • 引伸含義：子類能夠擴展父類的功能，但不能改變父類原有的功能。

    1. 子類能夠實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
    2. 子類中能夠增長本身特有的方法。
    3. 當子類的方法重載父類的方法時，方法的前置條件（即方法的輸入/入參）要比父類方法的輸入參數更寬鬆。
    4. 當子類的方法實現父類的方法時（重寫/重載或實現抽象方法），方法的後置條件（即方法的輸
       出/返回值）要比父類更嚴格或相等。

• 總結

  • 子類不能改變父類原有方法，能夠新增方法。

1.3.7.合成複用原則

• 定義

  • 合成複用原則（Composite/Aggregate Reuse Principle,CARP）是指儘可能使用對象組合(has-a)/
    聚合(contains-a)，而不是繼承關係達到軟件複用的目的。可使系統更加靈活，下降類與類之間的耦
    合度，一個類的變化對其餘類形成的影響相對較少。
  • 繼承咱們叫作白箱複用，至關於把全部的實現細節暴露給子類。組合/聚合也稱之爲黑箱複用，對類之外的對象是沒法獲取到實現細節的。要根據具體的業務場景來作代碼設計，其實也都須要遵循 OOP
    模型。

• 總結

  • 多用聚合組合代替繼承原則

1.4.設計原則總結

學習設計原則，學習設計模式的基礎。在實際開發過程當中，並非必定要求全部代碼都遵循設計原
則，咱們要考慮人力、時間、成本、質量，不是刻意追求完美，要在適合的場景遵循設計原則，體現的是一種平衡取捨，幫助咱們設計出更加優雅的代碼結構。