Java設計模式中的裝飾者模式詳解

本篇內容主要講解“Java設計模式中的裝飾者模式詳解”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Java設計模式中的裝飾者模式詳解”吧!

目錄

• 介紹

• 角色

• 示例代碼

• 星巴克咖啡的例子

• 方案一

• 方案二 ：將調料內置到Drink類中

• 方案三:裝飾者模式

• 代碼演示

• 裝飾者模式的簡化

• 透明性的要求

• 半透明的裝飾模式

• 裝飾模式的優點

• 裝飾模式的缺點

• 裝飾模式注意事項

• 適用場景

• 設計模式在JAVA I/O庫中的應用

• 透明和半透明的裝飾模式的區別

介紹

裝飾者模式(Decorator Pattern)：動態地給一個對象增加一些額外的職責，增加對象功能來說，裝飾模式比生成子類實現更為靈活。裝飾模式是一種對象結構型模式。

在裝飾者模式中，為了讓系統具有更好的靈活性和可擴展性，我們通常會定義一個抽象裝飾類，而將具體的裝飾類作為它的子類

裝飾模式以對客戶透明的方式動態地給一個對象附加上更多的責任。換言之，客戶端并不會覺得對象在裝飾前和裝飾后有什么不同。裝飾模式可以在不使用創造更多子類的情況下，將對象的功能加以擴展。

裝飾模式的類圖如下：

角色

• Component（抽象構件）：給出一個抽象接口，以規范準備接收附加責任的對象。

• ConcreteComponent（具體構件）：定義一個將要接收附加責任的類。

• Decorator（抽象裝飾類）：持有一個構件(Component)對象的實例，并定義一個與抽象構件接口一致的接口。

• ConcreteDecorator（具體裝飾類）：負責給構件對象“貼上”附加的責任。

由于具體構件類和裝飾類都實現了相同的抽象構件接口，因此裝飾模式以對客戶透明的方式動態地給一個對象附加上更多的責任，換言之，客戶端并不會覺得對象在裝飾前和裝飾后有什么不同。裝飾模式可以在不需要創造更多子類的情況下，將對象的功能加以擴展。

裝飾模式的核心在于抽象裝飾類的設計。

示例代碼

抽象構件角色

public interface Component {
    public void sampleOperation();
}

具體構件角色

public class ConcreteComponent implements Component {
    @Override
    public void sampleOperation() {
        // 寫相關的業務代碼
    }
}

裝飾角色

public class Decorator implements Component{
    private Component component;
    public Decorator(Component component){
        this.component = component;
    }
    @Override
    public void sampleOperation() {
        // 委派給構件
        component.sampleOperation();
    }
}

具體裝飾角色

public class ConcreteDecoratorA extends Decorator {
    public ConcreteDecoratorA(Component component) {
        super(component);
    }
    @Override
    public void sampleOperation() {
　　　　　super.sampleOperation();
        // 寫相關的業務代碼
    }
}

public class ConcreteDecoratorB extends Decorator {
    public ConcreteDecoratorB(Component component) {
        super(component);
    }
    @Override
    public void sampleOperation() {
　　　　  super.sampleOperation();
        // 寫相關的業務代碼
    }
}

星巴克咖啡的例子

方案一

加入不同調料的咖啡，例如：蒸奶（Steamed Milk）、豆漿（Soy）、摩卡（Mocha，也就是巧克力風味）或覆蓋奶泡。星巴茲會根據所加入的調料收取不同的費用。所以訂單系統必須考慮到這些調料部分。

方案二 ：將調料內置到Drink類中

這種設計雖然滿足了現在的需求，但是我們想一下，如果出現下面情況，我們怎么辦，

①、調料價錢的改變會使我們更改現有代碼。

②、一旦出現新的調料，我們就需要加上新的方法，并改變超類中的cost()方法。

③、以后可能會開發出新飲料。對這些飲料而言（例如：冰茶），某些調料可能并不適合，但是在這個設計方式中，Tea（茶）子類仍將繼承那些不適合的方法，例如：hasWhip()（加奶泡）。

④、萬一顧客想要雙倍摩卡咖啡，怎么辦？

很明顯，上面的設計并不能夠從根本上解決我們所碰到的問題。并且這種設計違反了 開放關閉原則（類應該對擴展開放，對修改關閉。）。

那我們怎么辦呢？好啦，裝飾者可以非常完美的解決以上的所有問題，讓我們有一個設計非常nice的咖啡館。

方案三:裝飾者模式

這里的Coffee是一個緩沖層，負責將抽取出所有具體咖啡的共同點

代碼演示

飲料抽象類：

public abstract class Drink
{
   protected String decription="";//描述
   public String getDecription() {
      return decription;
   }
   public abstract Integer cost();//返回飲料的價格
}

緩沖層：抽取出所有咖啡類的共同特征，即計算價錢

//緩沖層----所有種類咖啡的共同點抽取出來
public abstract class Coffee extends Drink
{
    //共同特點：計算價格
    @Override
    public Integer cost() {
        //價格從0累加
        return 0;
    }
}

