Java 設計模式
轉自https://javadoop.com/post/design-pattern
系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裏查看
喜歡的話麻煩點下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() 方法相關的知識即可。
參考文章
轉自https://javadoop.com/post/design-pattern