前言

• 這篇文章是我個人的學習筆記，可能無法做到面面俱到，也可能會有各種紕漏，如果任何疑惑的地方，歡迎一起討論~
• 本篇文章僅僅是讓小伙伴們對設計模式有一個概覽上的理解，所以篇幅較小，無深入內容，
• 如果想完整閱讀這個系列的文章，歡迎關注我的專欄《設計模式》~
• 哦對了！請不要吝嗇->點贊、關注、收藏~

什么是設計模式

• 以我個人的理解，設計模式就是一種業界公認的，在某種場景下的，高效的、滿足設計規范的代碼撰寫套路，

設計模式分類

• 設計模式分為三個大類，本文章將從三個大類中抽取一兩個典型的設計模式，進行簡要介紹，
  • 創建型模式：專注于優化物件創建方式的設計模式，通常會與多型進行配合實作，例如本文下面要講的單例模式、工廠方法模式、抽象工廠模式，
  • 結構型模式：用于優化類的上下級結構的設計模式，例如本文下面要講的裝飾器模式、代理模式，
  • 行為型模式：用于優化類、方法之間的互動方式和功能職責，例如本文下面要講的模版方法模式，

創建型模式

單例模式

• 單例模式的特點是整個系統中，該類的物件最多只會有一個，咱日常應用中有一個很好的例子——Windows系統的任務管理器，無論你怎么點，任務管理器始終都只會有一個，
• 單例模式適合用在對系統整體進行統一管理的類，有一種“靜態”類的感覺，

單例模式的實作方法

• 單例模式分為兩種實作方式：餓漢式和懶漢式，
  • 餓漢式：在JVM加載類的時候，就生成該類的物件，該方式不會產生執行緒同步問題，但是會造成一定程度的資源浪費，
  • 懶漢式：在第一次呼叫該類的時候，才生成該類的物件，該方式需要處理執行緒同步問題，但是不會造成資源浪費，

餓漢式

• 話不多說，直接上代碼，比如我們模仿一個“任務管理器”，
  • 好吧，多說一句，餓漢式實作方式就3個步驟，我將在寫在下面的代碼備注中，以便更好理解，

//餓漢式實作類
public class HungryMan {
    private final HashMap<String, String> tasks;//當前任務
    private int taskId;//任務編號

    //1.宣告本類自己的私有的靜態物件常量
    private static final HungryMan hungryMan = new HungryMan();

    //2.私有化構造方法
    private HungryMan() {
        System.out.println("餓漢來啦！");
        tasks = new HashMap<>();
        taskId = 0;
    }

    //3.對外界提供獲取實體的方法，除了這3個特殊的步驟，其他部分代碼全部和普通的類一樣，
    public static HungryMan getInstance() {
        return hungryMan;
    }

    //模擬一個添加任務的方法
    public String addTask(String taskName) {
        String id = Integer.toString(taskId++);
        tasks.put(id, taskName);
        System.out.println("添加了任務：" + taskName);

        return id;
    }

    //模擬一個查詢任務的方法
    public String getTaskName(String taskId) {
        return tasks.get(taskId);
    }
}

//啟動類
public class Starter {
    public static void main(String[] args) {
        testHungry();
    }

    private static void testHungry(){
        //測驗兩個物件是不是同一個
        System.out.println("我開始運行餓漢式單例模式啦！");

        HungryMan hungryMan1 = HungryMan.getInstance();
        HungryMan hungryMan2 = HungryMan.getInstance();

        String id = hungryMan1.addTask("4399小游戲");
        System.out.println(hungryMan2.getTaskName(id));
    }
}

• 運行結果如下，可以看到，hungryMan1和hungryMan2兩個變數指向的是同一個物件，

我開始運行餓漢式單例模式啦！
餓漢來啦！
添加了任務：4399小游戲
4399小游戲

