設計模式也可以這麼簡單（7年開發老鳥PS註釋總結）

設計模式是對大家實際工作中寫的各種程式碼進行高層次抽象的總結，其中最出名的當屬 Gang of Four (GoF) 的分類了，他們將設計模式分類為 23 種經典的模式，根據用途我們又可以分為三大類，分別為建立型模式、結構型模式和行為型模式。

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

1. 面向介面程式設計，而不是面向實現。這個很重要，也是優雅的、可擴充套件的程式碼的第一步，這就不需要多說了吧。

2. 職責單一原則。每個類都應該只有一個單一的功能，並且該功能應該由這個類完全封裝起來。

3. 對修改關閉，對擴充套件開放。對修改關閉是說，我們辛辛苦苦加班寫出來的程式碼，該實現的功能和該修復的 bug 都完成了，別人可不能說改就改；對擴充套件開放就比較好理解了，也就是說在我們寫好的程式碼基礎上，很容易實現擴充套件。

建立型模式比較簡單，但是會比較沒有意思，結構型和行為型比較有意思。

 

建立型模式

建立型模式的作用就是建立物件，說到建立一個物件，最熟悉的就是 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。

PS：個人讀文理解

簡單工廠模式是對產品進行抽象。

 

工廠模式

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

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，這將決定之後的所有的操作。

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

PS：個人讀文理解  

這裡不同工廠生產各自的產品，也體現了單一職責的原則，做到了不同產品之間的隔離，達到了解耦的目的。這也是設計模式的一大目的將不相關的內容隔離，不要耦合到一塊。

工廠模式相當於對對工廠進行抽象。

通過這兩個模式有沒有發現一個設計模式的特點，找到程式碼中的變化點和不變點，將不變的點抽象為父類、介面、抽象類，將變化點利用單一職責原則建立各自的子類。

不同的設計模式本質上是將這些變化點不變點進行優雅的組合，來解決不同場景的問題。

 

接下來我們看看不同設計模式是如何組織變化點和不變點的。

抽象工廠模式

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

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

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

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

// 得到 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 產的主機板不能相容使用，那麼這程式碼就容易出錯，因為客戶端並不知道它們不相容，也就會錯誤地出現隨意組合。

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

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

這個時候，對於客戶端來說，不再需要單獨挑選 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 保證了它們不會再被例項化，所以它天生就是單例的。

雖然我們平時很少看到用列舉來實現單例，但是在 RxJava 的原始碼中，有很多地方都用了列舉來實現單例。

 

建造者模式

經常碰見的 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);

很多人是這麼用的，但是筆者覺得其實這種寫法非常地不優雅，不是很推薦使用。

這種build模式本質上是Builder類引入要建立的物件，然後每次給某個屬性值複製完成之後，再返回這個物件就OK了。

原型模式

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

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

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

protected native Object clone() throws CloneNotSupportedException;

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

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

 

建立型模式總結

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

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

 

結構型模式

前面建立型模式介紹了建立物件的一些設計模式，這節介紹的結構型模式旨在通過改變程式碼結構來達到解耦的目的，使得我們的程式碼容易維護和擴充套件。

 

代理模式

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

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

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

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

我們發現沒有，代理模式說白了就是做 “方法包裝” 或做 “方法增強”。在面向切面程式設計中，其實就是動態代理的過程。比如 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();
}

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

這回大家應該就知道抽象在哪裡，怎麼解耦了吧。橋樑模式的優點也是顯而易見的，就是非常容易進行擴充套件。

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

本質上就是：兩個抽象類，一個抽閒類組合另外一個抽象類。這是典型的介面式程式設計。是依賴倒置原則，介面隔離原則的體現。

舉個大家常用的例子，JDBC就是橋接模式的典型體現。在呼叫DB進行資料操作的時候，開啟連結，寫SQL，關閉連線等一系列的業務操作都是用的JDBC的抽象介面，底層驅動各家驅動使用JDBC介面實現各自的驅動。如果想要更換DB例如將MySQL換成MongoDB，只需要換驅動就行，業務程式碼幾乎不需要動。

裝飾模式

要把裝飾模式說清楚明白，不是件容易的事情。也許讀者知道 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("")));

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

裝飾模式有點在於實現介面的具體功能和裝飾的功能可以動態的自由組合，中間沒有強力耦合。

巧妙之處在於裝飾類繼承功能介面裝飾類子類建構函式入參為要裝飾類的抽象定義（父介面），產生了如下的效果：

    1、裝飾類可以裝飾任何具體功能類，只要實現抽象介面即可

    2、裝飾類和具體功能類（類圖左側的實現類）實現相同的介面，裝飾類裝飾完具體功能類後，直接呼叫即可

 

