介紹

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

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

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

裝飾模式的類圖如下：

角色

• Component（抽象構(gòu)件）：給出一個抽象接口，以規(guī)范準(zhǔn)備接收附加責(zé)任的對象。
• ConcreteComponent（具體構(gòu)件）：定義一個將要接收附加責(zé)任的類。
• Decorator（抽象裝飾類）：持有一個構(gòu)件(Component)對象的實例，并定義一個與抽象構(gòu)件接口一致的接口。
• ConcreteDecorator（具體裝飾類）：負責(zé)給構(gòu)件對象“貼上”附加的責(zé)任。

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

裝飾模式的核心在于抽象裝飾類的設(shè)計。

示例代碼

抽象構(gòu)件角色

public interface Component {
    public void sampleOperation();
}

具體構(gòu)件角色

public class ConcreteComponent implements Component {
    @Override
    public void sampleOperation() {
        // 寫相關(guān)的業(yè)務(wù)代碼
    }
}

裝飾角色

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

具體裝飾角色

public class ConcreteDecoratorA extends Decorator {
    public ConcreteDecoratorA(Component component) {
        super(component);
    }
    @Override
    public void sampleOperation() {
　　　　　super.sampleOperation();
        // 寫相關(guān)的業(yè)務(wù)代碼
    }
}

public class ConcreteDecoratorB extends Decorator {
    public ConcreteDecoratorB(Component component) {
        super(component);
    }
    @Override
    public void sampleOperation() {
　　　　  super.sampleOperation();
        // 寫相關(guān)的業(yè)務(wù)代碼
    }
}

星巴克咖啡的例子

方案一

加入不同調(diào)料的咖啡，例如：蒸奶（Steamed Milk）、豆?jié){（Soy）、摩卡（Mocha，也就是巧克力風(fēng)味）或覆蓋奶泡。星巴茲會根據(jù)所加入的調(diào)料收取不同的費用。所以訂單系統(tǒng)必須考慮到這些調(diào)料部分。

方案二 ：將調(diào)料內(nèi)置到Drink類中

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

①、調(diào)料價錢的改變會使我們更改現(xiàn)有代碼。

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

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

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

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

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

方案三:裝飾者模式

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

代碼演示

飲料抽象類：

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
{
    //設(shè)置描述信息
    Espresso()
    {
        decription="意大利咖啡";
    }
    @Override
    public Integer cost() {
        //意大利咖啡20元
        return 20;
    }
}

抽象裝飾者

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

具體裝飾者—即調(diào)料

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() {
        //在原有飲料價格的基礎(chǔ)上加上調(diào)料味的價格
        return 5+drink.cost();
    }
}

測試

public class test
{
    @Test
    public void test()
    {
        //模擬下單
        //首先點一個美式咖啡，不加任何調(diào)料
        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());
    }
}

裝飾者模式的簡化

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

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

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

透明性的要求

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

用頂層抽象父類指向具體子類，以多態(tài)的形式實現(xiàn)透明性要求

應(yīng)該像下面這樣寫:

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

而不是這樣寫

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

半透明的裝飾模式

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

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

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

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

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

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

裝飾模式的優(yōu)點

• 對于擴展一個對象的功能，裝飾模式比繼承更加靈活性，不會導(dǎo)致類的個數(shù)急劇增加。
• 可以通過一種動態(tài)的方式來擴展一個對象的功能，通過配置文件可以在運行時選擇不同的具體裝飾類，從而實現(xiàn)不同的行為。
• 可以對一個對象進行多次裝飾，通過使用不同的具體裝飾類以及這些裝飾類的排列組合，可以創(chuàng)造出很多不同行為的組合，得到功能更為強大的對象。
• 具體構(gòu)件類與具體裝飾類可以獨立變化，用戶可以根據(jù)需要增加新的具體構(gòu)件類和具體裝飾類，原有類庫代碼無須改變，符合 “開閉原則”。

裝飾模式的缺點

• 使用裝飾模式進行系統(tǒng)設(shè)計時將產(chǎn)生很多小對象，這些對象的區(qū)別在于它們之間相互連接的方式有所不同，而不是它們的類或者屬性值有所不同，大量小對象的產(chǎn)生勢必會占用更多的系統(tǒng)資源，在一定程序上影響程序的性能。
• 裝飾模式提供了一種比繼承更加靈活機動的解決方案，但同時也意味著比繼承更加易于出錯，排錯也很困難，對于多次裝飾的對象，調(diào)試時尋找錯誤可能需要逐級排查，較為繁瑣。

裝飾模式注意事項

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

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

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

適用場景

• 在不影響其他對象的情況下，以動態(tài)、透明的方式給單個對象添加職責(zé)。
• 當(dāng)不能采用繼承的方式對系統(tǒng)進行擴展或者采用繼承不利于系統(tǒng)擴展和維護時可以使用裝飾模式。不能采用繼承的情況主要有兩類：第一類是系統(tǒng)中存在大量獨立的擴展，為支持每一種擴展或者擴展之間的組合將產(chǎn)生大量的子類，使得子類數(shù)目呈爆炸性增長；第二類是因為類已定義為不能被繼承（如Java語言中的final類）

設(shè)計模式在JAVA I/O庫中的應(yīng)用

裝飾模式在Java語言中的最著名的應(yīng)用莫過于Java I/O標(biāo)準(zhǔn)庫的設(shè)計了

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

Java I/O庫的對象結(jié)構(gòu)圖如下，由于Java I/O的對象眾多，因此只畫出InputStream的部分。

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

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

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

透明和半透明的裝飾模式的區(qū)別

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

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

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

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

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

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

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

參考文章

設(shè)計模式 | 裝飾者模式及典型應(yīng)用

《JAVA與模式》之裝飾模式

設(shè)計模式之裝飾者模式

總結(jié)

本篇文章就到這里了，希望能夠給你帶來幫助，也希望您能夠多多關(guān)注腳本之家的更多內(nèi)容！