• 不過我目前有一點比較疑惑，理論上在還沒有呼叫HungryMan的時候，JVM就應該已經初始化了所有靜態資源才對，但事實上，從方法呼叫堆疊可以看出，即使是餓漢式，其物件也是在呼叫該類時才會創建，不知道這個是不是JVM對靜態資源的一種自動優化，希望有明白的大佬可以解讀一下，

懶漢式

• 對比著餓漢式來，還是用同樣的例子，實作步驟依然放在代碼注釋中講解，

//懶漢式實作類
public class LazyMan {
    private final HashMap<String, String> tasks;//當前任務
    private int taskId;//任務編號

    //1.宣告本類自己的私有的靜態物件常量，此時并不實體化物件，
    private static LazyMan lazyMan;

    //2.私有化構造方法
    private LazyMan() {
        System.out.println("懶漢來啦！");
        tasks = new HashMap<>();
        taskId = 0;
    }

    //3.對外界提供獲取實體的方法，如果是第一次呼叫（lazyMan為空），則會實體化物件，除了這3個特殊的步驟，其他部分代碼全部和普通的類一樣，
    public static LazyMan getInstance() {
        if(lazyMan == null){
            lazyMan = new LazyMan();
        }

        return lazyMan;
    }

    //模擬一個添加任務的方法
    public String addTask(String taskName) {
        String id = Integer.toString(taskId++);
        tasks.put(id, taskName);
        System.out.println("添加了任務：" + taskName);

        return id;
    }

    //模擬一個查詢任務的方法
    public String getTaskName(String taskId) {
        return tasks.get(taskId);
    }
}

//啟動類
public class Starter {
    public static void main(String[] args) {
        testLazy();
    }

    private static void testHungry(){
        //測驗兩個物件是不是同一個
        System.out.println("我開始運行餓漢式單例模式啦！");

        HungryMan hungryMan1 = HungryMan.getInstance();
        HungryMan hungryMan2 = HungryMan.getInstance();

        String id = hungryMan1.addTask("4399小游戲");
        System.out.println(hungryMan2.getTaskName(id));
    }

    private static void testLazy(){
        //測驗兩個物件是不是同一個
        System.out.println("我開始運行懶漢式單例模式啦！");

        LazyMan lazyMan1 = LazyMan.getInstance();
        LazyMan lazyMan2 = LazyMan.getInstance();

        String id = lazyMan1.addTask("7k7k小游戲");
        System.out.println(lazyMan2.getTaskName(id));
    }
}

• 運行結果如下，餓漢式和懶漢式的區別很細微，他們的實作步驟幾乎一樣，只是具體的實作邏輯有些許區別，懶漢式就是實實在在的，在初次呼叫getInstance方法的時候才會創建物件，

我開始運行懶漢式單例模式啦！
懶漢來啦！
添加了任務：7k7k小游戲
7k7k小游戲

解決執行緒同步問題

• 上面也說到了，懶漢式會存在執行緒同步的問題，為什么呢？聽我娓娓道來~
  1. 問題就出在getInstance方法上，我們知道創建物件是需要一段時間的，而物件在被創建完成之前，lazyMan這個成員變數始侄訓等于null，
  2. 這個時候，來了兩個執行緒（他們叫小線和大線），同時呼叫了getInstance方法，小線跑得快一點，于是先通過了if判斷，于是開始對lazyMan進行實體化，
  3. 但是在小線實體化完成之前，大線也來進行if判斷了，此時大線理所當然能夠通過判斷，于是也開始了對lazyMan的實體化，
  4. 此時，兩個執行緒呼叫getInstance方法，就有可能會獲取到兩個不同的物件（當然運氣好的話也可能是一個，總之這是一個不正確的狀態），
• 正是因為getInstance方法訪問了臨界區資源，所以我們應當對getInstance方法加鎖，并且是整個系統使用同一把鎖，
• 此時聰明的小伙伴唰唰唰就吧改好的方法貼出來了：

    public synchronized static LazyMan getInstance() {
        if(lazyMan == null){
            lazyMan = new LazyMan();
        }

        return lazyMan;
    }