門面模式

門面模式（也叫外觀模式，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 中。

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

本質上就是物件快取起來重複利用。同一個物件，在不同的場景下回改變其屬性值。

 

結構型模式總結

前面，我們說了代理模式、介面卡模式、橋樑模式、裝飾模式、門面模式、組合模式和享元模式。讀者是否可以分別把這幾個模式說清楚了呢？在說到這些模式的時候，心中是否有一個清晰的圖或處理流程在腦海裡呢？

代理模式是做方法增強的，介面卡模式是把雞包裝成鴨這種用來適配介面的，橋樑模式做到了很好的解耦，裝飾模式從名字上就看得出來，適合於裝飾類或者說是增強類的場景，門面模式的優點是客戶端不需要關心例項化過程，只要呼叫需要的方法即可，組合模式用於描述具有層次結構的資料，享元模式是為了在特定的場景中快取已經建立的物件，用於提高效能。

 

行為型模式

行為型模式關注的是各個類之間的相互作用，將職責劃分清楚，使得我們的程式碼更加地清晰。

 

策略模式

策略模式太常用了，所以把它放到最前面進行介紹。它比較簡單，我就不廢話，直接用程式碼說事吧。

下面設計的場景是，我們需要畫一個圖形，可選的策略就是用紅色筆來畫，還是綠色筆來畫，或者藍色筆來畫。

首先，先定義一個策略介面：

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

然後我們定義具體的幾個策略：

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

使用策略的類：

public class Context {
   private Strategy strategy;

   public Context(Strategy strategy){
      this.strategy = strategy;
   }

   public int executeDraw(int radius, int x, int y){
      return strategy.draw(radius, x, y);
   }
}

客戶端演示：

public static void main(String[] args) {
    Context context = new Context(new BluePen()); // 使用綠色筆來畫
      context.executeDraw(10, 0, 0);
}

放到一張圖上，讓大家看得清晰些：

這個時候，大家有沒有聯想到結構型模式中的橋樑模式，它們其實非常相似，我把橋樑模式的圖拿過來大家對比下：

要我說的話，它們非常相似，橋樑模式在左側加了一層抽象而已。橋樑模式的耦合更低，結構更復雜一些。

Context類在當前的示例下是沒有作用的，不如直接用子類給父類賦值直接呼叫就OK。Context類的作用是對策略類的包裝，當策略類的初始化和使用不在一出時切使用策略的地方不想關注具體的策略這時候Context就該出場了。

 

觀察者模式

觀察者模式對於我們來說，真是再簡單不過了。無外乎兩個操作，觀察者訂閱自己關心的主題和主題有資料變化後通知觀察者們。

首先，需要定義主題，每個主題需要持有觀察者列表的引用，用於在資料變更的時候通知各個觀察者：

public class Subject {
    private List<Observer> observers = new ArrayList<Observer>();
    private int state;
    public int getState() {
        return state;
    }
    public void setState(int state) {
        this.state = state;
        // 資料已變更，通知觀察者們
        notifyAllObservers();
    }
    // 註冊觀察者
    public void attach(Observer observer) {
        observers.add(observer);
    }
    // 通知觀察者們
    public void notifyAllObservers() {
        for (Observer observer : observers) {
            observer.update();
        }
    }
}

定義觀察者介面：

public abstract class Observer {
    protected Subject subject;
    public abstract void update();
}

其實如果只有一個觀察者類的話，介面都不用定義了，不過，通常場景下，既然用到了觀察者模式，我們就是希望一個事件出來了，會有多個不同的類需要處理相應的資訊。比如，訂單修改成功事件，我們希望發簡訊的類得到通知、發郵件的類得到通知、處理物流資訊的類得到通知等。

我們來定義具體的幾個觀察者類：

public class BinaryObserver extends Observer {
    // 在構造方法中進行訂閱主題
    public BinaryObserver(Subject subject) {
        this.subject = subject;
        // 通常在構造方法中將 this 釋出出去的操作一定要小心
        this.subject.attach(this);
    }
    // 該方法由主題類在資料變更的時候進行呼叫
    @Override
    public void update() {
        String result = Integer.toBinaryString(subject.getState());
        System.out.println("訂閱的資料發生變化，新的資料處理為二進位制值為：" + result);
    }
}

