揭密設計模式：像搭樂高一樣構建功能的裝飾器模式
在軟件開發中，我們常常會遇到一個問題：如何給一個對象動態地添加新功能，同時又不想修改它的代碼？如果直接在原有類上修修補補，代碼會變得臃腫復雜，難以維護。
今天，我們就來聊一個能完美解決這個問題的設計模式——裝飾器模式 (Decorator Pattern) 。
什么是裝飾器模式？
簡單來說，裝飾器模式允許你在不改變一個對象原有代碼的前提下，為它增加新的職責或功能。 它就像是給一個基礎對象“穿上”不同的“配件”，每件“配件”都代表一個新功能。
從一杯咖啡開始理解裝飾器
為了更好地理解這個模式，我們來想象一下在咖啡店點咖啡的場景。
- 基礎對象（Base Component） ：首先，你有一杯最基礎的黑咖啡（BlackCoffee） 。它有自己的價格（比如5元）和描述（“黑咖啡”）。
- 裝飾器（Decorator） ：現在你想給這杯咖啡加點東西，比如牛奶（Milk）和糖（Sugar） 。我們把這些配料看作是“裝飾器”。它們本身也是咖啡的一種，只不過它們的作用是“包裹”另一杯咖啡，并在其基礎上增加新的功能。
這個模式的關鍵在于，無論是黑咖啡還是牛奶、糖，它們都遵循同一個接口（Interface） 。這個接口定義了所有飲料都必須具備的行為，比如 getDescription()（獲取描述）和 cost()（獲取價格）。
裝飾器模式的優勢
- 符合開閉原則：我們不需要修改
BlackCoffee類的代碼。如果未來想增加新的配料，比如“奶油”，我們只需要新增一個CreamDecorator類即可，對原有代碼完全無侵入。 - 避免“子類爆炸” ：如果不用裝飾器模式，我們可能需要創建
MilkCoffee、SugarCoffee、MilkSugarCoffee等大量子類來應對不同的組合。這會讓代碼變得異常復雜。裝飾器模式通過組合而非繼承的方式，巧妙地解決了這個問題。 - 動態組合功能：用戶可以根據需要，在運行時自由組合功能，比如先加奶再加糖，或者只加糖，非常靈活。
UML 類圖
為了更直觀地理解，我們來看一下裝飾器模式的 UML 類圖。
Beverage：定義了所有對象都必須實現的接口。BlackCoffee：具體組件，提供了最基礎的功能。BeverageDecorator：抽象裝飾器，繼承了接口并持有一個接口的引用。MilkDecorator和SugarDecorator：具體的裝飾器，用來添加新功能。
裝飾器模式在框架中的應用
除了我們自己手寫的代碼，裝飾器模式在許多成熟的框架中都有廣泛應用。
Java I/O 流
Java 的 I/O 流庫是裝飾器模式最經典的例子之一。InputStream 和 OutputStream 是最基礎的接口。而像 BufferedInputStream、DataInputStream、GZIPInputStream 等類，都是裝飾器。它們通過包裹一個基礎的 InputStream，為其添加新的功能，比如提供緩沖、處理基本數據類型、文件解壓縮等。
Spring 框架
在 Spring 框架中，裝飾器模式與代理模式的思想常常結合使用。當一個 Bean 被 Spring AOP 增強時，Spring 會創建一個代理對象。這個代理對象實際上就是裝飾器，它包裹著原始的 Bean 對象。當方法被調用時，代理對象會先執行一些額外的邏輯（比如事務的開啟和提交、日志的記錄），然后再將調用轉發給原始的 Bean 對象。這種設計使得 Spring 可以在不修改原始業務代碼的情況下，為其動態地添加橫切關注點（Cross-cutting Concerns），完美體現了裝飾器模式的精髓。
裝飾器模式與相似模式的對比
最后，為了更精確地理解裝飾器模式，我們來把它和兩個容易混淆的模式進行比較。
裝飾器模式 vs 代理模式
- 目的不同：裝飾器模式的目的是動態地增強一個對象的功能。而代理模式的目的是控制對一個對象的訪問。
- 聯系與區別：雖然兩者在結構上相似（都持有一個對目標對象的引用），但其意圖不同。在某些情況下（如 Spring AOP），代理既可以作為訪問控制的手段，也可以作為功能增強的方式，從而模糊了兩者之間的界限。
裝飾器模式 vs 組合模式
- 目的不同：裝飾器模式是為了增強一個單一對象的功能。而組合模式是為了將對象組織成樹形結構，以表示“部分-整體”的層次關系。
- 結構不同：在裝飾器模式中，裝飾器和被裝飾者都實現同一個接口。而在組合模式中，組合對象和葉子對象也實現同一個接口，但組合對象內部持有的是多個接口的引用（一個集合），目的是管理子對象。
Java 代碼實現
接下來，我們用 Java 來實現這個咖啡店的例子。
1. 統一接口：Beverage
首先，定義所有飲料都必須實現的接口。
// Beverage.java
public interface Beverage {String getDescription();double cost();
}
2. 具體組件：BlackCoffee
然后，我們創建最基礎的飲料類，它實現了 Beverage 接口。
// BlackCoffee.java
public class BlackCoffee implements Beverage {@Overridepublic String getDescription() {return "黑咖啡";}@Overridepublic double cost() {return 5.0;}
}
3. 抽象裝飾器：BeverageDecorator
為了讓所有裝飾器都具有統一的結構，我們創建一個抽象裝飾器類。它也實現了 Beverage 接口，并持有一個對 Beverage 對象的引用。所有的具體裝飾器都將繼承這個抽象類。
// BeverageDecorator.java
public abstract class BeverageDecorator implements Beverage {protected Beverage beverage;public BeverageDecorator(Beverage beverage) {this.beverage = beverage;}@Overridepublic abstract String getDescription();@Overridepublic abstract double cost();
}
4. 具體裝飾器：MilkDecorator 和 SugarDecorator
現在，我們創建具體的裝飾器類。它們繼承 BeverageDecorator 并重寫方法，在原有功能上添加新的職責。
// MilkDecorator.java
public class MilkDecorator extends BeverageDecorator {public MilkDecorator(Beverage beverage) {super(beverage);}@Overridepublic String getDescription() {// 在原有描述上添加 "加奶"return beverage.getDescription() + "，加奶";}@Overridepublic double cost() {// 在原有價格上加上牛奶的費用return beverage.cost() + 3.0;}
}
// SugarDecorator.java
public class SugarDecorator extends BeverageDecorator {public SugarDecorator(Beverage beverage) {super(beverage);}@Overridepublic String getDescription() {// 在原有描述上添加 "加糖"return beverage.getDescription() + "，加糖";}@Overridepublic double cost() {// 在原有價格上加上糖的費用return beverage.cost() + 1.0;}
}
5. 客戶端代碼：如何使用
最后，我們來看看如何將這些組件組合起來，構造出我們想要的咖啡。
// Main.java
public class Main {public static void main(String[] args) {// 1. 來一杯純黑咖啡Beverage blackCoffee = new BlackCoffee();System.out.println("描述: " + blackCoffee.getDescription() + "，價格: " + blackCoffee.cost());// 2. 來一杯加奶的黑咖啡Beverage milkCoffee = new MilkDecorator(blackCoffee);System.out.println("描述: " + milkCoffee.getDescription() + "，價格: " + milkCoffee.cost());// 3. 來一杯加奶又加糖的黑咖啡Beverage milkSugarCoffee = new SugarDecorator(milkCoffee);System.out.println("描述: " + milkSugarCoffee.getDescription() + "，價格: " + milkSugarCoffee.cost());}
}
運行結果：
描述: 黑咖啡，價格: 5.0
描述: 黑咖啡，加奶，價格: 8.0
描述: 黑咖啡，加奶，加糖，價格: 9.0
結語
裝飾器模式是一種強大且靈活的設計模式。它通過“包裹”而非修改的方式，讓我們可以像搭樂高積木一樣，動態地為對象添加和組合功能。當你的系統需要靈活擴展、避免大量子類時，不妨考慮一下這個精妙的模式。
)
)
