設計模式也能夠這麼簡單（7年開發老鳥PS註釋總結）
設計模式是對你們實際工做中寫的各類代碼進行高層次抽象的總結，其中最出名的當屬 Gang of Four (GoF) 的分類了，他們將設計模式分類爲 23 種經典的模式，根據用途咱們又能夠分爲三大類，分別爲建立型模式、結構型模式和行爲型模式。java
有一些重要的設計原則在開篇和你們分享下，這些原則將貫通全文：node
-
面向接口編程，而不是面向實現。這個很重要，也是優雅的、可擴展的代碼的第一步，這就不須要多說了吧。編程
-
職責單一原則。每一個類都應該只有一個單一的功能，而且該功能應該由這個類徹底封裝起來。設計模式
-
對修改關閉，對擴展開放。對修改關閉是說，咱們辛辛苦苦加班寫出來的代碼，該實現的功能和該修復的 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。app
簡單地說，簡單工廠模式一般就是這樣，一個工廠類 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(); 就能夠了。
適配器模式總結
-
類適配和對象適配的異同
一個採用繼承，一個採用組合；
類適配屬於靜態實現，對象適配屬於組合的動態實現，對象適配須要多實例化一個對象。
整體來講，對象適配用得比較多。
-
適配器模式和代理模式的異同
比較這兩種模式，實際上是比較對象適配器模式和代理模式，在代碼結構上，它們很類似，都須要一個具體的實現類的實例。可是它們的目的不同，代理模式作的是加強原方法的活；適配器作的是適配的活，爲的是提供「把雞包裝成鴨，而後當作鴨來使用」，而雞和鴨它們之間本來沒有繼承關係。
橋樑模式
理解橋樑模式，其實就是理解代碼抽象和解耦。
咱們首先須要一個橋樑，它是一個接口，定義提供的接口方法。
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("")));
因此說嘛，要找到純的嚴格符合設計模式的代碼仍是比較難的。
裝飾模式有點在於實現接口的具體功能和裝飾的功能能夠動態的自由組合，中間沒有強力耦合。
巧妙之處在於裝飾類繼承功能接口裝飾類子類構造函數入參爲要裝飾類的抽象定義（父接口），產生了以下的效果：
一、裝飾類能夠裝飾任何具體功能類，只要實現抽象接口便可
二、裝飾類和具體功能類（類圖左側的實現類）實現相同的接口，裝飾類裝飾完具體功能類後，直接調用便可
門面模式
門面模式（也叫外觀模式，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
- 1. 簡單總結設計模式
- 2. 設計模式簡單總結
- 3. 花5分鐘，菜鳥也能學一個設計模式|簡單工廠
- 4. 設計模式--簡化解釋(二)——結構型設計模式
- 5. 設計模式總結—單例模式
- 6. 原來還能夠這麼簡單
- 7. 設計模式——設計模式總結
- 8. 設計模式 ----- 設計模式總結
- 9. 設計模式總結 —— 單例設計模式
- 10. 7-設計模式-單例模式
- 更多相關文章...
- • R 註釋 - R 語言教程
- • Rust 註釋 - RUST 教程
- • PHP開發工具
- • 委託模式
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 簡單總結設計模式
- 2. 設計模式簡單總結
- 3. 花5分鐘，菜鳥也能學一個設計模式|簡單工廠
- 4. 設計模式--簡化解釋(二)——結構型設計模式
- 5. 設計模式總結—單例模式
- 6. 原來還能夠這麼簡單
- 7. 設計模式——設計模式總結
- 8. 設計模式 ----- 設計模式總結
- 9. 設計模式總結 —— 單例設計模式
- 10. 7-設計模式-單例模式