JDK中的設(shè)計(jì)模式簡(jiǎn)介

這篇文章主要講解了“JDK中的設(shè)計(jì)模式簡(jiǎn)介”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“JDK中的設(shè)計(jì)模式簡(jiǎn)介”吧！

設(shè)計(jì)模式是什么

（1）反復(fù)出現(xiàn)問題的解決方案
（2）增強(qiáng)軟件的靈活性
（3）適應(yīng)軟件不斷變化

學(xué)習(xí)JDK中設(shè)計(jì)模式的好處

（1）借鑒優(yōu)秀代碼的設(shè)計(jì)，有助于提高代碼設(shè)計(jì)能力
（2）JDK的設(shè)計(jì)中體現(xiàn)了大多數(shù)設(shè)計(jì)模式，是學(xué)習(xí)設(shè)計(jì)模式的較好的方式
（3）可以更加深入的了解JDK

類間關(guān)系

繼承、委托、依賴、聚合、組合

介紹方式

（1）作用：歸納某設(shè)計(jì)模式的基本要點(diǎn)
（2）JDK中體現(xiàn)：某設(shè)計(jì)模式在JDK中是怎樣體現(xiàn)出來的
（3）類圖：某設(shè)計(jì)模式在JDK中所對(duì)應(yīng)的類圖

經(jīng)典設(shè)計(jì)模式在JDK中的體現(xiàn)

1.Singleton（單例）
作用：保證類只有一個(gè)實(shí)例；提供一個(gè)全局訪問點(diǎn)
JDK中體現(xiàn)：
（1）Runtime
（2）NumberFormat
類圖：

靜態(tài)工廠

作用：
（1）代替構(gòu)造函數(shù)創(chuàng)建對(duì)象
（2）方法名比構(gòu)造函數(shù)清晰
JDK中體現(xiàn)：
（1）Integer.valueOf
（2）Class.forName

類圖：

工廠方法

作用：子類決定哪一個(gè)類實(shí)例化
JDK中體現(xiàn)：Collection.iterator方法

類圖：

建造者模式

作用：
（1）將構(gòu)造邏輯提到單獨(dú)的類中
（2）分離類的構(gòu)造邏輯和表現(xiàn)
JDK中體現(xiàn)：DocumentBuilder(org.w3c.dom)

類圖：

原型模型

作用：
（1）復(fù)制對(duì)象
（2）淺復(fù)制、深復(fù)制
JDK中體現(xiàn)：Object.clone；Cloneable
類圖：

適配器模式

作用：使不兼容的接口相容
JDK中體現(xiàn)：
（1）java.io.InputStreamReader(InputStream)
（2）java.io.OutputStreamWriter(OutputStream)

類圖：

橋接模式

作用：將抽象部分與其實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立地變化
JDK中體現(xiàn)：java.util.logging中的Handler和Formatter

類圖：

組合模式

作用：一致地對(duì)待組合對(duì)象和獨(dú)立對(duì)象
    JDK中體現(xiàn)：
    （1）org.w3c.dom
    （2）javax.swing.JComponent#add(Component)

類圖：

裝飾者模式

作用：為類添加新的功能；防止類繼承帶來的爆炸式增長(zhǎng)
JDK中體現(xiàn)：
（1）java.io包
（2）java.util.Collections#synchronizedList(List)

類圖：

外觀模式

作用：
（1）封裝一組交互類，一致地對(duì)外提供接口
（2）封裝子系統(tǒng)，簡(jiǎn)化子系統(tǒng)調(diào)用
JDK中體現(xiàn)：java.util.logging包

類圖：

享元模式

作用：共享對(duì)象，節(jié)省內(nèi)存
JDK中體現(xiàn)：
（1）Integer.valueOf(int i)；Character.valueOf(char c)
（2）String常量池

類圖：
**

代理模式

作用：
（1）透明調(diào)用被代理對(duì)象，無須知道復(fù)雜實(shí)現(xiàn)細(xì)節(jié)
（2）增加被代理類的功能
JDK中體現(xiàn)：動(dòng)態(tài)代理；RMI

類圖：
**

迭代器模式

