裝飾器模式

咱們都知道，可使用兩種方式給一個類或者對象添加行爲。

        一是使用繼承。繼承是給一個類添加行爲的比較有效的途徑。經過使用繼承，可使得子類在擁有自身方法的同時，還能夠擁有父類的方法。可是使用繼承是靜態的，在編譯的時候就已經決定了子類的行爲，咱們不便於控制增長行爲的方式和時機。

        二是使用關聯。組合即將一個對象嵌入到另外一個對象中，由另外一個對象來決定是否引用該對象來擴展本身的行爲。這是一種動態的方式，咱們能夠在應用程序中動態的控制。

        與繼承相比，關聯關係的優點就在於不會破壞類的封裝性，且具備較好的鬆耦合性，可使系統更加容易維護。可是它的缺點就在於要建立比繼承更多的對象。

        1、基本定義                                                                                                                     

        裝飾者模式，動態地將責任附加到對象上。若要擴展功能，裝飾者提供了比繼承更加有彈性的替代方案。

        2、模式結構                                                                                                                     

        裝飾者模式UML結構圖。

        Component: 抽象構件。是定義一個對象接口，能夠給這些對象動態地添加職責。

        ConcreteComponent:具體構件。是定義了一個具體的對象，也能夠給這個對象添加一些職責。

        Decorator: 抽象裝飾類。是裝飾抽象類，繼承了Component,從外類來擴展Component類的功能，但對於Component來講，是無需知道Decorator存在的。

        ConcreteDecorator:具體裝飾類，起到給Component添加職責的功能。

 

        3、實現裝飾者模式                                                                                                                                           

        情景模式：星巴茲以擴張速度快而聞名。在裏面購買咖啡時，能夠要求在其中加入各類調料，星巴茲會根據所加入的調料收取不一樣的費用，也就是說不一樣的咖啡與調料之間有N多不一樣的組合方式。每種咖啡和調料都有不一樣的收費。若是這個時候咱們使用繼承方式，則會陷入無以復加的地步。這裏會有N多個類，出現「類爆炸」現象。

        結構圖以下：

        裝飾者模式提供了一個比較好的解決方案。

        編碼實現：

        Component  Beverage.java

[java] view plaincopyprint?

1. public abstract class Beverage {  

2.     protected String description = "Unknown Beverage";  

3.   

4.     public String getDescription() {  

5.         return description;  

6.     }  

7.   

8.     public abstract double cost();  

9. }  

        四個組件：HouseBlend.java

[java] view plaincopyprint?

1. public class HouseBlend extends Beverage {  

2.   

3.     public HouseBlend(){  

4.         description = "HouseBlend";  

5.     }  

6.       

7.     @Override  

8.     public double cost() {  

9.         return 0.89;  

10.     }  

11.   

12. }  

        DarkRoast.java

[java] view plaincopyprint?

1. public class DarkRoast extends Beverage {  

2.     public DarkRoast(){  

3.         description = "DarkRoast";  

4.     }  

5.     @Override  

6.     public double cost() {  

7.         return 1.05;  

8.     }  

9.   

10. }  

        Espresso.java

[java] view plaincopyprint?

1. public class DarkRoast extends Beverage {  

2.     public DarkRoast(){  

3.         description = "DarkRoast";  

4.     }  

5.     @Override  

6.     public double cost() {  

7.         return 1.05;  

8.     }  

9.   

10. }  

        Decat.java

[java] view plaincopyprint?

1. public Decat(){  

2.     description = "Decat";  

3. }  

4.       

5. @Override  

6. public double cost() {  

7.     return 0.99;  

8. }  

        CondimentDecorator.java

[java] view plaincopyprint?

1. public abstract class CondimentDecorator extends Beverage{  

2.     public abstract String getDescription();  

3. }  

        Milk.java

[java] view plaincopyprint?

1. public class Milk extends CondimentDecorator {  

2.     Beverage beverage;  

3.       

4.     public Milk(Beverage beverage){  

5.         this.beverage = beverage;  

6.     }  

7.       

8.     @Override  

9.     public String getDescription() {  

10.         return beverage.getDescription() + " , Milk";  

11.     }  

12.   

13.     @Override  

14.     public double cost() {  

15.         return beverage.cost() + 0.3;  

16.     }  

17. }  

        Mocha.java

[java] view plaincopyprint?

1. public class Mocha extends CondimentDecorator {  

2.     Beverage beverage;  

3.     public Mocha(Beverage beverage){  

4.         this.beverage = beverage;  

5.     }  

6.       

7.     @Override  

8.     public String getDescription() {  

9.         return beverage.getDescription() + " , Mocha";  

10.     }  

11.   

12.     @Override  

13.     public double cost() {  

14.         return beverage.cost() + 0.20;  

15.     }  

16.   

17. }  

        Soy.java

[java] view plaincopyprint?

