裝飾模式是第三個介紹的模式了.

這個模式沒有前面兩個那么好理解.,

一, 裝飾模式(decorator)的定義.

教材里是這樣寫的:

動態第給1個對象添加1寫額外的職責(功能), 就增加的功能來講, 裝飾模式比生成子類更加靈活.

就咁睇的確很難明白. 但我們起碼可以知道一下兩點:

1. 裝飾模式的作用是增強1個對象(類) 的功能.

2. 它比生成子類更加靈活.

本文著重講下第2點, 包括什么是生成子類,? 為什么裝飾模式比它更加靈活.

二, 1個Hunter1(獵人)類的例子.

舉1個很簡單的例子. 1個獵人類實現1個打獵的接口.

Huntable 接口:

public interface Huntable {public void hunt(); }

獵人類Hunter1:

public class Hunter1 implements Huntable{public void eat(){System.out.println("eating!");}public void hunt(){System.out.println("Hunter is Hunting!");} }

可見Hunter1這個類實現了Huntable借口.?

hunt()方法里只簡單重寫了hunt()方法.

客戶端代碼:

Hunter1 h = new Hunter1(); h.hunt();

輸出:

Hunter is Hunting!

1個增強hunt()方法的需求:

好了, 現在有1個獵人, 他出去不只是打獵,? 他打獵的同時還同時訓練它的獵狗, 最后還會給戰利品拍一張照片.

也就是需要增強hunt()方法功能.

加上

trainDog() 和 takePic()這個兩個方法.

怎么實現呢?

三, 通過添加子類Hunter2方法來增強Hunter1

open-closed principle:

可能有人會覺得. 直接在Hunter1里加上兩個方法trainDog () 和? takePic(),? 在hunt()里調用這個兩個新方法不就完事了嗎.

的確, 但是這種做法修改了原有的類,? 違反了"封閉-開放原則".?

所謂"封閉-開發原則" 就是對修改封閉, 對擴展開放.

在項目中, 很多舊的業務類根本不會讓你修改(jar包發布或者你沒有權限)

所以我們應該把這個新需求當做1個擴展來處理, 而不是修改舊代碼.

其中1個方法就是增加子類.

新增1個Hunter2 類:

public class Hunter2 extends Hunter1{@Overridepublic void hunt(){super.hunt();this.trainDog();this.takePic();}//new function()public void trainDog(){System.out.println("Train the Dog!");}public void takePic(){System.out.println("Take a picture!");} }

客戶端代碼:

Hunter2 h2 = new Hunter2(); h2.hunt();

UML:

可見, 這種方法, 只是新增了1個子類, 以及修改客戶端代碼, 對原來的類代碼沒有任何修改, 是符合"封閉-修改 原則"的.

這種修改, 增強了原來的類Hunter1 的hunt()功能, 可以說是"裝飾"了原來的hunt()方法.

但是這種修改不是很靈活.

比如:?? 這種獵人是先打獵,再訓狗,再拍照的.

??????????? 如果有一種獵人喜歡先拍照再訓狗了,? 我們就又要增加1個Hunter1的子類了....

而裝飾模式能解決問題.

四, 通過裝飾模式來增強Hunter類.

Huntable 接口 和 Hunter類:

首先構造兩個相同的接口和類:

public interface Huntable {public void hunt(); }

public class Hunter implements Huntable {public void eat(){System.out.println("eating!");}@Overridepublic void hunt(){System.out.println("Hunter is Hunting!");} }
Hunter類跟上面的Hunter1類是完全一樣的.

下面開始構造新的類來強化hunt()方法.

抽象裝飾角色類?? HuntOperation:

無論, 是訓狗trainDog() 還是拍照takePic() 都是對hunt()的增強.

我們新增1個HuntOperation類,? 讓它繼承Hunter類,? 讓它能重寫hunt()方法.

public abstract class HuntOperation extends Hunter{private Hunter hunter = null;//setting componentpublic HuntOperation(Hunter hunter){this.hunter = hunter;}//actually execute component's hunt() method@Overridepublic void hunt(){if (null != hunter){hunter.hunt();}} }

注意, 這個類有1個Hunter對象成員.

在hunt()方法里, 執行的實際上是成員Hunter對象的hunt()方法.

具體的裝飾行為類 HuntTakePic():

照相類, 就讓它繼承抽象行為類 HuntOperation類.

public class HuntTakePic extends HuntOperation{public HuntTakePic(Hunter hunter) {super(hunter);}@Overridepublic void hunt(){super.hunt();this.takePic();}public void takePic(){System.out.println("Taking a Picture!");} }

可見, 它先執行性成員Hunter對象的hunt()方法, 在執行自己的照相方法.

具體的裝飾行為類 HuntTrainDog():

同樣, 這個類也繼承HuntOperation.

先執行Hunter對象的hunt()方法, 再執行自己的TrainDog方法.

public class HuntTrainDog extends HuntOperation{public HuntTrainDog(Hunter hunter) {super(hunter);// TODO Auto-generated constructor stub}@Overridepublic void hunt(){super.hunt();this.trainDog();}public void trainDog(){System.out.println("Training the dog!");}}

客戶端代碼:

客戶端代碼如下:

先構建1個Hunter對象h, 然后再基于h構建HuntTakePic htp,? 然后在基于htp構建HuntTrainDog 對象htd.

最后執行htd的hunt()方法.

Hunter h = new Hunter();HuntTakePic htp = new HuntTakePic(h);HuntTrainDog htd = new HuntTrainDog(htp);htd.hunt();

實際上, 就先執行Hunter對象的hunt(), 再執行HuntTakePic對象的hunt(), 最后才執行HuntTrainDog對象的hunt()

輸出:

Hunter is Hunting! Taking a Picture! Training the dog!

UML:

裝飾模式的靈活性:

好了, 這種模式一樣能增強Hunter類的hunt()

那么它到底比第一種方法靈活在哪里呢.

很簡單, 假如另1類獵人想調換訓狗, 和照相的順序, 只需修改客戶端的構建循序, 并需要再新增1個子類.

這就是裝飾模式的靈活性.

有人會覺得, 裝飾模式同樣需要增加子類啊,? 實際上, 假如我們為Hunter的hunt()再增加1個子行為, 例如給獵物剝皮.

那么只需要增加1個抽象行為HuntOperation的子類, 而不是Hunter的子類..

五, 小結

其實想深一層, 裝飾模式之所以叫裝飾模式.

是因為裝飾不能改變原有的功能的行為.

就如上面的例子,? Hunter里原來的hunt()方法沒有改變,? 只是增加了一些額外的功能.

所以如果需要從根本上改變Hunter里hunt()的代碼, 裝飾模式就不適用了,? 還是建議用增加Hunter子類的方法.

總結

以上是生活随笔為你收集整理的装饰模式(Decorator)简介的全部內容，希望文章能夠幫你解決所遇到的問題。

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