作用：將集合的迭代和集合本身分離
JDK中體現(xiàn)：Iterator、Enumeration接口

類圖：

觀察者模式

作用：通知對(duì)象狀態(tài)改變
JDK中體現(xiàn)：
（1）java.util.Observer,Observable
（2）Swing中的Listener

類圖：
**

模板方法模式

作用：定義算法的結(jié)構(gòu)，子類只實(shí)現(xiàn)不同的部分
JDK中體現(xiàn)：ThreadPoolExecutor.Worker

類圖：

策略模式

作用：提供不同的算法
JDK中的體現(xiàn)：ThreadPoolExecutor中的四種拒絕策略

類圖：

責(zé)任鏈模式

作用：請(qǐng)求會(huì)被鏈上的對(duì)象處理，但是客戶端不知道請(qǐng)求會(huì)被哪些對(duì)象處理
JDK中體現(xiàn)：
（1）java.util.logging.Logger會(huì)將log委托給parent logger
（2）ClassLoader的委托模型

類圖：

命令模式

作用：
（1）封裝操作，使接口一致
（2）將調(diào)用者和接收者在空間和時(shí)間上解耦合
JDK中體現(xiàn)：Runnable；Callable；ThreadPoolExecutor

類圖：

狀態(tài)模式

作用：將主對(duì)象和其狀態(tài)分離，狀態(tài)對(duì)象負(fù)責(zé)主對(duì)象的狀態(tài)轉(zhuǎn)換，使主對(duì)象類功能減輕
JDK中體現(xiàn)：未發(fā)現(xiàn)

類圖：

六、參考文獻(xiàn)

1. Design Pattern（GoF）

2. Software Architecture Design Patterns in Java

3. JDK 5 Documentation

4. http://stackoverflow.com/questions/1673841/examples-of-gof-design-patterns

5. http://java.csdn.net/a/20101129/282644.html**

本系列文章將整理到我在GitHub上的《Java面試指南》倉(cāng)庫(kù)，更多精彩內(nèi)容請(qǐng)到我的倉(cāng)庫(kù)里查看

https://github.com/h3pl/Java-Tutorial

喜歡的話麻煩點(diǎn)下Star、fork哈

文章也將發(fā)表在我的個(gè)人博客，閱讀體驗(yàn)更佳：

www.how2playlife.com

結(jié)構(gòu)型模式

前面創(chuàng)建型模式介紹了創(chuàng)建對(duì)象的一些設(shè)計(jì)模式，這節(jié)介紹的結(jié)構(gòu)型模式旨在通過改變代碼結(jié)構(gòu)來達(dá)到解耦的目的，使得我們的代碼容易維護(hù)和擴(kuò)展。

代理模式

第一個(gè)要介紹的代理模式是最常使用的模式之一了，用一個(gè)代理來隱藏具體實(shí)現(xiàn)類的實(shí)現(xiàn)細(xì)節(jié)，通常還用于在真實(shí)的實(shí)現(xiàn)的前后添加一部分邏輯。

既然說是代理，那就要對(duì)客戶端隱藏真實(shí)實(shí)現(xiàn)，由代理來負(fù)責(zé)客戶端的所有請(qǐng)求。當(dāng)然，代理只是個(gè)代理，它不會(huì)完成實(shí)際的業(yè)務(wù)邏輯，而是一層皮而已，但是對(duì)于客戶端來說，它必須表現(xiàn)得就是客戶端需要的真實(shí)實(shí)現(xiàn)。

理解代理這個(gè)詞，這個(gè)模式其實(shí)就簡(jiǎn)單了。