• 但是這樣真的好么？當然，這樣做確實解決了執行緒同步問題，但是卻引入了一個新問題——同時只能有一個執行緒能夠獲取這個類的物件，導致效率較低，小學二年級的同學都知道，加鎖的粒度要盡可能地小，
• 所以我們需要把方法鎖改為代碼塊鎖，而且粒度要盡可能小，這個地方就稍微有一點點難度了，
  • 我們知道，其實臨界區資源就是new物件那一行，那我們要防止執行緒同步問題，就應該同一時間只讓一個執行緒創建物件，所以我決定把鎖包在if外面，
  • 但是僅僅用一個包住if判斷的鎖就解決問題了么？當然沒有，小小分析一下就能發現，同一時間還是只能有一個執行緒獲取物件，于是我們再加一個if判斷，問題就解決了，最終代碼如下，

    public static LazyMan getInstance() {
        if (lazyMan == null) {
            synchronized (LazyMan.class) {
                if (lazyMan == null) {
                    lazyMan = new LazyMan();
                }
            }
        }

        return lazyMan;
    }

工廠方法模式

• 工廠方法模式用于強化物件創建，其主要優勢在于可以在物件創建的前后封裝一些額外的操作；并且當系統中存在大量該類的物件創建代碼時，可以提高系統的可維護性，
• 工廠方法模式也有幾個分支——普通工廠方法模式、多個工廠方法模式、靜態工廠方法模式、抽象工廠方法模式，

普通工廠方法模式

• 普通工廠方法模式有一點點反射機制內味兒，但是它可以比反射機制創建物件更靈活，
• 優點：
  • 可以實作動態編程，即創建的物件可以通過字串傳遞，
  • 可以在創建物件前后額外撰寫操作，
• 缺點：
  • 可能存在字串傳遞錯誤的情況，所以需要有對應的例外處理，
  • 每次使用需要額外創建一個工廠物件，
  • 若需求發生變更，需要調整工廠類代碼，因此不滿足開閉原則，
• 其實我感覺普通工廠方法模式就很實用，因為動態編程有時候真的很爽~
• 來個簡單的例子：

//創建一個父類
public class Person {
    public Person() {
        System.out.println("a person created");
    }
}

//創建一個子類
public class Man extends Person {
    public Man() {
        System.out.println("a man created");
    }
}

//創建另一個子類
public class Woman extends Person {
    public Woman() {
        System.out.println("a woman created");
    }
}

//普通工廠
public class PersonFactory {
    public Person create(String type) throws Exception {
        System.out.println("ready to crate " + type);
        switch (type) {
            case "Man":
                return new Man();
            case "Woman":
                return new Woman();
            default:
                throw new Exception("創建失敗：該類不存在");
        }
    }
}

//啟動類
public class Starter {
    public static void main(String[] args) throws Exception {
        testNormal();
    }

    private static void testNormal() throws Exception {
        PersonFactory factory = new PersonFactory();
        Person man = factory.create("Man");
        Person incorrect = factory.create("autoMan");
    }
}

• 執行結果如下，可以看到，普通工廠方法模式可以實作動態編程，當我們把創建物件的字串以變數的方式傳遞，則可以通過變數的值，來靈活創建物件，此外，還可以看到，普通工廠方法模式的物件創建是可能出錯的，

ready to crate Man
a person created
a man created
ready to crate autoMan
Exception in thread "main" java.lang.Exception: 創建失敗：該類不存在
	at com.DesignPattern.Creational.Factory.NormalFactory.PersonFactory.create(PersonFactory.java:17)
	at com.DesignPattern.Creational.Factory.Starter.testNormal(Starter.java:14)
	at com.DesignPattern.Creational.Factory.Starter.main(Starter.java:8)

多個工廠方法模式

