7 大設計原則總結篇（41張圖解、2萬多字、非常詳細）

來源：mikechen的網際網路架構

無論是哪一種設計模式，都需要遵循設計原則。

如果說設計模式則是具體運用，那麼設計原則就是理論指導。

因此，要想理解設計模式的精髓，就需要先深入 7 大設計原則。

本文，我們重點介紹設計模式的 7 大原則。

01

  設計模式的概述？

1.1  設計模式是什麼

設計模式（Design Pattern）是軟體開發經驗的總結，是一套解決特定問題領域的通用、可重用的解決方案。

簡單理解，就是透過複用成功的設計和體系結構，來解決反覆出現的通用問題。

設計模式一共有 23 種，每一種模式都有明確的用途和適用場景，解決的問題都是不一樣的。

1.2  設計模式的起源

1995 年，Gang of Four  聯合出版了圖書《設計模式：可複用物件導向軟體的基礎》。

在這本書中，第一次將設計模式提升到理論高度，並將之規範化，23 種經典的設計模式被首次提出。

1.3  設計模式的作用

設計模式透過複用成功的設計和體系結構，提高了程式碼的重用性、可讀性、可靠性、可擴充套件性。

• 將通用功能封裝在可重用的元件中，減少了程式碼的冗餘；

• 提供了一種結構化的方式來組織程式碼，減少程式碼的複雜性；

• 有新的需求和變化時，可以輕鬆進行擴充套件，減少了對現有程式碼的破壞性更改。

02

  設計模式的七大設計原則

在前面的系列文章中，我們介紹了 7 大設計原則。

它們分別是開閉原則、里氏替換原則、依賴倒置原則、單一職責原則、介面隔離原則、迪米特法則、合成複用原則。

 7 大設計原則的簡介（詳解見下文）：

設計模式的 7  大設計原則，以實現“高內聚、松耦合”的軟體系統為目標。

下面，我們逐一詳解。

03

  單一職責原則

單一職責原則，英文全稱 Single Responsibility Principle，又稱為單一功能原則。

單一職責原則是指一個類要職責單一，只負責一個特定的功能或任務。

單一職責原則讓每個類都專注於一個明確的職責，降低了程式碼的複雜性，提高程式碼的可維護性。

單一職責原則的 UML 類圖：

單一職責原則的難點是：

如何將類的職責劃分得清晰明瞭，如何識別和消除不必要的職責......。

在實際開發中，我們很容易將不同的責任歸類在一起，或者過度拆分。

是否需要拆分職責，參考思路：

當變化發生，隻影響其中一個職責，那就需要拆分。如果變化都影響到這兩個職責，那就不需要拆分。

完整內容，檢視詳解篇：一文吃透單一職責原則

 

04

  開閉原則

開閉原則，英文全稱 Open/Closed Principle。

開閉原則是指一個軟體實體（類、函式等），應該 對擴充套件開放、對修改封閉 。

開閉原則是物件導向設計中“可複用設計”的基石。

開閉原則透過實現一個熱插拔的效果，在不破壞現有功能、不修改原有程式碼的情況下，去擴充套件原有程式碼，讓系統可維護、可擴充套件、可複用。

開閉原則的 UML 類圖：

開閉原則的示例：

假設：

我們要實現一個繪製圖表的功能，支援多種圖表顯示方式，例如柱狀圖、餅狀圖...等多種圖表。

系統結構：

......

完整內容，檢視詳解篇: 3 分鐘吃透開閉原則，架構設計築基必知必會

05

  里氏替換原則

里氏替換原則（LSP），又稱為里氏代換原則，英文全稱 Liskov Substitution Principle。

里氏替換原則中的“里氏”，取自其提出者麻省理工學院的 Liskov 女士。

里氏替換原則的定義：

所有引用基類（父類）的地方，必須能透明地使用其子類的物件，但不能修改父類已有的功能。

即，任何父類在的地方，都可以替換成子類，並且要保證原有程式的邏輯行為和正確性。

里氏替換原則提高了程式碼的重用性、相容性、擴充套件性。

但是，里氏替換原則也有一些缺點。例如，繼承是侵入性的，降低了程式碼的靈活性，增強了耦合性。

里氏替換原則的例項：

假設：

一個電商系統中，使用者分為兩類：VIP使用者、普通使用者。

現在，需要實現一個傳送郵件的功能。

沒有遵循里氏替換原則，是這樣設計的：

......

完整內容，檢視詳解篇: 微信一面掛，痛失 50 W，只因里氏替換原則沒說清楚

 

06

  依賴倒置原則

依賴倒置原則（DIP），英文全稱 Dependency Inversion Principle。

依賴倒置原則是指要面向介面程式設計。

高階模組不應該依賴於低階模組，它們都應該依賴於抽象。抽象不應該依賴於具體實現，具體實現應該依賴於抽象。

依賴倒置的 UML 類圖：

依賴倒置原則的兩個核心思想：

1） 高層模組不應依賴於底層模組，高層模組、底層模組都應依賴於抽象。

