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 種經典的模式，根據用途我們又可以分為三大類，分别為建立型模式、結構型模式和行為型模式。是的，我不善于扯這些有的沒的，還是少點廢話吧~~~
有一些重要的設計原則在開篇和大家分享下，這些原則将貫通全文：
- 面向接口程式設計，而不是面向實作。這個很重要，也是優雅的、可擴充的代碼的第一步，這就不需要多說了吧。
- 職責單一原則。每個類都應該隻有一個單一的功能，并且該功能應該由這個類完全封裝起來。
- 對修改關閉，對擴充開放。對修改關閉是說，我們辛辛苦苦加班寫出來的代碼，該實作的功能和該修複的 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，這将決定之後的所有的操作。
雖然簡單，不過我也把所有的構件都畫到一張圖上，這樣讀者看着比較清晰：
轉存失敗重新上傳取消
當涉及到産品族的時候，就需要引入抽象工廠模式了。
一個經典的例子是造一台電腦。我們先不引入抽象工廠模式，看看怎麼實作。
因為電腦是由許多的構件組成的，我們将 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 保證了它們不會再被執行個體化，是以它天生就是單例的。不說了，讀者自己看着辦吧，不建議使用。
經常碰見的 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() 方法相關的知識即可。
參考文章
微信公衆号
個人公衆号：程式員黃小斜
微信公衆号【程式員黃小斜】新生代青年聚集地，程式員成長充電站。作者黃小斜，職業是阿裡程式員，身份是斜杠青年，希望和更多的程式員交朋友，一起進步和成長！專注于分享技術、面試、職場等成長幹貨，這一次，我們一起出發。
關注公衆号後回複“2020”領取我這兩年整理的學習資料，涵蓋自學程式設計、求職面試、算法刷題、Java技術學習、計算機基礎和考研等8000G資料合集。
技術公衆号：Java技術江湖
微信公衆号【Java技術江湖】一位阿裡 Java 工程師的技術小站，專注于 Java 相關技術：SSM、SpringBoot、MySQL、分布式、中間件、叢集、Linux、網絡、多線程，偶爾講點Docker、ELK，同時也分享技術幹貨和學習經驗，緻力于Java全棧開發！
關注公衆号後回複“PDF”即可領取200+頁的《Java工程師面試指南》強烈推薦，幾乎涵蓋所有Java工程師必知必會的知識點。