public class HexaObserver extends Observer {
    public HexaObserver(Subject subject) {
        this.subject = subject;
        this.subject.attach(this);
    }
    @Override
    public void update() {
        String result = Integer.toHexString(subject.getState()).toUpperCase();
        System.out.println("訂閱的資料發生變化，新的資料處理為十六進位制值為：" + result);
    }
}

客戶端使用也非常簡單：

public static void main(String[] args) {
    // 先定義一個主題
    Subject subject1 = new Subject();
    // 定義觀察者
    new BinaryObserver(subject1);
    new HexaObserver(subject1);

    // 模擬資料變更，這個時候，觀察者們的 update 方法將會被呼叫
    subject.setState(11);
}

output:

訂閱的資料發生變化，新的資料處理為二進位制值為：1011
訂閱的資料發生變化，新的資料處理為十六進位制值為：B

當然，jdk 也提供了相似的支援，具體的大家可以參考 java.util.Observable 和 java.util.Observer 這兩個類。

實際生產過程中，觀察者模式往往用訊息中介軟體來實現，如果要實現單機觀察者模式，筆者建議讀者使用 Guava 中的 EventBus，它有同步實現也有非同步實現，本文主要介紹設計模式，就不展開說了。

還有，即使是上面的這個程式碼，也會有很多變種，大家只要記住核心的部分，那就是一定有一個地方存放了所有的觀察者，然後在事件發生的時候，遍歷觀察者，呼叫它們的回撥函式。

 

責任鏈模式

責任鏈通常需要先建立一個單向連結串列，然後呼叫方只需要呼叫頭部節點就可以了，後面會自動流轉下去。比如流程審批就是一個很好的例子，只要終端使用者提交申請，根據申請的內容資訊，自動建立一條責任鏈，然後就可以開始流轉了。

有這麼一個場景，使用者參加一個活動可以領取獎品，但是活動需要進行很多的規則校驗然後才能放行，比如首先需要校驗使用者是否是新使用者、今日參與人數是否有限額、全場參與人數是否有限額等等。設定的規則都通過後，才能讓使用者領走獎品。

如果產品給你這個需求的話，我想大部分人一開始肯定想的就是，用一個 List 來存放所有的規則，然後 foreach 執行一下每個規則就好了。不過，讀者也先別急，看看責任鏈模式和我們說的這個有什麼不一樣？

首先，我們要定義流程上節點的基類：

public abstract class RuleHandler {
    // 後繼節點
    protected RuleHandler successor;

    public abstract void apply(Context context);

    public void setSuccessor(RuleHandler successor) {
        this.successor = successor;
    }

    public RuleHandler getSuccessor() {
        return successor;
    }
}

接下來，我們需要定義具體的每個節點了。

校驗使用者是否是新使用者：

public class NewUserRuleHandler extends RuleHandler {
    public void apply(Context context) {
        if (context.isNewUser()) {
            // 如果有後繼節點的話，傳遞下去
            if (this.getSuccessor() != null) {
                this.getSuccessor().apply(context);
            }
        } else {
            throw new RuntimeException("該活動僅限新使用者參與");
        }
    }
}

校驗使用者所在地區是否可以參與：

public class LocationRuleHandler extends RuleHandler {
    public void apply(Context context) {
        boolean allowed = activityService.isSupportedLocation(context.getLocation);
        if (allowed) {
            if (this.getSuccessor() != null) {
                this.getSuccessor().apply(context);
            }
        } else {
            throw new RuntimeException("非常抱歉，您所在的地區無法參與本次活動");
        }
    }
}

校驗獎品是否已領完：

public class LimitRuleHandler extends RuleHandler {
    public void apply(Context context) {
        int remainedTimes = activityService.queryRemainedTimes(context); // 查詢剩餘獎品
        if (remainedTimes > 0) {
            if (this.getSuccessor() != null) {
                this.getSuccessor().apply(userInfo);
            }
        } else {
            throw new RuntimeException("您來得太晚了，獎品被領完了");
        }
    }
}

客戶端：

public static void main(String[] args) {
    RuleHandler newUserHandler = new NewUserRuleHandler();
    RuleHandler locationHandler = new LocationRuleHandler();
    RuleHandler limitHandler = new LimitRuleHandler();

    // 假設本次活動僅校驗地區和獎品數量，不校驗新老使用者
    locationHandler.setSuccessor(limitHandler);

    locationHandler.apply(context);
}

程式碼其實很簡單，就是先定義好一個連結串列，然後在通過任意一節點後，如果此節點有後繼節點，那麼傳遞下去。

