前言

 IO 包中是用了大量的裝飾器模式

為了弄明白裝飾器模式的本質，我查看了很多資料，發現有很多文章要麼說的很苦澀，要麼舉的例子不恰當。

其實我們可以這樣理解裝飾器模式， 就拿自己舉例子，你把自己裸體的樣子，想象成被裝飾的物件。你的鞋子，你的寸衣，你的外套，你的手錶，你的帽子 等等，都是你的裝飾物，你和這些裝飾物，是裝飾和被裝飾的關係。

例項展示

好了，現在我們用程式碼的方法去理解這樣概念。

首先，我們發現，不管是裸體的人，還是你的鞋子、帽子，都有展示的功能，我們稱之為show 方法。

我們定義一個介面，它具有展示的功能，也就是show() , 

package com.user;

/**
* 定義介面
* @author T
*
*/
public interface AbstractPerson {

//具有展示的功能
void show() ;
}

現在應該定義一個裸體的自己了，Me 類

package com.user;

/**
* 定義一個具體的人，就是被裝飾者
* @author T
*
*/
public class Me implements AbstractPerson {

@Override
public void show() {
System.out.println( "什麼都沒穿，我展示的是裸體");
}

}
 

下面該定義，鞋子，帽子，手錶等 裝飾物，等等先別急，我們應該先定義一個鞋子，帽子，手錶的抽象父類 AbstractClothes 。 
其實抽象的父類有一個建構函式，建構函式裡面的引數是抽象的人類，這裡的用法很巧妙，這也是能夠實現裝飾功能的一個必不可少的步驟。

package com.user;

/**
* 定義抽象裝飾物
* @author T
*
*/
public abstract class AbstractClothes implements AbstractPerson {

AbstractPerson abstractPerson ;

 
public AbstractClothes( AbstractPerson abstractPerson ){
this.abstractPerson = abstractPerson ;
}

@Override
public void show() {
abstractPerson.show();
}

}

下面開始定義，帽子裝飾物  Hat 類， 繼承 AbstractClothes 類

package com.user;

/**
* 帽子裝飾物
* @author T
*
*/
public class Hat extends AbstractClothes {

public Hat(AbstractPerson abstractPerson) {
super(abstractPerson);
}

@Override
public void show() {
super.show();
say();
}

public void say(){
System.out.println( "我展示一個帽子");
}

}

定義鞋子裝飾類 Shoes ,   繼承 AbstractClothes 類

package com.user;

/**
* 鞋子裝飾物
* @author T
*
*/
public class Shoes extends AbstractClothes {

public Shoes(AbstractPerson abstractPerson) {
super(abstractPerson);
}

@Override
public void show() {
super.show();
say();
}

public void say(){
System.out.println( "我展示一雙鞋子");
}
}

建立測試類 Test

package com.user;

public class Test {

public static void main(String[] args) {
　　//建立被裝飾者
　　Me me = new Me() ;
　　//裸體的人被裝飾了帽子 ，具有了展示帽子的能力
　　Hat hat = new Hat( me ) ;
　　// 帶了帽子的人被裝飾了鞋子，具有了展示鞋子的本領
　　Shoes shoes = new Shoes( hat ) ;
　　shoes.show();
　}
}

執行結果：
什麼都沒穿，我展示的是裸體
我展示一個帽子
我展示一雙鞋子
裝飾器模式的類圖

在學習完了一個小例子之後，我們試著總結出裝飾器模式的類圖。

裝飾器模式類圖：

Component抽象構件角色：真實物件和裝飾物件有相同的介面。這樣，客戶端物件就能夠以與真實物件相同的方式同裝飾物件互動。
ConcreteCompoent具體構建角色(真實物件)：定義一個將要接收附加責任的類。
Decorator裝飾角色：持有一個抽象構件的引用。裝飾物件接受所有客戶端的請求，並把這些請求轉發給真實的物件。這樣，就能在真實物件呼叫前後增加新的功能。
ConcreteDecorate具體裝飾角色：負責給構件物件增加新的功能。
裝模式在Java I/O庫中的應用
IO流實現細節：

Component抽象構件角色：io流中的InputStream,OutputStream,Reader,Writer
ConcreteComponent具體構件角色：io流中的FileInputStream,FileOutputStream
Decorate裝飾角色：持有抽象構件的引用，FilterInputStream,FilterOutputStream
ConcreteDecorate具體裝飾角色：負責給構件物件新增新的責任，BufferedInputStream,BufferedOutputStream等
總結
裝飾模式(Decorate)也叫包裝模式(Wrapper)
裝飾模式降低系統的耦合度，可以動態的增加或刪除物件的責任，並使得需要裝飾的具體構建類和具體裝飾類可以獨立變化，以便增加新的具體構建類和具體裝飾類。
優點
 擴充套件物件功能，比繼承靈活，不會導致類個數急劇增加。
可以對一個物件進行多次裝飾，創造出不同行為的組合，得到功能更加強大的物件。
具體構 件 類和具體裝飾類可以獨立變化，使用者可以根據需要自己增加新的 具體構件子類和具體裝飾子類。
缺點
產生很多小物件。大量小的物件佔據記憶體，一定程度上影響效能。
裝飾模式易出錯，除錯排查比較麻煩。
---------------------

原文：https://blog.csdn.net/zhaoyanjun6/article/details/56488020