問題來源

我們在進行軟件系統設計的時候，有一些業務（如下圖，一些通用的非功能性需求）是多個模塊都需要的，是跨越模塊的。把它們放到什么地方呢？

最簡單的辦法就是把這些通用模塊的接口寫好，讓程序員在實現業務模塊的時候去調用。

這樣做的缺點是，日志、安全、事務、統計性能等相關代碼幾乎把真正的業務代碼淹沒了。重復的代碼會變得非常多。

設計模式：模板方法

調用方式很簡單：

BaseCommand cmd = new PlaceOrderCommand(xxx); cmd.execute();

子類變得很清爽，只需要關注業務邏輯就可以了。

這種方式的巨大缺陷是：父類會定義一切。要定義哪些非功能性代碼、執行順序，子類都只能無條件接受。如果有一個子類，根本不需要某個功能，也無法去掉。

設計模式：裝飾器模式

現在讓這個 PlaceHolderCommand 能夠打印日志，進行性能統計：

Command cmd = new LoggerDecorator(new PerformanceDecorator(new PlaceOrderCommand())); cmd.execute();

如果 PaymantCommand 只需要打印日志，那么裝飾一次就可以了。

Command cmd = new LoggerDecorator(new PaymentCommand()); cmd.execute();

可以使用任意數量的裝飾器，還可以以任意次序執行，是不是很靈活？

總結

以上是生活随笔為你收集整理的【设计模式】装饰器模式的使用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。