public interface FoodService {
    Food makeChicken();
    Food makeNoodle();
}
public class FoodServiceImpl implements FoodService {
    public Food makeChicken() {
          Food f = new Chicken()
        f.setChicken("1kg");
          f.setSpicy("1g");
          f.setSalt("3g");
        return f;
    }
    public Food makeNoodle() {
        Food f = new Noodle();
        f.setNoodle("500g");
        f.setSalt("5g");
        return f;
    }
}
// 代理要表現(xiàn)得“就像是”真實(shí)實(shí)現(xiàn)類，所以需要實(shí)現(xiàn) FoodService
public class FoodServiceProxy implements FoodService {
    // 內(nèi)部一定要有一個(gè)真實(shí)的實(shí)現(xiàn)類，當(dāng)然也可以通過構(gòu)造方法注入
    private FoodService foodService = new FoodServiceImpl();
    public Food makeChicken() {
        System.out.println("我們馬上要開始制作雞肉了");
        // 如果我們定義這句為核心代碼的話，那么，核心代碼是真實(shí)實(shí)現(xiàn)類做的，
        // 代理只是在核心代碼前后做些“無足輕重”的事情
        Food food = foodService.makeChicken();
        System.out.println("雞肉制作完成啦，加點(diǎn)胡椒粉"); // 增強(qiáng)
          food.addCondiment("pepper");
        return food;
    }
    public Food makeNoodle() {
        System.out.println("準(zhǔn)備制作拉面~");
        Food food = foodService.makeNoodle();
        System.out.println("制作完成啦")
        return food;
    }
}

客戶端調(diào)用，注意，我們要用代理來實(shí)例化接口：

// 這里用代理類來實(shí)例化
FoodService foodService = new FoodServiceProxy();
foodService.makeChicken();

我們發(fā)現(xiàn)沒有，代理模式說白了就是做 “方法包裝” 或做 “方法增強(qiáng)”。在面向切面編程中，算了還是不要吹捧這個(gè)名詞了，在 AOP 中，其實(shí)就是動(dòng)態(tài)代理的過程。比如 Spring 中，我們自己不定義代理類，但是 Spring 會(huì)幫我們動(dòng)態(tài)來定義代理，然后把我們定義在 @Before、 @After、 @Around 中的代碼邏輯動(dòng)態(tài)添加到代理中。

說到動(dòng)態(tài)代理，又可以展開說 …… Spring 中實(shí)現(xiàn)動(dòng)態(tài)代理有兩種，一種是如果我們的類定義了接口，如 UserService 接口和 UserServiceImpl 實(shí)現(xiàn)，那么采用 JDK 的動(dòng)態(tài)代理，感興趣的讀者可以去看看 java.lang.reflect.Proxy 類的源碼；另一種是我們自己沒有定義接口的，Spring 會(huì)采用 CGLIB 進(jìn)行動(dòng)態(tài)代理，它是一個(gè) jar 包，性能還不錯(cuò)。

適配器模式

說完代理模式，說適配器模式，是因?yàn)樗鼈兒芟嗨疲@里可以做個(gè)比較。

適配器模式做的就是，有一個(gè)接口需要實(shí)現(xiàn)，但是我們現(xiàn)成的對(duì)象都不滿足，需要加一層適配器來進(jìn)行適配。

適配器模式總體來說分三種：默認(rèn)適配器模式、對(duì)象適配器模式、類適配器模式。先不急著分清楚這幾個(gè)，先看看例子再說。

默認(rèn)適配器模式

首先，我們先看看最簡(jiǎn)單的適配器模式默認(rèn)適配器模式(Default Adapter)是怎么樣的。

我們用 Appache commons-io 包中的 FileAlterationListener 做例子，此接口定義了很多的方法，用于對(duì)文件或文件夾進(jìn)行監(jiān)控，一旦發(fā)生了對(duì)應(yīng)的操作，就會(huì)觸發(fā)相應(yīng)的方法。

public interface FileAlterationListener {
    void onStart(final FileAlterationObserver observer);
    void onDirectoryCreate(final File directory);
    void onDirectoryChange(final File directory);
    void onDirectoryDelete(final File directory);
    void onFileCreate(final File file);
    void onFileChange(final File file);
    void onFileDelete(final File file);
    void onStop(final FileAlterationObserver observer);
}

此接口的一大問題是抽象方法太多了，如果我們要用這個(gè)接口，意味著我們要實(shí)現(xiàn)每一個(gè)抽象方法，如果我們只是想要監(jiān)控文件夾中的文件創(chuàng)建和文件刪除事件，可是我們還是不得不實(shí)現(xiàn)所有的方法，很明顯，這不是我們想要的。