具體的咖啡類:

public class LongBlack extends Coffee
{
    LongBlack()
    {
        decription="美式咖啡";
    }
    @Override
    public Integer cost() {
        return 15;
    }
}

public class ChinaBlack extends Coffee
{
    ChinaBlack()
    {
        decription="中式咖啡";
    }
    @Override
    public Integer cost() {
        return 10;
    }
}

public class Espresso extends Coffee
{
    //設置描述信息
    Espresso()
    {
        decription="意大利咖啡";
    }
    @Override
    public Integer cost() {
        //意大利咖啡20元
        return 20;
    }
}

抽象裝飾者

//裝飾者
public abstract class Decorator extends Drink
{
    @Override
    public abstract String getDecription();
}

具體裝飾者—即調料

public class Milk extends Decorator{
    Drink drink;
    Milk(Drink drink)
    {
        this.drink=drink;
    }
    @Override
    public String getDecription()
    {
        return "加了牛奶的"+this.drink.getDecription();
    }
    @Override
    public Integer cost()
    {
        return this.drink.cost()+3;
    }
}

public class Chocolate extends Decorator{
     //用一個實例變量記錄飲料，也就是被裝飾者
    Drink drink;
    Chocolate(Drink drink) {
       this.drink=drink;
    }
    @Override
    public String getDecription() {
        return "加了巧克力的"+drink.getDecription();
    }
    @Override
    public Integer cost() {
        //在原有飲料價格的基礎上加上調料味的價格
        return 5+drink.cost();
    }
}

測試

public class test
{
    @Test
    public void test()
    {
        //模擬下單
        //首先點一個美式咖啡，不加任何調料
        Drink drink=new LongBlack();
        System.out.println("購買了"+drink.getDecription()+"  花了"+drink.cost());
        //給美式咖啡加一個巧克力
        drink=new Chocolate(drink);
        System.out.println("購買了"+drink.getDecription()+"  花了"+drink.cost());
        //給美式咖啡再加一個牛奶
        drink=new Milk(drink);
        System.out.println("購買了"+drink.getDecription()+"  花了"+drink.cost());
        //再把牛奶和巧克力加一次
        drink=new Chocolate(drink);
        System.out.println("購買了"+drink.getDecription()+"  花了"+drink.cost());
        drink=new Milk(drink);
        System.out.println("購買了"+drink.getDecription()+"  花了"+drink.cost());
        System.out.println("====================================================");
        //簡化寫法
        Drink d=new Chocolate(new Milk(new ChinaBlack()));
        System.out.println("購買了"+d.getDecription()+"  花了"+d.cost());
    }
}

裝飾者模式的簡化

大多數情況下，裝飾模式的實現都要比上面給出的示意性例子要簡單。

如果只有一個ConcreteComponent類，那么可以考慮去掉抽象的Component類（接口），把Decorator作為一個ConcreteComponent子類。如下圖所示：

如果只有一個ConcreteDecorator類，那么就沒有必要建立一個單獨的Decorator類，而可以把Decorator和ConcreteDecorator的責任合并成一個類。甚至在只有兩個ConcreteDecorator類的情況下，都可以這樣做。如下圖所示：

透明性的要求

裝飾模式對客戶端的透明性要求程序不要聲明一個ConcreteComponent類型的變量，而應當聲明一個Component類型的變量。

用頂層抽象父類指向具體子類，以多態的形式實現透明性要求

應該像下面這樣寫:

Drink drink=new LongBlack();
//給美式咖啡加一個巧克力
drink=new Chocolate(drink);

而不是這樣寫

Drink drink=new LongBlack();
//給美式咖啡加一個巧克力
Chocolate drink=new Chocolate(drink);

半透明的裝飾模式

然而，純粹的裝飾模式很難找到。裝飾模式的用意是在不改變接口的前提下，增強所考慮的類的性能。

在增強性能的時候，往往需要建立新的公開的方法。

比如巧克力可以單獨售賣，即售賣巧克力棒，那么這里巧克力類里面需要新增加一個sell方法，用于單獨售賣

這就導致了大多數的裝飾模式的實現都是“半透明”的，而不是完全透明的。換言之，允許裝飾模式改變接口，增加新的方法。這意味著客戶端可以聲明ConcreteDecorator類型的變量，從而可以調用ConcreteDecorator類中才有的方法：

Drink drink=new LongBlack();
//給美式咖啡加一個巧克力
Chocolate drink=new Chocolate(drink);
//售賣巧克力棒
drink.sell();

半透明的裝飾模式是介于裝飾模式和適配器模式之間的。適配器模式的用意是改變所考慮的類的接口，也可以通過改寫一個或幾個方法，或增加新的方法來增強或改變所考慮的類的功能。大多數的裝飾模式實際上是半透明的裝飾模式，這樣的裝飾模式也稱做半裝飾、半適配器模式。

裝飾模式的優點

• 對于擴展一個對象的功能，裝飾模式比繼承更加靈活性，不會導致類的個數急劇增加。

