介紹

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

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

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

裝飾模式的類圖如下：

角色

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

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

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

示例代碼

抽象構(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)味）或覆蓋奶泡。星巴茲會(huì)根據(jù)所加入的調(diào)料收取不同的費(fèi)用。所以訂單系統(tǒng)必須考慮到這些調(diào)料部分。

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

這種設(shè)計(jì)雖然滿足了現(xiàn)在的需求，但是我們想一下，如果出現(xiàn)下面情況，我們?cè)趺崔k，

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

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

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

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

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

那我們?cè)趺崔k呢？好啦，裝飾者可以非常完美的解決以上的所有問題，讓我們有一個(gè)設(shè)計(jì)非常nice的咖啡館。

方案三:裝飾者模式

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

代碼演示

飲料抽象類：

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

緩沖層：抽取出所有咖啡類的共同特征，即計(jì)算價(jià)錢

//緩沖層----所有種類咖啡的共同點(diǎn)抽取出來
public abstract class Coffee extends Drink
{
    //共同特點(diǎn)：計(jì)算價(jià)格
    @Override
    public Integer cost() {
        //價(jià)格從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{
     //用一個(gè)實(shí)例變量記錄飲料，也就是被裝飾者
    Drink drink;
    Chocolate(Drink drink) {
       this.drink=drink;
    }
    @Override
    public String getDecription() {
        return "加了巧克力的"+drink.getDecription();
    }
    @Override
    public Integer cost() {
        //在原有飲料價(jià)格的基礎(chǔ)上加上調(diào)料味的價(jià)格
        return 5+drink.cost();
    }
}

測(cè)試

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

裝飾者模式的簡(jiǎn)化

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

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

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

透明性的要求

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

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

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

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

而不是這樣寫

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

半透明的裝飾模式

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

在增強(qiáng)性能的時(shí)候，往往需要建立新的公開的方法。

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

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

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

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

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

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

裝飾模式的缺點(diǎn)

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

裝飾模式注意事項(xiàng)

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

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

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

適用場(chǎng)景

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

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

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

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

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

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

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();
        }
    }
}

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

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

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

而適配器模式則不然，一般而言，適配器模式并不要求對(duì)源對(duì)象的功能進(jìn)行增強(qiáng)，但是會(huì)改變?cè)磳?duì)象的接口，以便和目標(biāo)接口相符合。

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

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

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

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

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

參考文章

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

《JAVA與模式》之裝飾模式

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

總結(jié)

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

最新評(píng)論