所以，我們需要下面的一個(gè)適配器，它用于實(shí)現(xiàn)上面的接口，但是所有的方法都是空方法，這樣，我們就可以轉(zhuǎn)而定義自己的類來繼承下面這個(gè)類即可。

public class FileAlterationListenerAdaptor implements FileAlterationListener {
    public void onStart(final FileAlterationObserver observer) {
    }
    public void onDirectoryCreate(final File directory) {
    }
    public void onDirectoryChange(final File directory) {
    }
    public void onDirectoryDelete(final File directory) {
    }
    public void onFileCreate(final File file) {
    }
    public void onFileChange(final File file) {
    }
    public void onFileDelete(final File file) {
    }
    public void onStop(final FileAlterationObserver observer) {
    }
}

比如我們可以定義以下類，我們僅僅需要實(shí)現(xiàn)我們想實(shí)現(xiàn)的方法就可以了：

public class FileMonitor extends FileAlterationListenerAdaptor {
    public void onFileCreate(final File file) {
        // 文件創(chuàng)建
        doSomething();
    }
    public void onFileDelete(final File file) {
        // 文件刪除
        doSomething();
    }
}

當(dāng)然，上面說的只是適配器模式的其中一種，也是最簡(jiǎn)單的一種，無需多言。下面，再介紹“正統(tǒng)的”適配器模式。

對(duì)象適配器模式

來看一個(gè)《Head First 設(shè)計(jì)模式》中的一個(gè)例子，我稍微修改了一下，看看怎么將雞適配成鴨，這樣雞也能當(dāng)鴨來用。因?yàn)椋F(xiàn)在鴨這個(gè)接口，我們沒有合適的實(shí)現(xiàn)類可以用，所以需要適配器。

public interface Duck {
    public void quack(); // 鴨的呱呱叫
      public void fly(); // 飛
}
public interface Cock {
    public void gobble(); // 雞的咕咕叫
      public void fly(); // 飛
}
public class WildCock implements Cock {
    public void gobble() {
        System.out.println("咕咕叫");
    }
      public void fly() {
        System.out.println("雞也會(huì)飛哦");
    }
}

鴨接口有 fly() 和 quare() 兩個(gè)方法，雞 Cock 如果要冒充鴨，fly() 方法是現(xiàn)成的，但是雞不會(huì)鴨的呱呱叫，沒有 quack() 方法。這個(gè)時(shí)候就需要適配了：

// 毫無疑問，首先，這個(gè)適配器肯定需要 implements Duck，這樣才能當(dāng)做鴨來用
public class CockAdapter implements Duck {
    Cock cock;
    // 構(gòu)造方法中需要一個(gè)雞的實(shí)例，此類就是將這只雞適配成鴨來用
      public CockAdapter(Cock cock) {
        this.cock = cock;
    }
    // 實(shí)現(xiàn)鴨的呱呱叫方法
      @Override
      public void quack() {
        // 內(nèi)部其實(shí)是一只雞的咕咕叫
        cock.gobble();
    }
      @Override
      public void fly() {
        cock.fly();
    }
}

客戶端調(diào)用很簡(jiǎn)單了：

public static void main(String[] args) {
    // 有一只野雞
      Cock wildCock = new WildCock();
      // 成功將野雞適配成鴨
      Duck duck = new CockAdapter(wildCock);
      ...
}

到這里，大家也就知道了適配器模式是怎么回事了。無非是我們需要一只鴨，但是我們只有一只雞，這個(gè)時(shí)候就需要定義一個(gè)適配器，由這個(gè)適配器來充當(dāng)鴨，但是適配器里面的方法還是由雞來實(shí)現(xiàn)的。

我們用一個(gè)圖來簡(jiǎn)單說明下：

上圖應(yīng)該還是很容易理解的，我就不做更多的解釋了。下面，我們看看類適配模式怎么樣的。

類適配器模式

廢話少說，直接上圖：

看到這個(gè)圖，大家應(yīng)該很容易理解的吧，通過繼承的方法，適配器自動(dòng)獲得了所需要的大部分方法。這個(gè)時(shí)候，客戶端使用更加簡(jiǎn)單，直接 Target t = new SomeAdapter(); 就可以了。

適配器模式總結(jié)

