JDK中的設計模式簡介

這篇文章主要講解了“JDK中的設計模式簡介”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“JDK中的設計模式簡介”吧！

設計模式是什么

（1）反復出現問題的解決方案
（2）增強軟件的靈活性
（3）適應軟件不斷變化

學習JDK中設計模式的好處

（1）借鑒優秀代碼的設計，有助于提高代碼設計能力
（2）JDK的設計中體現了大多數設計模式，是學習設計模式的較好的方式
（3）可以更加深入的了解JDK

類間關系

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

介紹方式

（1）作用：歸納某設計模式的基本要點
（2）JDK中體現：某設計模式在JDK中是怎樣體現出來的
（3）類圖：某設計模式在JDK中所對應的類圖

經典設計模式在JDK中的體現

1.Singleton（單例）
作用：保證類只有一個實例；提供一個全局訪問點
JDK中體現：
（1）Runtime
（2）NumberFormat
類圖：

靜態工廠

作用：
（1）代替構造函數創建對象
（2）方法名比構造函數清晰
JDK中體現：
（1）Integer.valueOf
（2）Class.forName

類圖：

工廠方法

作用：子類決定哪一個類實例化
JDK中體現：Collection.iterator方法

類圖：

建造者模式

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

類圖：

原型模型

作用：
（1）復制對象
（2）淺復制、深復制
JDK中體現：Object.clone；Cloneable
類圖：

適配器模式

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

類圖：

橋接模式

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

類圖：

組合模式

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

類圖：

裝飾者模式

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

類圖：

外觀模式

作用：
（1）封裝一組交互類，一致地對外提供接口
（2）封裝子系統，簡化子系統調用
JDK中體現：java.util.logging包

類圖：

享元模式

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

類圖：
**

代理模式

作用：
（1）透明調用被代理對象，無須知道復雜實現細節
（2）增加被代理類的功能
JDK中體現：動態代理；RMI

類圖：
**

迭代器模式

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

類圖：

觀察者模式

作用：通知對象狀態改變
JDK中體現：
（1）java.util.Observer,Observable
（2）Swing中的Listener

類圖：
**

模板方法模式

作用：定義算法的結構，子類只實現不同的部分
JDK中體現：ThreadPoolExecutor.Worker

類圖：

策略模式

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

類圖：

責任鏈模式

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

類圖：

命令模式

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

類圖：

狀態模式

作用：將主對象和其狀態分離，狀態對象負責主對象的狀態轉換，使主對象類功能減輕
JDK中體現：未發現

類圖：

六、參考文獻

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面試指南》倉庫，更多精彩內容請到我的倉庫里查看

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

喜歡的話麻煩點下Star、fork哈

文章也將發表在我的個人博客，閱讀體驗更佳：

www.how2playlife.com

結構型模式

前面創建型模式介紹了創建對象的一些設計模式，這節介紹的結構型模式旨在通過改變代碼結構來達到解耦的目的，使得我們的代碼容易維護和擴展。

代理模式

第一個要介紹的代理模式是最常使用的模式之一了，用一個代理來隱藏具體實現類的實現細節，通常還用于在真實的實現的前后添加一部分邏輯。

既然說是代理，那就要對客戶端隱藏真實實現，由代理來負責客戶端的所有請求。當然，代理只是個代理，它不會完成實際的業務邏輯，而是一層皮而已，但是對于客戶端來說，它必須表現得就是客戶端需要的真實實現。

理解代理這個詞，這個模式其實就簡單了。

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;
    }
}
// 代理要表現得“就像是”真實實現類，所以需要實現 FoodService
public class FoodServiceProxy implements FoodService {
    // 內部一定要有一個真實的實現類，當然也可以通過構造方法注入
    private FoodService foodService = new FoodServiceImpl();
    public Food makeChicken() {
        System.out.println("我們馬上要開始制作雞肉了");
        // 如果我們定義這句為核心代碼的話，那么，核心代碼是真實實現類做的，
        // 代理只是在核心代碼前后做些“無足輕重”的事情
        Food food = foodService.makeChicken();
        System.out.println("雞肉制作完成啦，加點胡椒粉"); // 增強
          food.addCondiment("pepper");
        return food;
    }
    public Food makeNoodle() {
        System.out.println("準備制作拉面~");
        Food food = foodService.makeNoodle();
        System.out.println("制作完成啦")
        return food;
    }
}

客戶端調用，注意，我們要用代理來實例化接口：

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

我們發現沒有，代理模式說白了就是做 “方法包裝” 或做 “方法增強”。在面向切面編程中，算了還是不要吹捧這個名詞了，在 AOP 中，其實就是動態代理的過程。比如 Spring 中，我們自己不定義代理類，但是 Spring 會幫我們動態來定義代理，然后把我們定義在 @Before、 @After、 @Around 中的代碼邏輯動態添加到代理中。

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

適配器模式

說完代理模式，說適配器模式，是因為它們很相似，這里可以做個比較。

適配器模式做的就是，有一個接口需要實現，但是我們現成的對象都不滿足，需要加一層適配器來進行適配。

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

默認適配器模式

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

我們用 Appache commons-io 包中的 FileAlterationListener 做例子，此接口定義了很多的方法，用于對文件或文件夾進行監控，一旦發生了對應的操作，就會觸發相應的方法。

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

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

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

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) {
    }
}

比如我們可以定義以下類，我們僅僅需要實現我們想實現的方法就可以了：

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

當然，上面說的只是適配器模式的其中一種，也是最簡單的一種，無需多言。下面，再介紹“正統的”適配器模式。

對象適配器模式

