首先拋開到處都有的文字概念。來看下面的例子。
現在以：人吃飯。這個需求為例。來講解這個設計模式。
1.0：想當年，人們都比較樸實。吃飯就是簡簡單單的吃飯。
那麼PersonBefore類裡面一個簡單的方法chifan()；

2.0：現如今，人們生活水平高了。吃飯的花樣也多了，簡單的吃飯已經不能滿足需求。
那麼怎麼修改原來的程式碼才合適呢。總不能分分鐘推到重構吧。

先看下面程式碼實現：

PersonBefore類，最原始的需求實現。

package com.lxk.designPattern.decorator;

/**
 * 被裝飾的類
 * (被增強物件)
 * <p>
 * Created by lxk on 2016/11/24
 */
public class PersonBefore {
    public void eat() {
        System.out.println("吃飯");
    }
}
 

package com.lxk.designPattern.decorator;

/**
 * 裝飾類
 * (要去增強目標物件的類)
 * 裝飾類通常會通過構造方法接收被裝飾的物件。
 * 並基於被裝飾的物件的功能，提供更強的功能。
 * <p>
 * Created by lxk on 2016/11/24
 */
public class PersonNow {
    private PersonBefore p;

    PersonNow(PersonBefore p) {
        this.p = p;
    }

    public void superChifan() {
        //簡單擴充套件
        System.out.println("開胃酒");
        p.eat();
        System.out.println("甜點");
        System.out.println("來一根菸");
    }
}
 

package com.lxk.designPattern.decorator;

/**
 * 裝飾設計模式：
 * 當想要對已有的物件進行功能增強時，
 * 可以定義類，將已有物件傳入，基於已有的功能，並提供加強功能。
 * 那麼自定義的該類稱為裝飾類。
 * <p>
 * 裝飾類通常會通過構造方法接收被裝飾的物件。
 * 並基於被裝飾的物件的功能，提供更強的功能。
 */

class PersonDemo {
    public static void main(String[] args) {
        PersonBefore p = new PersonBefore();
        //p.eat();//這個是需求1.0
        PersonNow sp = new PersonNow(p);
        sp.superChifan();
    }
}
 

下面是摘自某度文庫的--裝飾模式的概念的詳細文字描述。真不是分分鐘能明白說的都是啥。

裝飾模式:
在不必改變原類檔案和使用繼承的情況下，動態地擴充套件一個物件的功能。它是通過建立一個包裝物件，也就是裝飾來包裹真實的物件。

裝飾模式的特點
（1） 裝飾物件和真實物件有相同的介面。這樣客戶端物件就能以和真實物件相同的方式和裝飾物件互動。
（2） 裝飾物件包含一個真實物件的引用（reference）
（3） 裝飾物件接受所有來自客戶端的請求。它把這些請求轉發給真實的物件。
（4） 裝飾物件可以在轉發這些請求以前或以後增加一些附加功能。這樣就確保了在執行時，不用修改給定物件的結構就可以在外部增加附加的功能。在面向物件的設計中，通常是通過繼承來實現對給定類的功能擴充套件。

適用性
以下情況使用Decorator模式
1. 需要擴充套件一個類的功能，或給一個類新增附加職責。
2. 需要動態的給一個物件新增功能，這些功能可以再動態的撤銷。
3. 需要增加由一些基本功能的排列組合而產生的非常大量的功能，從而使繼承關係變的不現實。
4. 當不能採用生成子類的方法進行擴充時。一種情況是，可能有大量獨立的擴充套件，為支援每一種組合將產生大量的子類，使得子類數目呈爆炸性增長。另一種情況可能是因為類定義被隱藏，或類定義不能用於生成子類。

優點
1. Decorator模式與繼承關係的目的都是要擴充套件物件的功能，但是Decorator可以提供比繼承更多的靈活性。
2. 通過使用不同的具體裝飾類以及這些裝飾類的排列組合，設計師可以創造出很多不同行為的組合。

缺點
1. 這種比繼承更加靈活機動的特性，也同時意味著更加多的複雜性。
2. 裝飾模式會導致設計中出現許多小類，如果過度使用，會使程式變得很複雜。
3. 裝飾模式是針對抽象元件（Component）型別程式設計。但是，如果你要針對具體元件程式設計時，就應該重新思考你的應用架構，以及裝飾者是否合適。當然也可以改變Component介面，增加新的公開的行為，實現“半透明”的裝飾者模式。在實際專案中要做出最佳選擇。

實際使用
java IO 流是典型的裝飾模式。

這倒是真的，看前2篇 BufferedReader BufferedWriter 都是把字元讀寫流資源作為引數，傳進類內部，對其進行功能增強。使得讀寫的效率得到提高。果然是實際使用此模式的好例子。