1. 類適配和對(duì)象適配的異同

   一個(gè)采用繼承，一個(gè)采用組合；

   類適配屬于靜態(tài)實(shí)現(xiàn)，對(duì)象適配屬于組合的動(dòng)態(tài)實(shí)現(xiàn)，對(duì)象適配需要多實(shí)例化一個(gè)對(duì)象。

   總體來說，對(duì)象適配用得比較多。

2. 適配器模式和代理模式的異同

   比較這兩種模式，其實(shí)是比較對(duì)象適配器模式和代理模式，在代碼結(jié)構(gòu)上，它們很相似，都需要一個(gè)具體的實(shí)現(xiàn)類的實(shí)例。但是它們的目的不一樣，代理模式做的是增強(qiáng)原方法的活；適配器做的是適配的活，為的是提供“把雞包裝成鴨，然后當(dāng)做鴨來使用”，而雞和鴨它們之間原本沒有繼承關(guān)系。

橋梁模式

理解橋梁模式，其實(shí)就是理解代碼抽象和解耦。

我們首先需要一個(gè)橋梁，它是一個(gè)接口，定義提供的接口方法。

public interface DrawAPI {
   public void draw(int radius, int x, int y);
}

然后是一系列實(shí)現(xiàn)類：

public class RedPen implements DrawAPI {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用紅色筆畫圖，radius:" + radius + ", x:" + x + ", y:" + y);
   }
}
public class GreenPen implements DrawAPI {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用綠色筆畫圖，radius:" + radius + ", x:" + x + ", y:" + y);
   }
}
public class BluePen implements DrawAPI {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用藍(lán)色筆畫圖，radius:" + radius + ", x:" + x + ", y:" + y);
   }
}

定義一個(gè)抽象類，此類的實(shí)現(xiàn)類都需要使用 DrawAPI：

public abstract class Shape {
   protected DrawAPI drawAPI;
   protected Shape(DrawAPI drawAPI){
      this.drawAPI = drawAPI;
   }
   public abstract void draw();    
}

定義抽象類的子類：

// 圓形
public class Circle extends Shape {
   private int radius;
   public Circle(int radius, DrawAPI drawAPI) {
      super(drawAPI);
      this.radius = radius;
   }
   public void draw() {
      drawAPI.draw(radius, 0, 0);
   }
}
// 長(zhǎng)方形
public class Rectangle extends Shape {
    private int x;
      private int y;
      public Rectangle(int x, int y, DrawAPI drawAPI) {
        super(drawAPI);
          this.x = x;
          this.y = y;
    }
      public void draw() {
      drawAPI.draw(0, x, y);
   }
}

最后，我們來看客戶端演示：

public static void main(String[] args) {
    Shape greenCircle = new Circle(10, new GreenPen());
      Shape redRectangle = new Rectangle(4, 8, new RedPen());
      greenCircle.draw();
      redRectangle.draw();
}

可能大家看上面一步步還不是特別清晰，我把所有的東西整合到一張圖上：

這回大家應(yīng)該就知道抽象在哪里，怎么解耦了吧。橋梁模式的優(yōu)點(diǎn)也是顯而易見的，就是非常容易進(jìn)行擴(kuò)展。

本節(jié)引用了 這里的例子，并對(duì)其進(jìn)行了修改。

裝飾模式

要把裝飾模式說清楚明白，不是件容易的事情。也許讀者知道 Java IO 中的幾個(gè)類是典型的裝飾模式的應(yīng)用，但是讀者不一定清楚其中的關(guān)系，也許看完就忘了，希望看完這節(jié)后，讀者可以對(duì)其有更深的感悟。

首先，我們先看一個(gè)簡(jiǎn)單的圖，看這個(gè)圖的時(shí)候，了解下層次結(jié)構(gòu)就可以了：

我們來說說裝飾模式的出發(fā)點(diǎn)，從圖中可以看到，接口 Component 其實(shí)已經(jīng)有了 ConcreteComponentA 和 ConcreteComponentB 兩個(gè)實(shí)現(xiàn)類了，但是，如果我們要增強(qiáng)這兩個(gè)實(shí)現(xiàn)類的話，我們就可以采用裝飾模式，用具體的裝飾器來裝飾實(shí)現(xiàn)類，以達(dá)到增強(qiáng)的目的。

