問題**
我們在進行軟體系統設計的時候,有一些業務(如下圖,一些通用的非功能性需求)是多個模組都需要的,是跨越模組的。把它們放到什麼地方呢?
最簡單的辦法就是把這些通用模組的介面寫好,讓程式設計師在實現業務模組的時候去呼叫。
這樣做的缺點是,日誌、安全、事務、統計效能等相關**幾乎把真正的業務**淹沒了。重複的**會變得非常多。
設計模式:模板方法
呼叫方式很簡單:
basecommand cmd =
newplaceordercommand
(***)
;cmd.
execute()
;
子類變得很清爽,只需要關注業務邏輯就可以了。
這種方式的巨大缺陷是:父類會定義一切。要定義哪些非功能性**、執行順序,子類都只能無條件接受。如果有乙個子類,根本不需要某個功能,也無法去掉。
設計模式:裝飾器模式
現在讓這個placeholdercommand
能夠列印日誌,進行效能統計:
command cmd =
newloggerdecorator
(new
performancedecorator
(new
placeordercommand()
));cmd.
execute()
;
如果paymantcommand
只需要列印日誌,那麼裝飾一次就可以了。
command cmd =
newloggerdecorator
(new
paymentcommand()
);cmd.
execute()
;
可以使用任意數量的裝飾器,還可以以任意次序執行,是不是很靈活? 設計模式 裝飾器模式
裝飾器模式 decorator pattern 允許向乙個現有的物件新增新的功能,同時又不改變其結構。這種型別的設計模式屬於結構型模式,它是作為現有的類的乙個包裝。這種模式建立了乙個裝飾類,用來包裝原有的類,並在保持類方法簽名完整性的前提下,提供了額外的功能。public inte ce playe...
設計模式 裝飾器模式
裝飾者模式的應用場景 裝飾者模式 decorator pattern 是指在不改變原有物件的基礎之上,將功能附加到物件上,提供了比繼承更有彈性的替代方案 擴充套件原有物件的功能 屬於結構型模式。裝飾者模式在我們生活中應用也比較多如給煎餅加雞蛋 給蛋糕加上一些水果 給房子裝修等,為物件擴充套件一些額外...
設計模式 裝飾器模式
定義 裝飾模式可以動態的給乙個物件增加一些額外的功能 增強功能 相比於繼承,裝飾模式能對不支援繼承的類進行增強 並且比繼承更靈活,不需要生成大量的子類。角色 實現 public abstract class house public abstract void sleep public class ...