1. public class Soy extends CondimentDecorator{  

2.     Beverage beverage;  

3.     public Soy(Beverage beverage) {  

4.         this.beverage = beverage;  

5.     }  

6.     @Override  

7.     public String getDescription() {  

8.         return beverage.getDescription() + " , Soy";  

9.     }  

10.   

11.     @Override  

12.     public double cost() {  

13.         return beverage.cost() + 0.10;  

14.     }  

15.   

16. }  

        Whip.java

[java] view plaincopyprint?

1. public class Whip extends CondimentDecorator {  

2.     Beverage beverage;  

3.     public Whip(Beverage beverage){  

4.         this.beverage = beverage;  

5.     }  

6.     @Override  

7.     public String getDescription() {  

8.         return beverage.getDescription() + " , Whip";  

9.     }  

10.   

11.     @Override  

12.     public double cost() {  

13.         return beverage.cost() + 0.20;  

14.     }  

15.   

16. }  

        測試程序

[java] view plaincopyprint?

1. public class StarbuzzCoffee {  

2.   

3.     /** 

4.      * @param args 

5.      */  

6.     public static void main(String[] args) {  

7.         Beverage beverage = new Espresso();  

8.         System.out.println(beverage.getDescription() + " $" + beverage.cost());  

9.           

10.         Beverage beverage2 = new DarkRoast();  

11.         beverage2 = new Mocha(beverage2);  

12.         beverage2 = new Mocha(beverage2);  

13.         beverage2 = new Whip(beverage2);  

14.         System.out.println(beverage2.getDescription() + " $" + beverage2.cost());     

15.     }  

16.   

17. }  

        運行結果

        4、裝飾者模式的優缺點                                                                                                   

        優勢

           一、裝飾者模式能夠提供比繼承更多的靈活性

           二、能夠經過一種動態的方式來擴展一個對象的功能，在運行時選擇不一樣的裝飾器，從而實現不一樣的行爲。

           三、經過使用不一樣的具體裝飾類以及這些裝飾類的排列組合，能夠創造出不少不一樣行爲的組合。可使用多個具體裝飾類來裝飾同一對象，獲得功能更爲強大的對象。

           四、具體構件類與具體裝飾類能夠獨立變化，用戶能夠根據須要增長新的具體構件類和具體裝飾類，在使用時再對其進行組合，原有代碼無須改變，符合「開閉原則」。

 

        缺點

           一、會產生不少的小對象，增長了系統的複雜性

           二、這種比繼承更加靈活機動的特性，也同時意味着裝飾模式比繼承更加易於出錯，排錯也很困難，對於屢次裝飾的對象，調試時尋找錯誤可能須要逐級排查，較爲煩瑣。

 

        五、裝飾者模式的適用場景                                                                                              

                 一、在不影響其餘對象的狀況下，以動態、透明的方式給單個對象添加職責。

                 二、須要動態地給一個對象增長功能，這些功能也能夠動態地被撤銷。  當不能採用繼承的方式對系統進行擴充或者採用繼承不利於系統擴展和維護時。

        6、總結                                                                                                                          

                 一、 組合和委託能夠在運行時動態的添加新的行爲，而繼承是靜態的，在系統編譯時就已經決定了對象的行爲。

                 二、裝飾者模式意味着一羣裝飾者類，這些類用來包裝具體組件

                 三、裝飾者能夠在被裝飾者的行爲前面或者後面加上本身的行爲，甚至能夠將被裝飾者的行爲整個取代掉，從而達到特定的目的。

                 四、能夠用多個裝飾者包裝一個組件。

                 五、裝飾者通常對於組件的客戶是透明的，除非客戶程序依賴於組件的具體類型。

                 六、裝飾者會致使設計中出現許多的小對象，若是過分的使用，會讓系統變得更加複雜。

                 七、裝飾者和被裝飾者對象有相同的超類型。

圖以下：

Source類是被裝飾類，Decorator類是一個裝飾類，能夠爲Source類動態的添加一些功能，代碼以下：

[java] view plaincopy

1. public interface Sourceable {  

2.     public void method();  

3. }  

[java] view plaincopy

1. public class Source implements Sourceable {  

2.   

3.     @Override  

4.     public void method() {  

5.         System.out.println("the original method!");  

6.     }  

7. }  

[java] view plaincopy

1. public class Decorator implements Sourceable {  

2.   

3.     private Sourceable source;  

4.       

5.     public Decorator(Sourceable source){  

6.         super();  

7.         this.source = source;  

8.     }  

9.     @Override  

10.     public void method() {  

11.         System.out.println("before decorator!");  

12.         source.method();  

13.         System.out.println("after decorator!");  

14.     }  

15. }  

測試類：

[java] view plaincopy

1. public class DecoratorTest {  

2.   

3.     public static void main(String[] args) {  

4.         Sourceable source = new Source();  

5.         Sourceable obj = new Decorator(source);  

6.         obj.method();  

7.     }  

8. }  

輸出：

before decorator!
the original method!
after decorator!

裝飾器模式的應用場景：

一、須要擴展一個類的功能。

二、動態的爲一個對象增長功能，並且還能動態撤銷。（繼承不能作到這一點，繼承的功能是靜態的，不能動態增刪。）

缺點：產生過多類似的對象，不易排錯！