至於它和我們前面說的用一個 List 存放需要執行的規則的做法有什麼異同，留給讀者自己琢磨吧。

 

模板方法模式

在含有繼承結構的程式碼中，模板方法模式是非常常用的。

通常會有一個抽象類：

public abstract class AbstractTemplate {
    // 這就是模板方法
    public void templateMethod() {
        init();
        apply(); // 這個是重點
        end(); // 可以作為鉤子方法
    }

    protected void init() {
        System.out.println("init 抽象層已經實現，子類也可以選擇覆寫");
    }

    // 留給子類實現
    protected abstract void apply();

    protected void end() {
    }
}

模板方法中呼叫了 3 個方法，其中 apply() 是抽象方法，子類必須實現它，其實模板方法中有幾個抽象方法完全是自由的，我們也可以將三個方法都設定為抽象方法，讓子類來實現。也就是說，模板方法只負責定義第一步應該要做什麼，第二步應該做什麼，第三步應該做什麼，至於怎麼做，由子類來實現。

我們寫一個實現類：

public class ConcreteTemplate extends AbstractTemplate {
    public void apply() {
        System.out.println("子類實現抽象方法 apply");
    }

    public void end() {
        System.out.println("我們可以把 method3 當做鉤子方法來使用，需要的時候覆寫就可以了");
    }
}

客戶端呼叫演示：

public static void main(String[] args) {
    AbstractTemplate t = new ConcreteTemplate();
    // 呼叫模板方法
    t.templateMethod();
}

程式碼其實很簡單，基本上看到就懂了，關鍵是要學會用到自己的程式碼中。

 

狀態模式

廢話我就不說了，我們說一個簡單的例子。商品庫存中心有個最基本的需求是減庫存和補庫存，我們看看怎麼用狀態模式來寫。

核心在於，我們的關注點不再是 Context 是該進行哪種操作，而是關注在這個 Context 會有哪些操作。

定義狀態介面：

public interface State {
    public void doAction(Context context);
}

定義減庫存的狀態：

public class DeductState implements State {

    public void doAction(Context context) {
        System.out.println("商品賣出，準備減庫存");
        context.setState(this);

        //... 執行減庫存的具體操作
    }

    public String toString() {
        return "Deduct State";
    }
}

定義補庫存狀態：

public class RevertState implements State {

    public void doAction(Context context) {
        System.out.println("給此商品補庫存");
        context.setState(this);

        //... 執行加庫存的具體操作
    }

    public String toString() {
        return "Revert State";
    }
}

前面用到了 context.setState(this)，我們來看看怎麼定義 Context 類：

public class Context {
    private State state;
      private String name;
      public Context(String name) {
        this.name = name;
    }

      public void setState(State state) {
        this.state = state;
    }
      public void getState() {
        return this.state;
    }
}

我們來看下客戶端呼叫，大家就一清二楚了：

public static void main(String[] args) {
    // 我們需要操作的是 iPhone X
    Context context = new Context("iPhone X");

    // 看看怎麼進行補庫存操作
      State revertState = new RevertState();
      revertState.doAction(context);

    // 同樣的，減庫存操作也非常簡單
      State deductState = new DeductState();
      deductState.doAction(context);

      // 如果需要我們可以獲取當前的狀態
    // context.getState().toString();
}

讀者可能會發現，在上面這個例子中，如果我們不關心當前 context 處於什麼狀態，那麼 Context 就可以不用維護 state 屬性了，那樣程式碼會簡單很多。

不過，商品庫存這個例子畢竟只是個例，我們還有很多例項是需要知道當前 context 處於什麼狀態的。

本質上將狀態判斷switch case或者if else 轉換為具體的狀態類，每個狀態類處理好自己的工作就OK了

行為型模式總結

行為型模式部分介紹了策略模式、觀察者模式、責任鏈模式、模板方法模式和狀態模式，其實，經典的行為型模式還包括備忘錄模式、命令模式等，但是它們的使用場景比較有限，而且本文篇幅也挺大了，我就不進行介紹了。

 

總結

學習設計模式的目的是為了讓我們的程式碼更加的優雅、易維護、易擴充套件。這次整理這篇文章，讓我重新審視了一下各個設計模式，對我自己而言收穫還是挺大的。我想，文章的最大收益者一般都是作者本人，為了寫一篇文章，需要鞏固自己的知識，需要尋找各種資料，而且，自己寫過的才最容易記住，也算是我給讀者的建議吧。

·END·

 

原文地址：https://mp.weixin.qq.com/s/pjQ6xqDvHHlfANUW_o2dTQ