從名字來簡(jiǎn)單解釋下裝飾器。既然說是裝飾，那么往往就是添加小功能這種，而且，我們要滿足可以添加多個(gè)小功能。最簡(jiǎn)單的，代理模式就可以實(shí)現(xiàn)功能的增強(qiáng)，但是代理不容易實(shí)現(xiàn)多個(gè)功能的增強(qiáng)，當(dāng)然你可以說用代理包裝代理的方式，但是那樣的話代碼就復(fù)雜了。

首先明白一些簡(jiǎn)單的概念，從圖中我們看到，所有的具體裝飾者們 ConcreteDecorator 都可以作為 Component 來使用，因?yàn)樗鼈兌紝?shí)現(xiàn)了 Component 中的所有接口。它們和 Component 實(shí)現(xiàn)類 ConcreteComponent 的區(qū)別是，它們只是裝飾者，起裝飾作用，也就是即使它們看上去牛逼轟轟，但是它們都只是在具體的實(shí)現(xiàn)中加了層皮來裝飾而已。

注意這段話中混雜在各個(gè)名詞中的 Component 和 Decorator，別搞混了。

下面來看看一個(gè)例子，先把裝飾模式弄清楚，然后再介紹下 java io 中的裝飾模式的應(yīng)用。

最近大街上流行起來了“快樂檸檬”，我們把快樂檸檬的飲料分為三類：紅茶、綠茶、咖啡，在這三大類的基礎(chǔ)上，又增加了許多的口味，什么金桔檸檬紅茶、金桔檸檬珍珠綠茶、芒果紅茶、芒果綠茶、芒果珍珠紅茶、烤珍珠紅茶、烤珍珠芒果綠茶、椰香胚芽咖啡、焦糖可可咖啡等等，每家店都有很長(zhǎng)的菜單，但是仔細(xì)看下，其實(shí)原料也沒幾樣，但是可以搭配出很多組合，如果顧客需要，很多沒出現(xiàn)在菜單中的飲料他們也是可以做的。

在這個(gè)例子中，紅茶、綠茶、咖啡是最基礎(chǔ)的飲料，其他的像金桔檸檬、芒果、珍珠、椰果、焦糖等都屬于裝飾用的。當(dāng)然，在開發(fā)中，我們確實(shí)可以像門店一樣，開發(fā)這些類：LemonBlackTea、LemonGreenTea、MangoBlackTea、MangoLemonGreenTea……但是，很快我們就發(fā)現(xiàn)，這樣子干肯定是不行的，這會(huì)導(dǎo)致我們需要組合出所有的可能，而且如果客人需要在紅茶中加雙份檸檬怎么辦？三份檸檬怎么辦？萬一有個(gè)變態(tài)要四份檸檬，所以這種做法是給自己找加班的。

不說廢話了，上代碼。

首先，定義飲料抽象基類：

public abstract class Beverage {
      // 返回描述
      public abstract String getDescription();
      // 返回價(jià)格
      public abstract double cost();
}

然后是三個(gè)基礎(chǔ)飲料實(shí)現(xiàn)類，紅茶、綠茶和咖啡：

public class BlackTea extends Beverage {
      public String getDescription() {
        return "紅茶";
    }
      public double cost() {
        return 10;
    }
}
public class GreenTea extends Beverage {
    public String getDescription() {
        return "綠茶";
    }
      public double cost() {
        return 11;
    }
}
...// 咖啡省略

定義調(diào)料，也就是裝飾者的基類，此類必須繼承自 Beverage：

// 調(diào)料
public abstract class Condiment extends Beverage {
}

然后我們來定義檸檬、芒果等具體的調(diào)料，它們屬于裝飾者，毫無疑問，這些調(diào)料肯定都需要繼承 Condiment 類：