• 對普通工廠方法模式進行改造，對每一種類都單獨提供一個實體化方法，改造完就沒有反射機制內味兒了，
• 優點：
  • 不會存在字串傳遞錯誤的情況，
  • 可以在創建物件前后額外撰寫操作，
• 缺點：
  • 失去了動態編程的優點，
  • 每次使用需要額外創建一個工廠物件，
  • 若需求發生變更，需要調整工廠類代碼，因此不滿足開閉原則，
• 這個模式的例子就和靜態工廠方法模式放在一起吧，

靜態工廠方法模式

• 靜態工廠方法模式可以套用在普通工廠方法模式和多個工廠方法模式上面，通過將創建物件的方法靜態化，從而解決了每次使用需要額外創建一個工廠物件的缺點，
• 來個栗子，被生產的類還是一樣（Person家族），所以就省略了，區別主要在于工廠類，

//靜態多個工廠
public class MultiPersonFactory {
    public static Person createMan() {
        System.out.println("ready to crate Man");
        return new Man();
    }

    public static Person createWoman() {
        System.out.println("ready to crate Woman");
        return new Woman();
    }
}

//啟動類
public class Starter {
    public static void main(String[] args) throws Exception {
        testMulti();
    }

    private static void testNormal() throws Exception {
        PersonFactory factory = new PersonFactory();
        Person man = factory.create("Man");
        Person incorrect = factory.create("autoMan");
    }

    private static void testMulti() {
        Person man = MultiPersonFactory.createMan();
    }
}

• 執行結果如下，靜態工廠方法可以省去每一次都去實體化工廠物件的程序；多個工廠方法模式雖然失去了動態編程能力，但是避免了物件創建錯誤的情況，

ready to crate Man
a person created
a man created

抽象工廠方法模式

• 該模式是對多個工廠方法模式的改良，通過將工廠類進行抽象和繼承，來讓其滿足開閉原則，
• 直接舉個栗子就明白了，這里我就不放啟動類了，直接給你們看工廠類吧，

//抽象工廠
public class AbstractManFactory extends Person {
    public Person create(){
        System.out.println("ready to create Man");
        return new Man();
    }
}

//子工廠
public abstract class AbstractPersonFactory {
    public abstract Person create();
}

//子工廠
public class AbstractWomanFactory extends Person {
    public Person create(){
        System.out.println("ready to create Woman");
        return new Woman();
    }
}

• 一目了然，當需要生產的類有多少種，工廠類就會對應添加多少種子工廠，從而避免了需求變更時，需要對原有代碼進行修改，這就滿足了“對擴展開放，對修改關閉”原則，也就是開閉原則，

結構型模式

裝飾器模式

• 裝飾器模式可以在不改變原來類的功能的基礎上，附加上額外的邏輯處理，
• 優點：
  • 可以靈活的選擇使用功能擴展（使用裝飾類或使用原始類），
  • 只要原始類實作的是同一個介面，那么這個裝飾器可以對多個原始類進行修飾，
  • 符合開閉原則的基礎上，能對原始類進行優化，
• 缺點：
  • 原始類和裝飾類都需要額外實作裝飾介面，增加了代碼復雜性，
  • 需要宣告額外的相似的物件，降低了代碼的可讀性，
• 文字有點蒼白，直接上栗子！

//可裝飾介面
public interface Decorateable {
    //這里宣告的是需要被裝飾的方法
    void say();
}

//原始類
public class Native implements Decorateable {
    //原始的方法
    @Override
    public void say(){
        System.out.println("我就是我，最單純的我~");
    }
}

//裝飾器
public class Decorater implements Decorateable {
    private final Decorateable decorateable;//原始類物件

    //通過多型，來將被裝飾的原始類傳遞給裝飾器
    public Decorater(Decorateable decorateable) {
        this.decorateable = decorateable;
    }