• 可以通過一種動態的方式來擴展一個對象的功能，通過配置文件可以在運行時選擇不同的具體裝飾類，從而實現不同的行為。

• 可以對一個對象進行多次裝飾，通過使用不同的具體裝飾類以及這些裝飾類的排列組合，可以創造出很多不同行為的組合，得到功能更為強大的對象。

• 具體構件類與具體裝飾類可以獨立變化，用戶可以根據需要增加新的具體構件類和具體裝飾類，原有類庫代碼無須改變，符合 “開閉原則”。

裝飾模式的缺點

• 使用裝飾模式進行系統設計時將產生很多小對象，這些對象的區別在于它們之間相互連接的方式有所不同，而不是它們的類或者屬性值有所不同，大量小對象的產生勢必會占用更多的系統資源，在一定程序上影響程序的性能。

• 裝飾模式提供了一種比繼承更加靈活機動的解決方案，但同時也意味著比繼承更加易于出錯，排錯也很困難，對于多次裝飾的對象，調試時尋找錯誤可能需要逐級排查，較為繁瑣。

裝飾模式注意事項

(1) 盡量保持裝飾類的接口與被裝飾類的接口相同，這樣，對于客戶端而言，無論是裝飾之前的對象還是裝飾之后的對象都可以一致對待。這也就是說，在可能的情況下，我們應該盡量使用透明裝飾模式。

(2) 盡量保持具體構件類是一個“輕”類，也就是說不要把太多的行為放在具體構件類中，我們可以通過裝飾類對其進行擴展。

(3) 如果只有一個具體構件類，那么抽象裝飾類可以作為該具體構件類的直接子類。

適用場景

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

• 當不能采用繼承的方式對系統進行擴展或者采用繼承不利于系統擴展和維護時可以使用裝飾模式。不能采用繼承的情況主要有兩類：第一類是系統中存在大量獨立的擴展，為支持每一種擴展或者擴展之間的組合將產生大量的子類，使得子類數目呈爆炸性增長；第二類是因為類已定義為不能被繼承（如Java語言中的final類）

設計模式在JAVA I/O庫中的應用

裝飾模式在Java語言中的最著名的應用莫過于Java I/O標準庫的設計了

由于Java I/O庫需要很多性能的各種組合，如果這些性能都是用繼承的方法實現的，那么每一種組合都需要一個類，這樣就會造成大量性能重復的類出現。而如果采用裝飾模式，那么類的數目就會大大減少，性能的重復也可以減至最少。因此裝飾模式是Java I/O庫的基本模式。

Java I/O庫的對象結構圖如下，由于Java I/O的對象眾多，因此只畫出InputStream的部分。

下面是使用I/O流讀取文件內容的簡單操作示例。

public class IOTest {
    public static void main(String[] args) throws IOException {
        // 流式讀取文件
        DataInputStream dis = null;
        try{
            dis = new DataInputStream(
                    new BufferedInputStream(
                            new FileInputStream("test.txt")
                    )
            );
            //讀取文件內容
            byte[] bs = new byte[dis.available()];
            dis.read(bs);
            String content = new String(bs);
            System.out.println(content);
        }finally{
            dis.close();
        }
    }
}

觀察上面的代碼，會發現最里層是一個FileInputStream對象，然后把它傳遞給一個BufferedInputStream對象，經過BufferedInputStream處理，再把處理后的對象傳遞給了DataInputStream對象進行處理，這個過程其實就是裝飾器的組裝過程，FileInputStream對象相當于原始的被裝飾的對象，而BufferedInputStream對象和DataInputStream對象則相當于裝飾器。

透明和半透明的裝飾模式的區別

理想的裝飾模式在對被裝飾對象進行功能增強的同時，要求具體構件角色、裝飾角色的接口與抽象構件角色的接口完全一致。

而適配器模式則不然，一般而言，適配器模式并不要求對源對象的功能進行增強，但是會改變源對象的接口，以便和目標接口相符合。

裝飾模式有透明和半透明兩種，這兩種的區別就在于裝飾角色的接口與抽象構件角色的接口是否完全一致。

透明的裝飾模式也就是理想的裝飾模式，要求具體構件角色、裝飾角色的接口與抽象構件角色的接口完全一致。

相反，如果裝飾角色的接口與抽象構件角色接口不一致，也就是說裝飾角色的接口比抽象構件角色的接口寬的話，裝飾角色實際上已經成了一個適配器角色，這種裝飾模式也是可以接受的，稱為“半透明”的裝飾模式，如下圖所示

在適配器模式里面，適配器類的接口通常會與目標類的接口重疊，但往往并不完全相同。換言之，適配器類的接口會比被裝飾的目標類接口寬。

顯然，半透明的裝飾模式實際上就是處于適配器模式與裝飾模式之間的灰色地帶。如果將裝飾模式與適配器模式合并成為一個“包裝模式”的話，那么半透明的裝飾模式倒可以成為這種合并后的“包裝模式”的代表。

到此，相信大家對“Java設計模式中的裝飾者模式詳解”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！