public class Lemon extends Condiment {
    private Beverage bevarage;
      // 這里很關(guān)鍵，需要傳入具體的飲料，如需要傳入沒有被裝飾的紅茶或綠茶，
      // 當(dāng)然也可以傳入已經(jīng)裝飾好的芒果綠茶，這樣可以做芒果檸檬綠茶
      public Lemon(Beverage bevarage) {
        this.bevarage = bevarage;
    }
      public String getDescription() {
        // 裝飾
        return bevarage.getDescription() + ", 加檸檬";
    }
      public double cost() {
          // 裝飾
        return beverage.cost() + 2; // 加檸檬需要 2 元
    }
}
public class Mango extends Condiment {
    private Beverage bevarage;
      public Mango(Beverage bevarage) {
        this.bevarage = bevarage;
    }
      public String getDescription() {
        return bevarage.getDescription() + ", 加芒果";
    }
      public double cost() {
        return beverage.cost() + 3; // 加芒果需要 3 元
    }
}
...// 給每一種調(diào)料都加一個(gè)類

看客戶端調(diào)用：

public static void main(String[] args) {
      // 首先，我們需要一個(gè)基礎(chǔ)飲料，紅茶、綠茶或咖啡
    Beverage beverage = new GreenTea();
      // 開始裝飾
      beverage = new Lemon(beverage); // 先加一份檸檬
      beverage = new Mongo(beverage); // 再加一份芒果
      System.out.println(beverage.getDescription() + " 價(jià)格：￥" + beverage.cost());
      //"綠茶, 加檸檬, 加芒果 價(jià)格：￥16"
}

如果我們需要芒果珍珠雙份檸檬紅茶：

Beverage beverage = new Mongo(new Pearl(new Lemon(new Lemon(new BlackTea()))));

是不是很變態(tài)？

看看下圖可能會(huì)清晰一些：

到這里，大家應(yīng)該已經(jīng)清楚裝飾模式了吧。

下面，我們?cè)賮碚f說 java IO 中的裝飾模式?？聪聢D InputStream 派生出來的部分類：

我們知道 InputStream 代表了輸入流，具體的輸入來源可以是文件（FileInputStream）、管道（PipedInputStream）、數(shù)組（ByteArrayInputStream）等，這些就像前面奶茶的例子中的紅茶、綠茶，屬于基礎(chǔ)輸入流。

FilterInputStream 承接了裝飾模式的關(guān)鍵節(jié)點(diǎn)，其實(shí)現(xiàn)類是一系列裝飾器，比如 BufferedInputStream 代表用緩沖來裝飾，也就使得輸入流具有了緩沖的功能，LineNumberInputStream 代表用行號(hào)來裝飾，在操作的時(shí)候就可以取得行號(hào)了，DataInputStream 的裝飾，使得我們可以從輸入流轉(zhuǎn)換為 java 中的基本類型值。

當(dāng)然，在 java IO 中，如果我們使用裝飾器的話，就不太適合面向接口編程了，如：

InputStream inputStream = new LineNumberInputStream(new BufferedInputStream(new FileInputStream("")));

這樣的結(jié)果是，InputStream 還是不具有讀取行號(hào)的功能，因?yàn)樽x取行號(hào)的方法定義在 LineNumberInputStream 類中。

我們應(yīng)該像下面這樣使用：

DataInputStream is = new DataInputStream(
                              new BufferedInputStream(
                                  new FileInputStream("")));

所以說嘛，要找到純的嚴(yán)格符合設(shè)計(jì)模式的代碼還是比較難的。

門面模式

門面模式（也叫外觀模式，F(xiàn)acade Pattern）在許多源碼中有使用，比如 slf4j 就可以理解為是門面模式的應(yīng)用。這是一個(gè)簡(jiǎn)單的設(shè)計(jì)模式，我們直接上代碼再說吧。

首先，我們定義一個(gè)接口：

public interface Shape {
   void draw();
}

定義幾個(gè)實(shí)現(xiàn)類：

public class Circle implements Shape {
   @Override
   public void draw() {
      System.out.println("Circle::draw()");
   }
}
public class Rectangle implements Shape {
   @Override
   public void draw() {
      System.out.println("Rectangle::draw()");
   }
}

客戶端調(diào)用：

public static void main(String[] args) {
    // 畫一個(gè)圓形
      Shape circle = new Circle();
      circle.draw();
      // 畫一個(gè)長(zhǎng)方形
      Shape rectangle = new Rectangle();
      rectangle.draw();
}