2） 抽象不應該依賴於細節，細節應該依賴於抽象。

這意味著，

在軟體設計中，應該使用抽象類、介面或抽象方法等抽象層，來定義模組之間的通訊介面。

而具體實現，應該依賴於這些抽象。

一圖釋義：

依賴倒置原則的實現示例：

假設：

現在你需要實現一個麵包店，你第一件想到的事情是什麼？

我想到的是一個麵包店，裡面有很多具體的麵包。

例如：法棍麵包、全麥麵包、白麵包、牛角麵包、蕎麥麵包、法式麵包、甜甜圈麵包、裸麥麵包。

傳統依賴關係：

麵包店就是上層模組，麵包是下層模組。如圖：

程式碼示例：

......

完整內容，檢視詳解篇: 依賴倒置原則看這篇就夠了

 

07

  介面隔離原則

介面隔離原則（ISP），英文全稱 Interface Segregation Principle。

介面隔離原則是指在設計介面時要精簡單一，只包含客戶端需要的方法，而不包含多餘的方法。

簡單理解：

• 客戶端需要什麼介面，就提供什麼介面，不需要的就不依賴。

• 將大介面拆分成多個小介面，每個介面只專注服務於一個子模組或業務邏輯。

• 使用抽象類或預設方法，來減少介面的改動對原有程式碼的影響。

介面隔離原則的核心是介面細化，介面細化要合理，結合系統的實際需求，以適度設計為前提，既小而精確。

在軟體設計最初，我們的想法是將相同功能的方法放在同一個介面裡面。

理論上來說，這貌似沒錯，我們來看看如何設計。

例如：

類 A 透過介面 I 依賴類 B，類 C 透過介面 I 依賴類 D。

那麼，對於類 A 和類 B 來說，介面 I 不是最小介面，則類 B 和類 D 必須去實現它們不需要的方法。

如圖：

類 A 依賴介面 I 中的方法 1、方法 2、方法 3，類 B 是對類 A 依賴的實現。

類 C 依賴介面 I 中的方法 1、方法 4、方法 5，類 D 是對類 C 依賴的實現。

對於類 B 和類 D 來說，雖然都有用不到的方法（紅色字型），但由於實現了介面 I，所以也必須要實現這些用不到的方法。

程式碼示例：

......

完整內容，檢視詳解篇: 精通介面隔離原則，輕鬆實現高內聚、低耦合架構

 

08

  合成複用原則

合成複用原則（CRP），又稱為組合/聚合複用原則，英文全稱 Composite Reuse Principle。

合成複用原則要求在實現程式碼複用時，儘量先使用組合或聚合等關聯關係，其次考慮使用繼承關係。

合成複用原則的核心思想：

• 將不同的類、模組或元件組合在一起，來建立新的類或物件。

• 儘量不透過繼承已有的類來獲得需要的功能。

 合成複用原則的實現示例：

假設：

在一個汽車分類管理程式中，汽車有兩種分類方式：

• 按動力源分類：汽油汽車、電動汽車等；

• 按顏色分類：白色汽車、黑色汽車和紅色汽車等。

如果使用繼承，就需要同時考慮這兩種分類，將會產生6個組合。

這樣的方式會帶來兩個問題：

• 導致子類過多。

• 任何一個分類發生變更，都要修改原始碼，違背了開閉原則。

圖例：

程式碼示例：

......

關於合成複用原則的概念、背景、作用、UML、示例、應用，以及組合和繼承的選型思路的全面詳解。

完整內容，檢視詳解篇: 合成複用原則全面解析（附圖解及原始碼例項）

 

09

  迪米特法則

迪米特法則（LoD），又稱為最少知識原則，英文全稱 Least Knowledge Principle。

迪米特法則是指一個模組（類）只和與它高度相關的模組交流，儘量減少與其他模組（類）的直接交流。

大白話就是，模組之間的通訊應該簡單明瞭，每個模組只需要關心與它高度相關的模組，而不必瞭解整個系統的細節。

這有點像在現實生活中，你只與你的朋友直接交流，而不會與朋友的朋友（陌生人）交流。你的任何改變，都不會對朋友的朋友帶來影響。

迪米特法則的由來

低耦合、高內聚是軟體程式設計的總原則。

• 耦合：指模組之間的聯絡程度。

• 內聚：指模組內部元素的聯絡程度。

模組之間瞭解得越多，耦合就越緊。

任何一個模組的變化，都會影響到其他模組，系統就會變得很複雜。

只有儘可能降低各個模組之間的耦合，才能提高程式碼的複用率。

怎樣才能實現低耦合呢？

這正是迪米特法則要去實現的。

迪米特法則的程式碼示例：

......

完整內容，檢視詳解篇: 2分鐘通俗理解迪米特法則

 

總結

  

本文主要詳解設計模式的 7 大設計原則。

設計模式的提出，是為了解決一個常見的問題而總結出來的解決方案。設計模式一共有 23 種，不同的設計模式，解決的問題是不一樣的，後續我將持續連載更新這個部分。