Java 設計模式

轉自https://javadoop.com/post/design-pattern

系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裡檢視

> https://github.com/h2pl/Java-Tutorial

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

文章也將發表在我的個人部落格，閱讀體驗更佳：

> www.how2playlife.com

本文是微信公眾號【Java技術江湖】的《夯實Java基礎系列博文》其中一篇，本文部分內容來源於網路，為了把本文主題講得清晰透徹，也整合了很多我認為不錯的技術部落格內容，引用其中了一些比較好的部落格文章，如有侵權，請聯絡作者。
該系列博文會告訴你如何從入門到進階，一步步地學習Java基礎知識，並上手進行實戰，接著瞭解每個Java知識點背後的實現原理，更完整地瞭解整個Java技術體系，形成自己的知識框架。為了更好地總結和檢驗你的學習成果，本系列文章也會提供每個知識點對應的面試題以及參考答案。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯絡作者，歡迎你參與本系列博文的創作和修訂

一直想寫一篇介紹設計模式的文章，讓讀者可以很快看完，而且一看就懂，看懂就會用，同時不會將各個模式搞混。自認為本文還是寫得不錯的，花了不少心思來寫這文章和做圖，力求讓讀者真的能看著簡單同時有所收穫。

設計模式是對大家實際工作中寫的各種程式碼進行高層次抽象的總結，其中最出名的當屬 _Gang of Four_ (_GoF_) 的分類了，他們將設計模式分類為 23 種經典的模式，根據用途我們又可以分為三大類，分別為建立型模式、結構型模式和行為型模式。是的，我不善於扯這些有的沒的，還是少點廢話吧~~~

有一些重要的設計原則在開篇和大家分享下，這些原則將貫通全文：

1.  面向介面程式設計，而不是面向實現。這個很重要，也是優雅的、可擴充套件的程式碼的第一步，這就不需要多說了吧。
2.  職責單一原則。每個類都應該只有一個單一的功能，並且該功能應該由這個類完全封裝起來。
3.  對修改關閉，對擴充套件開放。對修改關閉是說，我們辛辛苦苦加班寫出來的程式碼，該實現的功能和該修復的 bug 都完成了，別人可不能說改就改；對擴充套件開放就比較好理解了，也就是說在我們寫好的程式碼基礎上，很容易實現擴充套件。

**目錄**