來看一個《Head First 設計模式》中的一個例子，我稍微修改了一下，看看怎么將雞適配成鴨，這樣雞也能當鴨來用。因為，現在鴨這個接口，我們沒有合適的實現類可以用，所以需要適配器。

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("雞也會飛哦");
    }
}

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

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

客戶端調用很簡單了：

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

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

我們用一個圖來簡單說明下：

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

類適配器模式

廢話少說，直接上圖：

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

適配器模式總結

1. 類適配和對象適配的異同

   一個采用繼承，一個采用組合；

   類適配屬于靜態實現，對象適配屬于組合的動態實現，對象適配需要多實例化一個對象。

   總體來說，對象適配用得比較多。

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

   比較這兩種模式，其實是比較對象適配器模式和代理模式，在代碼結構上，它們很相似，都需要一個具體的實現類的實例。但是它們的目的不一樣，代理模式做的是增強原方法的活；適配器做的是適配的活，為的是提供“把雞包裝成鴨，然后當做鴨來使用”，而雞和鴨它們之間原本沒有繼承關系。

橋梁模式

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

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

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

然后是一系列實現類：

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("用藍色筆畫圖，radius:" + radius + ", x:" + x + ", y:" + y);
   }
}

定義一個抽象類，此類的實現類都需要使用 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);
   }
}
// 長方形
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();
}

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

這回大家應該就知道抽象在哪里，怎么解耦了吧。橋梁模式的優點也是顯而易見的，就是非常容易進行擴展。

本節引用了 這里的例子，并對其進行了修改。

裝飾模式

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

首先，我們先看一個簡單的圖，看這個圖的時候，了解下層次結構就可以了：

我們來說說裝飾模式的出發點，從圖中可以看到，接口 Component 其實已經有了 ConcreteComponentA 和 ConcreteComponentB 兩個實現類了，但是，如果我們要增強這兩個實現類的話，我們就可以采用裝飾模式，用具體的裝飾器來裝飾實現類，以達到增強的目的。

從名字來簡單解釋下裝飾器。既然說是裝飾，那么往往就是添加小功能這種，而且，我們要滿足可以添加多個小功能。最簡單的，代理模式就可以實現功能的增強，但是代理不容易實現多個功能的增強，當然你可以說用代理包裝代理的方式，但是那樣的話代碼就復雜了。

首先明白一些簡單的概念，從圖中我們看到，所有的具體裝飾者們 ConcreteDecorator 都可以作為 Component 來使用，因為它們都實現了 Component 中的所有接口。它們和 Component 實現類 ConcreteComponent 的區別是，它們只是裝飾者，起裝飾作用，也就是即使它們看上去牛逼轟轟，但是它們都只是在具體的實現中加了層皮來裝飾而已。

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

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

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

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

不說廢話了，上代碼。

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

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

然后是三個基礎飲料實現類，紅茶、綠茶和咖啡：

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;
    }
}
...// 咖啡省略

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

// 調料
public abstract class Condiment extends Beverage {
}

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

public class Lemon extends Condiment {
    private Beverage bevarage;
      // 這里很關鍵，需要傳入具體的飲料，如需要傳入沒有被裝飾的紅茶或綠茶，
      // 當然也可以傳入已經裝飾好的芒果綠茶，這樣可以做芒果檸檬綠茶
      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 元
    }
}
...// 給每一種調料都加一個類

看客戶端調用：

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

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

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

是不是很變態？

看看下圖可能會清晰一些：

到這里，大家應該已經清楚裝飾模式了吧。

下面，我們再來說說 java IO 中的裝飾模式。看下圖 InputStream 派生出來的部分類：

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

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

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

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

這樣的結果是，InputStream 還是不具有讀取行號的功能，因為讀取行號的方法定義在 LineNumberInputStream 類中。

我們應該像下面這樣使用：

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

所以說嘛，要找到純的嚴格符合設計模式的代碼還是比較難的。

門面模式

門面模式（也叫外觀模式，Facade Pattern）在許多源碼中有使用，比如 slf4j 就可以理解為是門面模式的應用。這是一個簡單的設計模式，我們直接上代碼再說吧。

首先，我們定義一個接口：

public interface Shape {
   void draw();
}

定義幾個實現類：

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

客戶端調用：

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

以上是我們常寫的代碼，我們需要畫圓就要先實例化圓，畫長方形就需要先實例化一個長方形，然后再調用相應的 draw() 方法。

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

我們先定義一個門面：

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

看看現在客戶端怎么調用：

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

門面模式的優點顯而易見，客戶端不再需要關注實例化時應該使用哪個實現類，直接調用門面提供的方法就可以了，因為門面類提供的方法的方法名對于客戶端來說已經很友好了。

組合模式

組合模式用于表示具有層次結構的數據，使得我們對單個對象和組合對象的訪問具有一致性。

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

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() 這些方法。

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

享元模式

英文是 Flyweight Pattern，不知道是誰最先翻譯的這個詞，感覺這翻譯真的不好理解，我們試著強行關聯起來吧。Flyweight 是輕量級的意思，享元分開來說就是 共享 元器件，也就是復用已經生成的對象，這種做法當然也就是輕量級的了。

復用對象最簡單的方式是，用一個 HashMap 來存放每次新生成的對象。每次需要一個對象的時候，先到 HashMap 中看看有沒有，如果沒有，再生成新的對象，然后將這個對象放入 HashMap 中。

這種簡單的代碼我就不演示了。

感謝各位的閱讀，以上就是“JDK中的設計模式簡介”的內容了，經過本文的學習后，相信大家對JDK中的設計模式簡介這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！