以上是我們常寫的代碼，我們需要畫圓就要先實(shí)例化圓，畫長(zhǎng)方形就需要先實(shí)例化一個(gè)長(zhǎng)方形，然后再調(diào)用相應(yīng)的 draw() 方法。

下面，我們看看怎么用門面模式來讓客戶端調(diào)用更加友好一些。

我們先定義一個(gè)門面：

public class ShapeMaker {
   private Shape circle;
   private Shape rectangle;
   private Shape square;
   public ShapeMaker() {
      circle = new Circle();
      rectangle = new Rectangle();
      square = new Square();
   }
  /**
   * 下面定義一堆方法，具體應(yīng)該調(diào)用什么方法，由這個(gè)門面來決定
   */
   public void drawCircle(){
      circle.draw();
   }
   public void drawRectangle(){
      rectangle.draw();
   }
   public void drawSquare(){
      square.draw();
   }
}

看看現(xiàn)在客戶端怎么調(diào)用：

public static void main(String[] args) {
  ShapeMaker shapeMaker = new ShapeMaker();
  // 客戶端調(diào)用現(xiàn)在更加清晰了
  shapeMaker.drawCircle();
  shapeMaker.drawRectangle();
  shapeMaker.drawSquare();        
}

門面模式的優(yōu)點(diǎn)顯而易見，客戶端不再需要關(guān)注實(shí)例化時(shí)應(yīng)該使用哪個(gè)實(shí)現(xiàn)類，直接調(diào)用門面提供的方法就可以了，因?yàn)殚T面類提供的方法的方法名對(duì)于客戶端來說已經(jīng)很友好了。

組合模式

組合模式用于表示具有層次結(jié)構(gòu)的數(shù)據(jù)，使得我們對(duì)單個(gè)對(duì)象和組合對(duì)象的訪問具有一致性。

直接看一個(gè)例子吧，每個(gè)員工都有姓名、部門、薪水這些屬性，同時(shí)還有下屬員工集合（雖然可能集合為空），而下屬員工和自己的結(jié)構(gòu)是一樣的，也有姓名、部門這些屬性，同時(shí)也有他們的下屬員工集合。

public class Employee {
   private String name;
   private String dept;
   private int salary;
   private List<Employee> subordinates; // 下屬
   public Employee(String name,String dept, int sal) {
      this.name = name;
      this.dept = dept;
      this.salary = sal;
      subordinates = new ArrayList<Employee>();
   }
   public void add(Employee e) {
      subordinates.add(e);
   }
   public void remove(Employee e) {
      subordinates.remove(e);
   }
   public List<Employee> getSubordinates(){
     return subordinates;
   }
   public String toString(){
      return ("Employee :[ Name : " + name + ", dept : " + dept + ", salary :" + salary+" ]");
   }   
}

通常，這種類需要定義 add(node)、remove(node)、getChildren() 這些方法。

這說的其實(shí)就是組合模式，這種簡(jiǎn)單的模式我就不做過多介紹了，相信各位讀者也不喜歡看我寫廢話。

享元模式

英文是 Flyweight Pattern，不知道是誰(shuí)最先翻譯的這個(gè)詞，感覺這翻譯真的不好理解，我們?cè)囍鴱?qiáng)行關(guān)聯(lián)起來吧。Flyweight 是輕量級(jí)的意思，享元分開來說就是 共享 元器件，也就是復(fù)用已經(jīng)生成的對(duì)象，這種做法當(dāng)然也就是輕量級(jí)的了。

復(fù)用對(duì)象最簡(jiǎn)單的方式是，用一個(gè) HashMap 來存放每次新生成的對(duì)象。每次需要一個(gè)對(duì)象的時(shí)候，先到 HashMap 中看看有沒有，如果沒有，再生成新的對(duì)象，然后將這個(gè)對(duì)象放入 HashMap 中。

這種簡(jiǎn)單的代碼我就不演示了。

感謝各位的閱讀，以上就是“JDK中的設(shè)計(jì)模式簡(jiǎn)介”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)JDK中的設(shè)計(jì)模式簡(jiǎn)介這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！