*   [建立型模式](https://javadoop.com/post/design-pattern#%E5%88%9B%E5%BB%BA%E5%9E%8B%E6%A8%A1%E5%BC%8F)
    *   [簡單工廠模式](https://javadoop.com/post/design-pattern#%E7%AE%80%E5%8D%95%E5%B7%A5%E5%8E%82%E6%A8%A1%E5%BC%8F)
    *   [工廠模式](https://javadoop.com/post/design-pattern#%E5%B7%A5%E5%8E%82%E6%A8%A1%E5%BC%8F)
    *   [抽象工廠模式](https://javadoop.com/post/design-pattern#%E6%8A%BD%E8%B1%A1%E5%B7%A5%E5%8E%82%E6%A8%A1%E5%BC%8F)
    *   [單例模式](https://javadoop.com/post/design-pattern#%E5%8D%95%E4%BE%8B%E6%A8%A1%E5%BC%8F)
    *   [建造者模式](https://javadoop.com/post/design-pattern#%E5%BB%BA%E9%80%A0%E8%80%85%E6%A8%A1%E5%BC%8F)
    *   [原型模式](https://javadoop.com/post/design-pattern#%E5%8E%9F%E5%9E%8B%E6%A8%A1%E5%BC%8F)
    *   [建立型模式總結](https://javadoop.com/post/design-pattern#%E5%88%9B%E5%BB%BA%E5%9E%8B%E6%A8%A1%E5%BC%8F%E6%80%BB%E7%BB%93)

## 建立型模式

建立型模式的作用就是建立物件，說到建立一個物件，最熟悉的就是 new 一個物件，然後 set 相關屬性。但是，在很多場景下，我們需要給客戶端提供更加友好的建立物件的方式，尤其是那種我們定義了類，但是需要提供給其他開發者用的時候。

### 簡單工廠模式

和名字一樣簡單，非常簡單，直接上程式碼吧：

```
public class FoodFactory {

public static Food makeFood(String name) {
        if (name.equals("noodle")) {
            Food noodle = new LanZhouNoodle();
            noodle.addSpicy("more");
            return noodle;
        } else if (name.equals("chicken")) {
            Food chicken = new HuangMenChicken();
            chicken.addCondiment("potato");
            return chicken;
        } else {
            return null;
        }
    }
}

```

_其中，LanZhouNoodle 和 HuangMenChicken 都繼承自 Food。_

簡單地說，簡單工廠模式通常就是這樣，一個工廠類 XxxFactory，裡面有一個靜態方法，根據我們不同的引數，返回不同的派生自同一個父類（或實現同一介面）的例項物件。

> 我們強調**職責單一**原則，一個類只提供一種功能，FoodFactory 的功能就是隻要負責生產各種 Food。

### 工廠模式

簡單工廠模式很簡單，如果它能滿足我們的需要，我覺得就不要折騰了。之所以需要引入工廠模式，是因為我們往往需要使用兩個或兩個以上的工廠。

```
public interface FoodFactory {
    Food makeFood(String name);
}
public class ChineseFoodFactory implements FoodFactory {

@Override
    public Food makeFood(String name) {
        if (name.equals("A")) {
            return new ChineseFoodA();
        } else if (name.equals("B")) {
            return new ChineseFoodB();
        } else {
            return null;
        }
    }
}
public class AmericanFoodFactory implements FoodFactory {

@Override
    public Food makeFood(String name) {
        if (name.equals("A")) {
            return new AmericanFoodA();
        } else if (name.equals("B")) {
            return new AmericanFoodB();
        } else {
            return null;
        }
    }
}

```

其中，ChineseFoodA、ChineseFoodB、AmericanFoodA、AmericanFoodB 都派生自 Food。

客戶端呼叫：

```
public class APP {
    public static void main(String[] args) {
        // 先選擇一個具體的工廠
        FoodFactory factory = new ChineseFoodFactory();
        // 由第一步的工廠產生具體的物件，不同的工廠造出不一樣的物件
        Food food = factory.makeFood("A");
    }
}

```

雖然都是呼叫 makeFood("A") 製作 A 類食物，但是，不同的工廠生產出來的完全不一樣。

第一步，我們需要選取合適的工廠，然後第二步基本上和簡單工廠一樣。

**核心在於，我們需要在第一步選好我們需要的工廠**。比如，我們有 LogFactory 介面，實現類有 FileLogFactory 和 KafkaLogFactory，分別對應將日誌寫入檔案和寫入 Kafka 中，顯然，我們客戶端第一步就需要決定到底要例項化 FileLogFactory 還是 KafkaLogFactory，這將決定之後的所有的操作。

雖然簡單，不過我也把所有的構件都畫到一張圖上，這樣讀者看著比較清晰：

![](https://javadoop.com/blogimages/design-pattern/factory-1.png)![](https://csdnimg.cn/release/phoenix/write/assets/uploading.gif)轉存失敗重新上傳取消![factory-1](https://javadoop.com/blogimages/design-pattern/factory-1.png)![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

### 抽象工廠模式

當涉及到**產品族**的時候，就需要引入抽象工廠模式了。

一個經典的例子是造一臺電腦。我們先不引入抽象工廠模式，看看怎麼實現。

因為電腦是由許多的構件組成的，我們將 CPU 和主機板進行抽象，然後 CPU 由 CPUFactory 生產，主機板由 MainBoardFactory 生產，然後，我們再將 CPU 和主機板搭配起來組合在一起，如下圖：

![](https://javadoop.com/blogimages/design-pattern/abstract-factory-1.png)![](https://csdnimg.cn/release/phoenix/write/assets/uploading.gif)轉存失敗重新上傳取消![factory-1](https://javadoop.com/blogimages/design-pattern/abstract-factory-1.png)![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

這個時候的客戶端呼叫是這樣的：

```
// 得到 Intel 的 CPU
CPUFactory cpuFactory = new IntelCPUFactory();
CPU cpu = intelCPUFactory.makeCPU();

// 得到 AMD 的主機板
MainBoardFactory mainBoardFactory = new AmdMainBoardFactory();
MainBoard mainBoard = mainBoardFactory.make();

// 組裝 CPU 和主機板
Computer computer = new Computer(cpu, mainBoard);

```

單獨看 CPU 工廠和主機板工廠，它們分別是前面我們說的**工廠模式**。這種方式也容易擴充套件，因為要給電腦加硬碟的話，只需要加一個 HardDiskFactory 和相應的實現即可，不需要修改現有的工廠。

但是，這種方式有一個問題，那就是如果 **Intel 家產的 CPU 和 AMD 產的主機板不能相容使用**，那麼這程式碼就容易出錯，因為客戶端並不知道它們不相容，也就會錯誤地出現隨意組合。

下面就是我們要說的**產品族**的概念，它代表了組成某個產品的一系列附件的集合：

![](https://javadoop.com/blogimages/design-pattern/abstract-factory-2.png)

![abstract-factory-2](https://javadoop.com/blogimages/design-pattern/abstract-factory-2.png)

當涉及到這種產品族的問題的時候，就需要抽象工廠模式來支援了。我們不再定義 CPU 工廠、主機板工廠、硬碟工廠、螢幕工廠等等，我們直接定義電腦工廠，每個電腦工廠負責生產所有的裝置，這樣能保證肯定不存在相容問題。

![](https://javadoop.com/blogimages/design-pattern/abstract-factory-3.png)

![abstract-factory-3](https://javadoop.com/blogimages/design-pattern/abstract-factory-3.png)

這個時候，對於客戶端來說，不再需要單獨挑選 CPU廠商、主機板廠商、硬碟廠商等，直接選擇一家品牌工廠，品牌工廠會負責生產所有的東西，而且能保證肯定是相容可用的。

```
public static void main(String[] args) {
    // 第一步就要選定一個“大廠”
    ComputerFactory cf = new AmdFactory();
    // 從這個大廠造 CPU
    CPU cpu = cf.makeCPU();
    // 從這個大廠造主機板
    MainBoard board = cf.makeMainBoard();
      // 從這個大廠造硬碟
      HardDisk hardDisk = cf.makeHardDisk();

// 將同一個廠子出來的 CPU、主機板、硬碟組裝在一起
    Computer result = new Computer(cpu, board, hardDisk);
}

```

當然，抽象工廠的問題也是顯而易見的，比如我們要加個顯示器，就需要修改所有的工廠，給所有的工廠都加上製造顯示器的方法。這有點違反了**對修改關閉，對擴充套件開放**這個設計原則。

### 單例模式

單例模式用得最多，錯得最多。

餓漢模式最簡單：

```
public class Singleton {
    // 首先，將 new Singleton() 堵死
    private Singleton() {};
    // 建立私有靜態例項，意味著這個類第一次使用的時候就會進行建立
    private static Singleton instance = new Singleton();

public static Singleton getInstance() {
        return instance;
    }
    // 瞎寫一個靜態方法。這裡想說的是，如果我們只是要呼叫 Singleton.getDate(...)，
    // 本來是不想要生成 Singleton 例項的，不過沒辦法，已經生成了
    public static Date getDate(String mode) {return new Date();}
}

```

> 很多人都能說出餓漢模式的缺點，可是我覺得生產過程中，很少碰到這種情況：你定義了一個單例的類，不需要其例項，可是你卻把一個或幾個你會用到的靜態方法塞到這個類中。

飽漢模式最容易出錯：

```
public class Singleton {
    // 首先，也是先堵死 new Singleton() 這條路
    private Singleton() {}
    // 和餓漢模式相比，這邊不需要先例項化出來，注意這裡的 volatile，它是必須的
    private static volatile Singleton instance = null;

public static Singleton getInstance() {
        if (instance == null) {
            // 加鎖
            synchronized (Singleton.class) {
                // 這一次判斷也是必須的，不然會有併發問題
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

```

> 雙重檢查，指的是兩次檢查 instance 是否為 null。
> 
> volatile 在這裡是需要的，希望能引起讀者的關注。
> 
> 很多人不知道怎麼寫，直接就在 getInstance() 方法簽名上加上 synchronized，這就不多說了，效能太差。

巢狀類最經典，以後大家就用它吧：

```
public class Singleton3 {

private Singleton3() {}
    // 主要是使用了 巢狀類可以訪問外部類的靜態屬性和靜態方法 的特性
    private static class Holder {
        private static Singleton3 instance = new Singleton3();
    }
    public static Singleton3 getInstance() {
        return Holder.instance;
    }
}

```

> 注意，很多人都會把這個**巢狀類**說成是**靜態內部類**，嚴格地說，內部類和巢狀類是不一樣的，它們能訪問的外部類許可權也是不一樣的。

最後，一定有人跳出來說用列舉實現單例，是的沒錯，列舉類很特殊，它在類載入的時候會初始化裡面的所有的例項，而且 JVM 保證了它們不會再被例項化，所以它天生就是單例的。不說了，讀者自己看著辦吧，不建議使用。

### 建造者模式

經常碰見的 XxxBuilder 的類，通常都是建造者模式的產物。建造者模式其實有很多的變種，但是對於客戶端來說，我們的使用通常都是一個模式的：

```
Food food = new FoodBuilder().a().b().c().build();
Food food = Food.builder().a().b().c().build();

```

套路就是先 new 一個 Builder，然後可以鏈式地呼叫一堆方法，最後再呼叫一次 build() 方法，我們需要的物件就有了。

來一箇中規中矩的建造者模式：

```
class User {
    // 下面是“一堆”的屬性
    private String name;
    private String password;
    private String nickName;
    private int age;

// 構造方法私有化，不然客戶端就會直接呼叫構造方法了
    private User(String name, String password, String nickName, int age) {
        this.name = name;
        this.password = password;
        this.nickName = nickName;
        this.age = age;
    }
    // 靜態方法，用於生成一個 Builder，這個不一定要有，不過寫這個方法是一個很好的習慣，
    // 有些程式碼要求別人寫 new User.UserBuilder().a()...build() 看上去就沒那麼好
    public static UserBuilder builder() {
        return new UserBuilder();
    }

public static class UserBuilder {
        // 下面是和 User 一模一樣的一堆屬性
        private String  name;
        private String password;
        private String nickName;
        private int age;

private UserBuilder() {
        }

// 鏈式呼叫設定各個屬性值，返回 this，即 UserBuilder
        public UserBuilder name(String name) {
            this.name = name;
            return this;
        }

public UserBuilder password(String password) {
            this.password = password;
            return this;
        }

public UserBuilder nickName(String nickName) {
            this.nickName = nickName;
            return this;
        }

public UserBuilder age(int age) {
            this.age = age;
            return this;
        }

// build() 方法負責將 UserBuilder 中設定好的屬性“複製”到 User 中。
        // 當然，可以在 “複製” 之前做點檢驗
        public User build() {
            if (name == null || password == null) {
                throw new RuntimeException("使用者名稱和密碼必填");
            }
            if (age <= 0 || age >= 150) {
                throw new RuntimeException("年齡不合法");
            }
            // 還可以做賦予”預設值“的功能
              if (nickName == null) {
                nickName = name;
            }
            return new User(name, password, nickName, age);
        }
    }
}

```

核心是：先把所有的屬性都設定給 Builder，然後 build() 方法的時候，將這些屬性**複製**給實際產生的物件。

看看客戶端的呼叫：

```
public class APP {
    public static void main(String[] args) {
        User d = User.builder()
                .name("foo")
                .password("pAss12345")
                .age(25)
                .build();
    }
}

```

說實話，建造者模式的**鏈式**寫法很吸引人，但是，多寫了很多“無用”的 builder 的程式碼，感覺這個模式沒什麼用。不過，當屬性很多，而且有些必填，有些選填的時候，這個模式會使程式碼清晰很多。我們可以在 **Builder 的構造方法**中強制讓呼叫者提供必填欄位，還有，在 build() 方法中校驗各個引數比在 User 的構造方法中校驗，程式碼要優雅一些。

> 題外話，強烈建議讀者使用 lombok，用了 lombok 以後，上面的一大堆程式碼會變成如下這樣:

```
@Builder
class User {
    private String  name;
    private String password;
    private String nickName;
    private int age;
}

```

> 怎麼樣，省下來的時間是不是又可以乾點別的了。

當然，如果你只是想要鏈式寫法，不想要建造者模式，有個很簡單的辦法，User 的 getter 方法不變，所有的 setter 方法都讓其 **return this** 就可以了，然後就可以像下面這樣呼叫：

```
User user = new User().setName("").setPassword("").setAge(20);

```

### 原型模式

這是我要說的建立型模式的最後一個設計模式了。

原型模式很簡單：有一個原型**例項**，基於這個原型例項產生新的例項，也就是“克隆”了。

Object 類中有一個 clone() 方法，它用於生成一個新的物件，當然，如果我們要呼叫這個方法，java 要求我們的類必須先**實現 Cloneable 介面**，此介面沒有定義任何方法，但是不這麼做的話，在 clone() 的時候，會丟擲 CloneNotSupportedException 異常。

```
protected native Object clone() throws CloneNotSupportedException;

```

> java 的克隆是淺克隆，碰到物件引用的時候，克隆出來的物件和原物件中的引用將指向同一個物件。通常實現深克隆的方法是將物件進行序列化，然後再進行反序列化。

原型模式瞭解到這裡我覺得就夠了，各種變著法子說這種程式碼或那種程式碼是原型模式，沒什麼意義。

### 建立型模式總結

建立型模式總體上比較簡單，它們的作用就是為了產生例項物件，算是各種工作的第一步了，因為我們寫的是**物件導向**的程式碼，所以我們第一步當然是需要建立一個物件了。

簡單工廠模式最簡單；工廠模式在簡單工廠模式的基礎上增加了選擇工廠的維度，需要第一步選擇合適的工廠；抽象工廠模式有產品族的概念，如果各個產品是存在相容性問題的，就要用抽象工廠模式。單例模式就不說了，為了保證全域性使用的是同一物件，一方面是安全性考慮，一方面是為了節省資源；建造者模式專門對付屬性很多的那種類，為了讓程式碼更優美；原型模式用得最少，瞭解和 Object 類中的 clone() 方法相關的知識即可。

## 參考文章

轉自https://javadoop.com/post/design-pattern

初探Java設計模式1：建立型模式（工廠，單例等）

相關文章