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

時間  2019-11-07
標籤 初探 java 設計 模式 建立 工廠 欄目 Java 简体版
原文   原文鏈接

Java 設計模式前端

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

系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到個人倉庫裏查看python

https://github.com/h2pl/Java-Tutorialgit

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

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

www.how2playlife.com面試

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

若是對本系列文章有什麼建議，或者是有什麼疑問的話，也能夠關注公衆號【Java技術江湖】聯繫做者，歡迎你參與本系列博文的創做和修訂編程

一直想寫一篇介紹設計模式的文章，讓讀者能夠很快看完，並且一看就懂，看懂就會用，同時不會將各個模式搞混。自認爲本文仍是寫得不錯的，花了很多心思來寫這文章和作圖，力求讓讀者真的能看着簡單同時有所收穫。後端

設計模式是對你們實際工做中寫的各類代碼進行高層次抽象的總結，其中最出名的當屬 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。

工廠模式

簡單工廠模式很簡單，若是它能知足咱們的須要，我以爲就不要折騰了。之因此須要引入工廠模式，是由於咱們每每須要使用兩個或兩個以上的工廠。

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，這將決定以後的全部的操做。

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

轉存失敗從新上傳取消factory-1​

抽象工廠模式

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

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

由於電腦是由許多的構件組成的，咱們將 CPU 和主板進行抽象，而後 CPU 由 CPUFactory 生產，主板由 MainBoardFactory 生產，而後，咱們再將 CPU 和主板搭配起來組合在一塊兒，以下圖：

轉存失敗從新上傳取消factory-1​

這個時候的客戶端調用是這樣的：

// 獲得 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 產的主板不能兼容使用，那麼這代碼就容易出錯，由於客戶端並不知道它們不兼容，也就會錯誤地出現隨意組合。

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

abstract-factory-2

當涉及到這種產品族的問題的時候，就須要抽象工廠模式來支持了。咱們再也不定義 CPU 工廠、主板工廠、硬盤工廠、顯示屏工廠等等，咱們直接定義電腦工廠，每一個電腦工廠負責生產全部的設備，這樣能保證確定不存在兼容問題。

abstract-factory-3

這個時候，對於客戶端來講，再也不須要單獨挑選 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

微信公衆號

我的公衆號：程序員黃小斜

​黃小斜是 985 碩士，阿里巴巴Java工程師，在自學編程、技術求職、Java學習等方面有豐富經驗和獨到看法，但願幫助到更多想要從事互聯網行業的程序員們。​做者專一於 JAVA 後端技術棧，熱衷於分享程序員乾貨、學習經驗、求職心得，以及自學編程和Java技術棧的相關乾貨。​黃小斜是一個斜槓青年，堅持學習和寫做，相信終身學習的力量，但願和更多的程序員交朋友，一塊兒進步和成長！

原創電子書:關注微信公衆號【程序員黃小斜】後回覆【原創電子書】便可領取我原創的電子書《菜鳥程序員修煉手冊：從技術小白到阿里巴巴Java工程師》這份電子書總結了我2年的Java學習之路，包括學習方法、技術總結、求職經驗和麪試技巧等內容，已經幫助不少的程序員拿到了心儀的offer！

程序員3T技術學習資源： 一些程序員學習技術的資源大禮包，關注公衆號後，後臺回覆關鍵字 「資料」 便可免費無套路獲取，包括Java、python、C++、大數據、機器學習、前端、移動端等方向的技術資料。

技術公衆號：Java技術江湖

若是你們想要實時關注我更新的文章以及分享的乾貨的話，能夠關注個人微信公衆號【Java技術江湖】

這是一位阿里 Java 工程師的技術小站。做者黃小斜，專一 Java 相關技術：SSM、SpringBoot、MySQL、分佈式、中間件、集羣、Linux、網絡、多線程，偶爾講點Docker、ELK，同時也分享技術乾貨和學習經驗，致力於Java全棧開發！

Java工程師必備學習資源:關注公衆號後回覆」Java「便可領取 Java基礎、進階、項目和架構師等免費學習資料，更有數據庫、分佈式、微服務等熱門技術學習視頻，內容豐富，兼顧原理和實踐，另外也將贈送做者原創的Java學習指南、Java程序員面試指南等乾貨資源

個人公衆號

​

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程