摘要：設計模式原則、設計模式的劃分與簡要概括，怎么使用重構獲得設計模式并改善代碼的壞味道。

本篇作概覽與檢索用，后續結合源碼進行具體模式深入學習。

目錄

1、設計模式原理

核心原則（語言無關）

本質原理圖

原則關聯矩陣

2、設計模式分類

1. 創建型模式

2. 結構型模式

3. 行為型模式

3、重構獲得模式

重構關鍵技法

靜態——>動態

早綁定——>晚綁定

繼承——>組合

編譯時依賴——>運行時依賴

緊耦合——>松耦合

生產設計的原則傾向

---

什么樣的代碼算是好的代碼呢？同好的服務一樣（此處強行關聯 《[微服務設計]1_微服務》）——功能正確、高效、可維護性強、健壯抗壓、寫作流暢。也可以總的來說，低耦合高內聚的高質量可維護代碼，就是好的代碼。

那么，有沒有一些規范可以遵循的呢？

有的，設計模式就是這樣的指導規范。

1、設計模式原理

核心原則（語言無關）

眾所周知，設計模式有一些原則可以遵守：

單一職責：一個模塊/類應僅負責一個職責。降低模塊間耦合，提升可維護性。

里氏替換：所有引用基類的地方必須能透明地使用子類對象。這樣利于抽象與類型封裝。

開放封閉：對修改封閉、對拓展開放。

迪米特：減少對象間不必要的直接交互，降低耦合，提高模塊獨立性。

接口隔離原則：客戶端不應依賴未使用的接口。將大接口拆分為小的、高內聚的接口。

依賴倒置：高層模塊不應該依賴于底層模塊，轉換為二者都依賴于抽象。具體來說就是針對接口編程，而不是針對具體實現，這樣可以減少各部分依賴關系，這也面向對象設計的亮點。

還有優先使用對象組合而不是類繼承等等……

總的來說：從通用核心原則到實現層原則再到構造策略相關的原則，均追求代碼模塊的低耦合高內聚，降低復雜度。

本質原理圖

原則關聯矩陣

2、設計模式分類

Gang of Four（四人組，GOF） 在經典著作《設計模式：可復用面向對象軟件的基礎》中提出的23種設計模式的分類方式，按功能和用途分為三大類——創建型、結構型、行為型。

1. 創建型模式

目的：解決對象的創建問題，封裝實例化邏輯，提升代碼復用性和靈活性。

核心思想：將對象的創建與使用解耦，通過統一接口或模板控制對象實例化過程。

2. 結構型模式

目的：處理類與對象的組合，優化系統結構，提高模塊間的解耦性。

關注如何將對象組合成更大的結構，處理類和對象的關系，以實現更大的功能。

核心思想：通過組合、繼承或接口，調整類與對象的結構，增強系統的靈活性和擴展性。

3. 行為型模式

目的：定義對象間的通信機制，管理算法或職責的動態變化。

核心思想：通過解耦對象間的直接依賴，實現行為的動態組合、算法替換或事件驅動。

3、重構獲得模式

需要強調的是：

設計模式是循序漸進的，如同架構設計一樣，沒有一步到位的設計模式，也少有單一的設計模式，要掌握應用時間、地點。

應對變化，提高復用，尋找變化點。

設計模式應在變化點處應用：設計模式是對動態變化點的設計，在變化、穩定中尋找隔離點，來分離他們，從而管理變化，以穩控變。

沒有一個穩定的點，設計模式就沒有意義。

設計模式有23種，慢慢理解嘛。

重構關鍵技法

在《重構-改善既有代碼的設計》一書中，作者Martin Fowler有提到一些有效的重構手法，重構時遵守設計原則。

技法對應原則如下：

靜態——>動態

更好地適應變化與減少重復代碼：動態結構可以通過配置或者接口靈活調整，可以服用邏輯，避免靜態編碼導致的重復。

設計模式：

如策略模式（通過接口定義算法族，運行時選擇具體策略）、觀察者模式（事件驅動的動態通知機制）

重構手法：

替換條件分支為多態（如將if-else替換為不同子類實現）。

引入參數化配置（如通過配置文件動態加載行為）。

示例如下：

// 靜態：硬編碼的條件判斷
public void calculateTax(double income) {if (country == "USA") {// 美國稅率邏輯} else if (country == "China") {// 中國稅率邏輯}
}// 動態：使用策略模式
interface TaxStrategy {double calculate(double income);
}
class USATax implements TaxStrategy { ... }
class ChinaTax implements TaxStrategy { ... }public void calculateTax(TaxStrategy strategy, double income) {return strategy.calculate(income);
}

早綁定——>晚綁定

通過接口和運行時決策增強靈活性。

定義與背景

為什么需要轉向晚綁定？

如何實現？

// 早綁定：直接依賴具體類
public void sendEmail(Email email) {EmailSender sender = new GmailSender();sender.send(email);
}// 晚綁定：通過接口實現多態
public interface EmailSender {void send(Email email);
}
public class GmailSender implements EmailSender { ... }
public class OutlookSender implements EmailSender { ... }public void sendEmail(Email email, EmailSender sender) {sender.send(email); // 運行時決定具體實現
}

繼承——>組合

用組合替代繼承，避免層級過深。

定義與背景

為什么需要轉向組合？

如何實現？

// 繼承：硬編碼行為
class Animal {void move() { ... }
}
class Bird extends Animal { ... }
class Fish extends Animal { ... }// 組合：通過接口解耦
interface MovementStrategy {void move();
}
class Bird {private MovementStrategy movement;public Bird(MovementStrategy movement) {this.movement = movement;}void fly() {movement.move(); // 組合不同策略}
}

編譯時依賴——>運行時依賴

將依賴關系移到運行時，提高可測試性和擴展性。

定義與背景

為什么需要轉向運行時依賴？

如何實現？

// 編譯時依賴：硬編碼依賴
class Service {private Database database = new MySQLDatabase();void doWork() {database.query();}
}// 運行時依賴：通過構造函數注入
class Service {private Database database;public Service(Database database) {this.database = database; // 運行時注入}void doWork() {database.query();}
}

緊耦合——>松耦合

通過抽象接口和事件機制降低模塊間依賴。

定義與背景

為什么需要轉向松耦合？

如何實現？

// 緊耦合：直接調用具體類
class Button {void onClick() {Text text = new Text();text.update();}
}// 松耦合：通過接口解耦
interface Updatable {void update();
}
class Button {private Updatable listener;public Button(Updatable listener) {this.listener = listener;}void onClick() {listener.update();}
}

總結一下核心思想是動態化、低耦合高內聚、保證可讀性與可維護性。

生產設計的原則傾向

低耦合、高內聚是軟件設計的核心原則，但并非所有設計場景的最優先考慮的事情。

比如業務服務設計中，優先考慮組織架構所需求的迭代或者用戶需求和業務目標，在架構設計中，優先考慮系統性能、可維護性。

需要依據具體場景靈活變動。

再次強調，無必要修改的“完美主義”重構，設計模式也不是最優先考慮的，優先完成，優先保證代碼清晰。