    //被裝飾后的方法
    @Override
    public void say() {
        //呼叫原始類的該方法
        decorateable.say();
        //裝飾邏輯
        System.out.println("但就是要給你加點顏色不一樣的花火!");
    }
}

//啟動類
public class Starter {
    public static void main(String[] args) {
        //測驗原始類的say方法
        Decorateable na = new Native();
        na.say();

        System.out.println("======================================");

        //測驗裝飾后的say方法
        Decorateable decorater = new Decorater(na);
        decorater.say();
    }
}

• 執行結果如下，怎么說呢，可能只能用《九品芝麻官》里的一個橋段來形容了：我進來啦！我又出去啦！我又進來啦！！這種來去自如的感覺真不戳~

我就是我，最單純的我~
======================================
我就是我，最單純的我~
但就是要給你加點顏色不一樣的花火!

代理模式

• 代理模式和裝飾器模式很像，但是作用不一樣，代理模式的作用是以中介的身份，替代一個類與其他類互動的程序，
  • 打個很恰當的比方：假如我要租房子，我就是被代理的類，中介就是代理類，而房東就是其他類，在找房子的時候，并不需要我親自出面來與房東互動，
• 代理模式的作用主要在于控制被代理類的訪問權限以及動態添加方法的額外邏輯處理，
• 舉個栗子如下，因為和裝飾器模式很像，所以這里就只放出代理類，其余代碼同裝飾器模式的例子，

//裝飾器
public class Proxy implements Decorateable {
    private final Decorateable decorateable = new Native();//直接創建原始類物件

    //被裝飾后的方法
    @Override
    public void say() {
        //呼叫原始類的該方法
        decorateable.say();
        //代理邏輯
        System.out.println("代理類在給你加點顏色不一樣的花火!");
    }
}

• 從代碼就能看出來，代理模式和裝飾器模式存在以下區別：
  • 裝飾器模式通常將原始類物件作為引數來構造裝飾類物件；而代理模式直接創建被代理的類的物件，
  • 裝飾器模式關注于在一個物件上動態的添加方法；代理模式關注于控制物件的訪問，

行為型模式

模版方法模式

• 模板方法模式可以說是一個特別簡單，但是又特別實用的設計模式了，
• 其通過在一個抽象類中提取公共的方法作為普通方法、將不同處理邏輯的同名方法設定為抽象方法，由子類根據自身需求來具體重寫抽象方法，從而讓固定的流程產生不同的結果，
• 這樣做的優點在于提高代碼可讀性、結構性，從而降低后期維護成本，而模板方法模式目前沒有發現明顯的缺點，
• 聽起來好高端，其實很簡單，比如還是拿Person類那一系舉個栗子：

//Person類，作為模板類
public abstract class Person {
    //所有人走路的方式都是一樣的
    public void walk(){
        System.out.println("用兩條腿走路");
    }

    //男性和女性說話會有區別，所以需要子類來實作
    public abstract void speak();
}

//創建一個子類
public class Man extends Person {
    @Override
    public void speak() {
        System.out.println("男性說話音調會低一些");
    }
}

//創建另一個子類
public class Woman extends Person {
    @Override
    public void speak() {
        System.out.println("女性說話音調會高一些");
    }
}

//啟動類
public class Starter {
    public static void main(String[] args) {
        testFactory();
    }

    public static void testFactory(){
        //通過多型創建Man和Woman物件
        Person man = new Man();
        Person woman = new Woman();

        //分別測驗走路和說話
        man.speak();
        woman.speak();
        man.walk();
        woman.walk();
    }
}

• 運行結果如下，Person類這一族中，walk的實作邏輯是一模一樣的，所以我們將其提取出來放在模板類中；而speak方法，雖然是實作相同的目的，但是不同子類之間的實作邏輯會有差異，所以需要宣告為抽象方法，強制要求子類重寫邏輯，

男性說話音調會低一些
女性說話音調會高一些
用兩條腿走路
用兩條腿走路