25000 字詳解 23 種設(shè)計(jì)模式，原來(lái)可以這么簡(jiǎn)單！
關(guān)注我們有助于升職加薪噢！
設(shè)計(jì)模式是對(duì)大家實(shí)際工作中寫(xiě)的各種代碼進(jìn)行高層次抽象的總結(jié)，其中最出名的當(dāng)屬 Gang of Four (GoF) 的分類(lèi)了，他們將設(shè)計(jì)模式分類(lèi)為 23 種經(jīng)典的模式，根據(jù)用途我們又可以分為三大類(lèi)，分別為創(chuàng)建型模式、結(jié)構(gòu)型模式和行為型模式。
有一些重要的設(shè)計(jì)原則在開(kāi)篇和大家分享下，這些原則將貫通全文：
面向接口編程，而不是面向?qū)崿F(xiàn)。這個(gè)很重要，也是優(yōu)雅的、可擴(kuò)展的代碼的第一步，這就不需要多說(shuō)了吧。 職責(zé)單一原則。每個(gè)類(lèi)都應(yīng)該只有一個(gè)單一的功能，并且該功能應(yīng)該由這個(gè)類(lèi)完全封裝起來(lái)。 對(duì)修改關(guān)閉，對(duì)擴(kuò)展開(kāi)放。對(duì)修改關(guān)閉是說(shuō)，我們辛辛苦苦加班寫(xiě)出來(lái)的代碼，該實(shí)現(xiàn)的功能和該修復(fù)的 bug 都完成了，別人可不能說(shuō)改就改；對(duì)擴(kuò)展開(kāi)放就比較好理解了，也就是說(shuō)在我們寫(xiě)好的代碼基礎(chǔ)上，很容易實(shí)現(xiàn)擴(kuò)展。
創(chuàng)建型模式比較簡(jiǎn)單，但是會(huì)比較沒(méi)有意思，結(jié)構(gòu)型和行為型比較有意思。
創(chuàng)建型模式
創(chuàng)建型模式的作用就是創(chuàng)建對(duì)象，說(shuō)到創(chuàng)建一個(gè)對(duì)象，最熟悉的就是 new 一個(gè)對(duì)象，然后 set 相關(guān)屬性。但是，在很多場(chǎng)景下，我們需要給客戶(hù)端提供更加友好的創(chuàng)建對(duì)象的方式，尤其是那種我們定義了類(lèi)，但是需要提供給其他開(kāi)發(fā)者用的時(shí)候。
簡(jiǎn)單工廠模式
和名字一樣簡(jiǎn)單，非常簡(jiǎn)單，直接上代碼吧：
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。
簡(jiǎn)單地說(shuō)，簡(jiǎn)單工廠模式通常就是這樣，一個(gè)工廠類(lèi) XxxFactory，里面有一個(gè)靜態(tài)方法，根據(jù)我們不同的參數(shù)，返回不同的派生自同一個(gè)父類(lèi)（或?qū)崿F(xiàn)同一接口）的實(shí)例對(duì)象。
我們強(qiáng)調(diào)職責(zé)單一原則，一個(gè)類(lèi)只提供一種功能，F(xiàn)oodFactory 的功能就是只要負(fù)責(zé)生產(chǎn)各種 Food。
工廠模式
簡(jiǎn)單工廠模式很簡(jiǎn)單，如果它能滿(mǎn)足我們的需要，我覺(jué)得就不要折騰了。之所以需要引入工廠模式，是因?yàn)槲覀兺枰褂脙蓚€(gè)或兩個(gè)以上的工廠。
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。
客戶(hù)端調(diào)用：
public class APP {
public static void main(String[] args) {
// 先選擇一個(gè)具體的工廠
FoodFactory factory = new ChineseFoodFactory();
// 由第一步的工廠產(chǎn)生具體的對(duì)象，不同的工廠造出不一樣的對(duì)象
Food food = factory.makeFood("A");
}
}
雖然都是調(diào)用 makeFood("A") 制作 A 類(lèi)食物，但是，不同的工廠生產(chǎn)出來(lái)的完全不一樣。
第一步，我們需要選取合適的工廠，然后第二步基本上和簡(jiǎn)單工廠一樣。
核心在于，我們需要在第一步選好我們需要的工廠。比如，我們有 LogFactory 接口，實(shí)現(xiàn)類(lèi)有 FileLogFactory 和 KafkaLogFactory，分別對(duì)應(yīng)將日志寫(xiě)入文件和寫(xiě)入 Kafka 中，顯然，我們客戶(hù)端第一步就需要決定到底要實(shí)例化 FileLogFactory 還是 KafkaLogFactory，這將決定之后的所有的操作。
雖然簡(jiǎn)單，不過(guò)我也把所有的構(gòu)件都畫(huà)到一張圖上，這樣讀者看著比較清晰：
抽象工廠模式
當(dāng)涉及到產(chǎn)品族的時(shí)候，就需要引入抽象工廠模式了。
一個(gè)經(jīng)典的例子是造一臺(tái)電腦。我們先不引入抽象工廠模式，看看怎么實(shí)現(xiàn)。
因?yàn)殡娔X是由許多的構(gòu)件組成的，我們將 CPU 和主板進(jìn)行抽象，然后 CPU 由 CPUFactory 生產(chǎn)，主板由 MainBoardFactory 生產(chǎn)，然后，我們?cè)賹?CPU 和主板搭配起來(lái)組合在一起，如下圖：
這個(gè)時(shí)候的客戶(hù)端調(diào)用是這樣的：
// 得到 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);
單獨(dú)看 CPU 工廠和主板工廠，它們分別是前面我們說(shuō)的工廠模式。這種方式也容易擴(kuò)展，因?yàn)橐o電腦加硬盤(pán)的話，只需要加一個(gè) HardDiskFactory 和相應(yīng)的實(shí)現(xiàn)即可，不需要修改現(xiàn)有的工廠。
但是，這種方式有一個(gè)問(wèn)題，那就是如果 Intel 家產(chǎn)的 CPU 和 AMD 產(chǎn)的主板不能兼容使用，那么這代碼就容易出錯(cuò)，因?yàn)榭蛻?hù)端并不知道它們不兼容，也就會(huì)錯(cuò)誤地出現(xiàn)隨意組合。
下面就是我們要說(shuō)的產(chǎn)品族的概念，它代表了組成某個(gè)產(chǎn)品的一系列附件的集合：
當(dāng)涉及到這種產(chǎn)品族的問(wèn)題的時(shí)候，就需要抽象工廠模式來(lái)支持了。我們不再定義 CPU 工廠、主板工廠、硬盤(pán)工廠、顯示屏工廠等等，我們直接定義電腦工廠，每個(gè)電腦工廠負(fù)責(zé)生產(chǎn)所有的設(shè)備，這樣能保證肯定不存在兼容問(wèn)題。
這個(gè)時(shí)候，對(duì)于客戶(hù)端來(lái)說(shuō)，不再需要單獨(dú)挑選 CPU廠商、主板廠商、硬盤(pán)廠商等，直接選擇一家品牌工廠，品牌工廠會(huì)負(fù)責(zé)生產(chǎn)所有的東西，而且能保證肯定是兼容可用的。
public static void main(String[] args) {
// 第一步就要選定一個(gè)“大廠”
ComputerFactory cf = new AmdFactory();
// 從這個(gè)大廠造 CPU
CPU cpu = cf.makeCPU();
// 從這個(gè)大廠造主板
MainBoard board = cf.makeMainBoard();
// 從這個(gè)大廠造硬盤(pán)
HardDisk hardDisk = cf.makeHardDisk();
// 將同一個(gè)廠子出來(lái)的 CPU、主板、硬盤(pán)組裝在一起
Computer result = new Computer(cpu, board, hardDisk);
}
當(dāng)然，抽象工廠的問(wèn)題也是顯而易見(jiàn)的，比如我們要加個(gè)顯示器，就需要修改所有的工廠，給所有的工廠都加上制造顯示器的方法。這有點(diǎn)違反了對(duì)修改關(guān)閉，對(duì)擴(kuò)展開(kāi)放這個(gè)設(shè)計(jì)原則。
單例模式
單例模式用得最多，錯(cuò)得最多。
餓漢模式最簡(jiǎn)單：
public class Singleton {
// 首先，將 new Singleton() 堵死
private Singleton() {};
// 創(chuàng)建私有靜態(tài)實(shí)例，意味著這個(gè)類(lèi)第一次使用的時(shí)候就會(huì)進(jìn)行創(chuàng)建
private static Singleton instance = new Singleton();
public static Singleton getInstance() {
return instance;
}
// 瞎寫(xiě)一個(gè)靜態(tài)方法。這里想說(shuō)的是，如果我們只是要調(diào)用 Singleton.getDate(...)，
// 本來(lái)是不想要生成 Singleton 實(shí)例的，不過(guò)沒(méi)辦法，已經(jīng)生成了
public static Date getDate(String mode) {return new Date();}
}
很多人都能說(shuō)出餓漢模式的缺點(diǎn)，可是我覺(jué)得生產(chǎn)過(guò)程中，很少碰到這種情況：你定義了一個(gè)單例的類(lèi)，不需要其實(shí)例，可是你卻把一個(gè)或幾個(gè)你會(huì)用到的靜態(tài)方法塞到這個(gè)類(lèi)中。
飽漢模式最容易出錯(cuò)：
public class Singleton {
// 首先，也是先堵死 new Singleton() 這條路
private Singleton() {}
// 和餓漢模式相比，這邊不需要先實(shí)例化出來(lái)，注意這里的 volatile，它是必須的
private static volatile Singleton instance = null;
public static Singleton getInstance() {
if (instance == null) {
// 加鎖
synchronized (Singleton.class) {
// 這一次判斷也是必須的，不然會(huì)有并發(fā)問(wèn)題
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
雙重檢查，指的是兩次檢查 instance 是否為 null。
volatile 在這里是需要的，希望能引起讀者的關(guān)注。
很多人不知道怎么寫(xiě)，直接就在 getInstance() 方法簽名上加上 synchronized，這就不多說(shuō)了，性能太差。
嵌套類(lèi)最經(jīng)典，以后大家就用它吧：
public class Singleton3 {
private Singleton3() {}
// 主要是使用了 嵌套類(lèi)可以訪問(wèn)外部類(lèi)的靜態(tài)屬性和靜態(tài)方法 的特性
private static class Holder {
private static Singleton3 instance = new Singleton3();
}
public static Singleton3 getInstance() {
return Holder.instance;
}
}
注意，很多人都會(huì)把這個(gè)嵌套類(lèi)說(shuō)成是靜態(tài)內(nèi)部類(lèi)，嚴(yán)格地說(shuō)，內(nèi)部類(lèi)和嵌套類(lèi)是不一樣的，它們能訪問(wèn)的外部類(lèi)權(quán)限也是不一樣的。
最后，我們說(shuō)一下枚舉，枚舉很特殊，它在類(lèi)加載的時(shí)候會(huì)初始化里面的所有的實(shí)例，而且 JVM 保證了它們不會(huì)再被實(shí)例化，所以它天生就是單例的。
雖然我們平時(shí)很少看到用枚舉來(lái)實(shí)現(xiàn)單例，但是在 RxJava 的源碼中，有很多地方都用了枚舉來(lái)實(shí)現(xiàn)單例。
建造者模式
經(jīng)常碰見(jiàn)的 XxxBuilder 的類(lèi)，通常都是建造者模式的產(chǎn)物。建造者模式其實(shí)有很多的變種，但是對(duì)于客戶(hù)端來(lái)說(shuō)，我們的使用通常都是一個(gè)模式的：
Food food = new FoodBuilder().a().b().c().build();
Food food = Food.builder().a().b().c().build();
套路就是先 new 一個(gè) Builder，然后可以鏈?zhǔn)降卣{(diào)用一堆方法，最后再調(diào)用一次 build() 方法，我們需要的對(duì)象就有了。
來(lái)一個(gè)中規(guī)中矩的建造者模式：
class User {
// 下面是“一堆”的屬性
private String name;
private String password;
private String nickName;
private int age;
// 構(gòu)造方法私有化，不然客戶(hù)端就會(huì)直接調(diào)用構(gòu)造方法了
private User(String name, String password, String nickName, int age) {
this.name = name;
this.password = password;
this.nickName = nickName;
this.age = age;
}
// 靜態(tài)方法，用于生成一個(gè) Builder，這個(gè)不一定要有，不過(guò)寫(xiě)這個(gè)方法是一個(gè)很好的習(xí)慣，
// 有些代碼要求別人寫(xiě) new User.UserBuilder().a()...build() 看上去就沒(méi)那么好
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() {
}
// 鏈?zhǔn)秸{(diào)用設(shè)置各個(gè)屬性值，返回 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() 方法負(fù)責(zé)將 UserBuilder 中設(shè)置好的屬性“復(fù)制”到 User 中。
// 當(dāng)然，可以在 “復(fù)制” 之前做點(diǎn)檢驗(yàn)
public User build() {
if (name == null || password == null) {
throw new RuntimeException("用戶(hù)名和密碼必填");
}
if (age <= 0 || age >= 150) {
throw new RuntimeException("年齡不合法");
}
// 還可以做賦予”默認(rèn)值“的功能
if (nickName == null) {
nickName = name;
}
return new User(name, password, nickName, age);
}
}
}
核心是：先把所有的屬性都設(shè)置給 Builder，然后 build() 方法的時(shí)候，將這些屬性復(fù)制給實(shí)際產(chǎn)生的對(duì)象。
看看客戶(hù)端的調(diào)用：
public class APP {
public static void main(String[] args) {
User d = User.builder()
.name("foo")
.password("pAss12345")
.age(25)
.build();
}
}
說(shuō)實(shí)話，建造者模式的鏈?zhǔn)?/strong>寫(xiě)法很吸引人，但是，多寫(xiě)了很多“無(wú)用”的 builder 的代碼，感覺(jué)這個(gè)模式?jīng)]什么用。不過(guò)，當(dāng)屬性很多，而且有些必填，有些選填的時(shí)候，這個(gè)模式會(huì)使代碼清晰很多。我們可以在 Builder 的構(gòu)造方法中強(qiáng)制讓調(diào)用者提供必填字段，還有，在 build() 方法中校驗(yàn)各個(gè)參數(shù)比在 User 的構(gòu)造方法中校驗(yàn)，代碼要優(yōu)雅一些。
題外話，強(qiáng)烈建議讀者使用 lombok，用了 lombok 以后，上面的一大堆代碼會(huì)變成如下這樣:
@Builder
class User {
private String name;
private String password;
private String nickName;
private int age;
}
怎么樣，省下來(lái)的時(shí)間是不是又可以干點(diǎn)別的了。
當(dāng)然，如果你只是想要鏈?zhǔn)綄?xiě)法，不想要建造者模式，有個(gè)很簡(jiǎn)單的辦法，User 的 getter 方法不變，所有的 setter 方法都讓其 return this 就可以了，然后就可以像下面這樣調(diào)用：
User user = new User().setName("").setPassword("").setAge(20);
很多人是這么用的，但是筆者覺(jué)得其實(shí)這種寫(xiě)法非常地不優(yōu)雅，不是很推薦使用。
原型模式
這是我要說(shuō)的創(chuàng)建型模式的最后一個(gè)設(shè)計(jì)模式了。
原型模式很簡(jiǎn)單：有一個(gè)原型實(shí)例，基于這個(gè)原型實(shí)例產(chǎn)生新的實(shí)例，也就是“克隆”了。
Object 類(lèi)中有一個(gè) clone() 方法，它用于生成一個(gè)新的對(duì)象，當(dāng)然，如果我們要調(diào)用這個(gè)方法，java 要求我們的類(lèi)必須先實(shí)現(xiàn) Cloneable 接口，此接口沒(méi)有定義任何方法，但是不這么做的話，在 clone() 的時(shí)候，會(huì)拋出 CloneNotSupportedException 異常。
protected native Object clone() throws CloneNotSupportedException;
java 的克隆是淺克隆，碰到對(duì)象引用的時(shí)候，克隆出來(lái)的對(duì)象和原對(duì)象中的引用將指向同一個(gè)對(duì)象。通常實(shí)現(xiàn)深克隆的方法是將對(duì)象進(jìn)行序列化，然后再進(jìn)行反序列化。
原型模式了解到這里我覺(jué)得就夠了，各種變著法子說(shuō)這種代碼或那種代碼是原型模式，沒(méi)什么意義。
創(chuàng)建型模式總結(jié)
創(chuàng)建型模式總體上比較簡(jiǎn)單，它們的作用就是為了產(chǎn)生實(shí)例對(duì)象，算是各種工作的第一步了，因?yàn)槲覀儗?xiě)的是面向?qū)ο?/strong>的代碼，所以我們第一步當(dāng)然是需要?jiǎng)?chuàng)建一個(gè)對(duì)象了。
簡(jiǎn)單工廠模式最簡(jiǎn)單；工廠模式在簡(jiǎn)單工廠模式的基礎(chǔ)上增加了選擇工廠的維度，需要第一步選擇合適的工廠；抽象工廠模式有產(chǎn)品族的概念，如果各個(gè)產(chǎn)品是存在兼容性問(wèn)題的，就要用抽象工廠模式。單例模式就不說(shuō)了，為了保證全局使用的是同一對(duì)象，一方面是安全性考慮，一方面是為了節(jié)省資源；建造者模式專(zhuān)門(mén)對(duì)付屬性很多的那種類(lèi)，為了讓代碼更優(yōu)美；原型模式用得最少，了解和 Object 類(lèi)中的 clone() 方法相關(guān)的知識(shí)即可。
結(jié)構(gòu)型模式
前面創(chuàng)建型模式介紹了創(chuàng)建對(duì)象的一些設(shè)計(jì)模式，這節(jié)介紹的結(jié)構(gòu)型模式旨在通過(guò)改變代碼結(jié)構(gòu)來(lái)達(dá)到解耦的目的，使得我們的代碼容易維護(hù)和擴(kuò)展。
代理模式
第一個(gè)要介紹的代理模式是最常使用的模式之一了，用一個(gè)代理來(lái)隱藏具體實(shí)現(xiàn)類(lèi)的實(shí)現(xiàn)細(xì)節(jié)，通常還用于在真實(shí)的實(shí)現(xiàn)的前后添加一部分邏輯。
既然說(shuō)是代理，那就要對(duì)客戶(hù)端隱藏真實(shí)實(shí)現(xiàn)，由代理來(lái)負(fù)責(zé)客戶(hù)端的所有請(qǐng)求。當(dāng)然，代理只是個(gè)代理，它不會(huì)完成實(shí)際的業(yè)務(wù)邏輯，而是一層皮而已，但是對(duì)于客戶(hù)端來(lái)說(shuō)，它必須表現(xiàn)得就是客戶(hù)端需要的真實(shí)實(shí)現(xiàn)。
理解代理這個(gè)詞，這個(gè)模式其實(shí)就簡(jiǎn)單了。
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;
}
}
// 代理要表現(xiàn)得“就像是”真實(shí)實(shí)現(xiàn)類(lèi)，所以需要實(shí)現(xiàn) FoodService
public class FoodServiceProxy implements FoodService {
// 內(nèi)部一定要有一個(gè)真實(shí)的實(shí)現(xiàn)類(lèi)，當(dāng)然也可以通過(guò)構(gòu)造方法注入
private FoodService foodService = new FoodServiceImpl();
public Food makeChicken() {
System.out.println("我們馬上要開(kāi)始制作雞肉了");
// 如果我們定義這句為核心代碼的話，那么，核心代碼是真實(shí)實(shí)現(xiàn)類(lèi)做的，
// 代理只是在核心代碼前后做些“無(wú)足輕重”的事情
Food food = foodService.makeChicken();
System.out.println("雞肉制作完成啦，加點(diǎn)胡椒粉"); // 增強(qiáng)
food.addCondiment("pepper");
return food;
}
public Food makeNoodle() {
System.out.println("準(zhǔn)備制作拉面~");
Food food = foodService.makeNoodle();
System.out.println("制作完成啦")
return food;
}
}
客戶(hù)端調(diào)用，注意，我們要用代理來(lái)實(shí)例化接口：
// 這里用代理類(lèi)來(lái)實(shí)例化
FoodService foodService = new FoodServiceProxy();
foodService.makeChicken();
我們發(fā)現(xiàn)沒(méi)有，代理模式說(shuō)白了就是做 “方法包裝” 或做 “方法增強(qiáng)”。在面向切面編程中，其實(shí)就是動(dòng)態(tài)代理的過(guò)程。比如 Spring 中，我們自己不定義代理類(lèi)，但是 Spring 會(huì)幫我們動(dòng)態(tài)來(lái)定義代理，然后把我們定義在 @Before、@After、@Around 中的代碼邏輯動(dòng)態(tài)添加到代理中。
說(shuō)到動(dòng)態(tài)代理，又可以展開(kāi)說(shuō)，Spring 中實(shí)現(xiàn)動(dòng)態(tài)代理有兩種，一種是如果我們的類(lèi)定義了接口，如 UserService 接口和 UserServiceImpl 實(shí)現(xiàn)，那么采用 JDK 的動(dòng)態(tài)代理，感興趣的讀者可以去看看 java.lang.reflect.Proxy 類(lèi)的源碼；另一種是我們自己沒(méi)有定義接口的，Spring 會(huì)采用 CGLIB 進(jìn)行動(dòng)態(tài)代理，它是一個(gè) jar 包，性能還不錯(cuò)。
適配器模式
說(shuō)完代理模式，說(shuō)適配器模式，是因?yàn)樗鼈兒芟嗨疲@里可以做個(gè)比較。
適配器模式做的就是，有一個(gè)接口需要實(shí)現(xiàn)，但是我們現(xiàn)成的對(duì)象都不滿(mǎn)足，需要加一層適配器來(lái)進(jìn)行適配。
適配器模式總體來(lái)說(shuō)分三種：默認(rèn)適配器模式、對(duì)象適配器模式、類(lèi)適配器模式。先不急著分清楚這幾個(gè)，先看看例子再說(shuō)。
默認(rèn)適配器模式
首先，我們先看看最簡(jiǎn)單的適配器模式**默認(rèn)適配器模式(Default Adapter)**是怎么樣的。
我們用 Appache commons-io 包中的 FileAlterationListener 做例子，此接口定義了很多的方法，用于對(duì)文件或文件夾進(jìn)行監(jiān)控，一旦發(fā)生了對(duì)應(yīng)的操作，就會(huì)觸發(fā)相應(yīng)的方法。
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);
}
此接口的一大問(wèn)題是抽象方法太多了，如果我們要用這個(gè)接口，意味著我們要實(shí)現(xiàn)每一個(gè)抽象方法，如果我們只是想要監(jiān)控文件夾中的文件創(chuàng)建和文件刪除事件，可是我們還是不得不實(shí)現(xiàn)所有的方法，很明顯，這不是我們想要的。
關(guān)注公眾號(hào)：Java后端編程，后臺(tái)回復(fù)：Java，獲取學(xué)習(xí)視頻。
所以，我們需要下面的一個(gè)適配器，它用于實(shí)現(xiàn)上面的接口，但是所有的方法都是空方法，這樣，我們就可以轉(zhuǎn)而定義自己的類(lèi)來(lái)繼承下面這個(gè)類(lèi)即可。
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) {
}
}
比如我們可以定義以下類(lèi)，我們僅僅需要實(shí)現(xiàn)我們想實(shí)現(xiàn)的方法就可以了：
public class FileMonitor extends FileAlterationListenerAdaptor {
public void onFileCreate(final File file) {
// 文件創(chuàng)建
doSomething();
}
public void onFileDelete(final File file) {
// 文件刪除
doSomething();
}
}
當(dāng)然，上面說(shuō)的只是適配器模式的其中一種，也是最簡(jiǎn)單的一種，無(wú)需多言。下面，再介紹**“正統(tǒng)的”**適配器模式。
對(duì)象適配器模式
來(lái)看一個(gè)《Head First 設(shè)計(jì)模式》中的一個(gè)例子，我稍微修改了一下，看看怎么將雞適配成鴨，這樣雞也能當(dāng)鴨來(lái)用。因?yàn)椋F(xiàn)在鴨這個(gè)接口，我們沒(méi)有合適的實(shí)現(xiàn)類(lèi)可以用，所以需要適配器。
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("雞也會(huì)飛哦");
}
}
鴨接口有 fly() 和 quare() 兩個(gè)方法，雞 Cock 如果要冒充鴨，fly() 方法是現(xiàn)成的，但是雞不會(huì)鴨的呱呱叫，沒(méi)有 quack() 方法。這個(gè)時(shí)候就需要適配了：
// 毫無(wú)疑問(wèn)，首先，這個(gè)適配器肯定需要 implements Duck，這樣才能當(dāng)做鴨來(lái)用
public class CockAdapter implements Duck {
Cock cock;
// 構(gòu)造方法中需要一個(gè)雞的實(shí)例，此類(lèi)就是將這只雞適配成鴨來(lái)用
public CockAdapter(Cock cock) {
this.cock = cock;
}
// 實(shí)現(xiàn)鴨的呱呱叫方法
@Override
public void quack() {
// 內(nèi)部其實(shí)是一只雞的咕咕叫
cock.gobble();
}
@Override
public void fly() {
cock.fly();
}
}
客戶(hù)端調(diào)用很簡(jiǎn)單了：
public static void main(String[] args) {
// 有一只野雞
Cock wildCock = new WildCock();
// 成功將野雞適配成鴨
Duck duck = new CockAdapter(wildCock);
...
}
到這里，大家也就知道了適配器模式是怎么回事了。無(wú)非是我們需要一只鴨，但是我們只有一只雞，這個(gè)時(shí)候就需要定義一個(gè)適配器，由這個(gè)適配器來(lái)充當(dāng)鴨，但是適配器里面的方法還是由雞來(lái)實(shí)現(xiàn)的。
我們用一個(gè)圖來(lái)簡(jiǎn)單說(shuō)明下：
上圖應(yīng)該還是很容易理解的，我就不做更多的解釋了。下面，我們看看類(lèi)適配模式怎么樣的。
類(lèi)適配器模式
廢話少說(shuō)，直接上圖：
看到這個(gè)圖，大家應(yīng)該很容易理解的吧，通過(guò)繼承的方法，適配器自動(dòng)獲得了所需要的大部分方法。這個(gè)時(shí)候，客戶(hù)端使用更加簡(jiǎn)單，直接 Target t = new SomeAdapter(); 就可以了。
適配器模式總結(jié)
類(lèi)適配和對(duì)象適配的異同
一個(gè)采用繼承，一個(gè)采用組合；
類(lèi)適配屬于靜態(tài)實(shí)現(xiàn)，對(duì)象適配屬于組合的動(dòng)態(tài)實(shí)現(xiàn)，對(duì)象適配需要多實(shí)例化一個(gè)對(duì)象。
總體來(lái)說(shuō)，對(duì)象適配用得比較多。
適配器模式和代理模式的異同
比較這兩種模式，其實(shí)是比較對(duì)象適配器模式和代理模式，在代碼結(jié)構(gòu)上，它們很相似，都需要一個(gè)具體的實(shí)現(xiàn)類(lèi)的實(shí)例。但是它們的目的不一樣，代理模式做的是增強(qiáng)原方法的活；適配器做的是適配的活，為的是提供“把雞包裝成鴨，然后當(dāng)做鴨來(lái)使用”，而雞和鴨它們之間原本沒(méi)有繼承關(guān)系。
橋梁模式
理解橋梁模式，其實(shí)就是理解代碼抽象和解耦。
我們首先需要一個(gè)橋梁，它是一個(gè)接口，定義提供的接口方法。
public interface DrawAPI {
public void draw(int radius, int x, int y);
}
然后是一系列實(shí)現(xiàn)類(lèi)：
public class RedPen implements DrawAPI {
@Override
public void draw(int radius, int x, int y) {
System.out.println("用紅色筆畫(huà)圖，radius:" + radius + ", x:" + x + ", y:" + y);
}
}
public class GreenPen implements DrawAPI {
@Override
public void draw(int radius, int x, int y) {
System.out.println("用綠色筆畫(huà)圖，radius:" + radius + ", x:" + x + ", y:" + y);
}
}
public class BluePen implements DrawAPI {
@Override
public void draw(int radius, int x, int y) {
System.out.println("用藍(lán)色筆畫(huà)圖，radius:" + radius + ", x:" + x + ", y:" + y);
}
}
定義一個(gè)抽象類(lèi)，此類(lèi)的實(shí)現(xiàn)類(lèi)都需要使用 DrawAPI：
public abstract class Shape {
protected DrawAPI drawAPI;
protected Shape(DrawAPI drawAPI) {
this.drawAPI = drawAPI;
}
public abstract void draw();
}
定義抽象類(lèi)的子類(lèi)：
// 圓形
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);
}
}
// 長(zhǎng)方形
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);
}
}
最后，我們來(lái)看客戶(hù)端演示：
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();
}
可能大家看上面一步步還不是特別清晰，我把所有的東西整合到一張圖上：
這回大家應(yīng)該就知道抽象在哪里，怎么解耦了吧。橋梁模式的優(yōu)點(diǎn)也是顯而易見(jiàn)的，就是非常容易進(jìn)行擴(kuò)展。
本節(jié)引用了這里的例子，并對(duì)其進(jìn)行了修改。
裝飾模式
要把裝飾模式說(shuō)清楚明白，不是件容易的事情。也許讀者知道 Java IO 中的幾個(gè)類(lèi)是典型的裝飾模式的應(yīng)用，但是讀者不一定清楚其中的關(guān)系，也許看完就忘了，希望看完這節(jié)后，讀者可以對(duì)其有更深的感悟。
首先，我們先看一個(gè)簡(jiǎn)單的圖，看這個(gè)圖的時(shí)候，了解下層次結(jié)構(gòu)就可以了：
我們來(lái)說(shuō)說(shuō)裝飾模式的出發(fā)點(diǎn)，從圖中可以看到，接口 Component 其實(shí)已經(jīng)有了 ConcreteComponentA 和 ConcreteComponentB 兩個(gè)實(shí)現(xiàn)類(lèi)了，但是，如果我們要增強(qiáng)這兩個(gè)實(shí)現(xiàn)類(lèi)的話，我們就可以采用裝飾模式，用具體的裝飾器來(lái)裝飾實(shí)現(xiàn)類(lèi)，以達(dá)到增強(qiáng)的目的。
從名字來(lái)簡(jiǎn)單解釋下裝飾器。既然說(shuō)是裝飾，那么往往就是添加小功能這種，而且，我們要滿(mǎn)足可以添加多個(gè)小功能。最簡(jiǎn)單的，代理模式就可以實(shí)現(xiàn)功能的增強(qiáng)，但是代理不容易實(shí)現(xiàn)多個(gè)功能的增強(qiáng)，當(dāng)然你可以說(shuō)用代理包裝代理的多層包裝方式，但是那樣的話代碼就復(fù)雜了。
首先明白一些簡(jiǎn)單的概念，從圖中我們看到，所有的具體裝飾者們 ConcreteDecorator* 都可以作為 Component 來(lái)使用，因?yàn)樗鼈兌紝?shí)現(xiàn)了 Component 中的所有接口。它們和 Component 實(shí)現(xiàn)類(lèi) ConcreteComponent* 的區(qū)別是，它們只是裝飾者，起裝飾作用，也就是即使它們看上去牛逼轟轟，但是它們都只是在具體的實(shí)現(xiàn)中加了層皮來(lái)裝飾而已。
注意這段話中混雜在各個(gè)名詞中的 Component 和 Decorator，別搞混了。
下面來(lái)看看一個(gè)例子，先把裝飾模式弄清楚，然后再介紹下 java io 中的裝飾模式的應(yīng)用。
最近大街上流行起來(lái)了“快樂(lè)檸檬”，我們把快樂(lè)檸檬的飲料分為三類(lèi)：紅茶、綠茶、咖啡，在這三大類(lèi)的基礎(chǔ)上，又增加了許多的口味，什么金桔檸檬紅茶、金桔檸檬珍珠綠茶、芒果紅茶、芒果綠茶、芒果珍珠紅茶、烤珍珠紅茶、烤珍珠芒果綠茶、椰香胚芽咖啡、焦糖可可咖啡等等，每家店都有很長(zhǎng)的菜單，但是仔細(xì)看下，其實(shí)原料也沒(méi)幾樣，但是可以搭配出很多組合，如果顧客需要，很多沒(méi)出現(xiàn)在菜單中的飲料他們也是可以做的。
在這個(gè)例子中，紅茶、綠茶、咖啡是最基礎(chǔ)的飲料，其他的像金桔檸檬、芒果、珍珠、椰果、焦糖等都屬于裝飾用的。當(dāng)然，在開(kāi)發(fā)中，我們確實(shí)可以像門(mén)店一樣，開(kāi)發(fā)這些類(lèi)：LemonBlackTea、LemonGreenTea、MangoBlackTea、MangoLemonGreenTea......但是，很快我們就發(fā)現(xiàn)，這樣子干肯定是不行的，這會(huì)導(dǎo)致我們需要組合出所有的可能，而且如果客人需要在紅茶中加雙份檸檬怎么辦？三份檸檬怎么辦？
不說(shuō)廢話了，上代碼。
首先，定義飲料抽象基類(lèi)：
public abstract class Beverage {
// 返回描述
public abstract String getDescription();
// 返回價(jià)格
public abstract double cost();
}
然后是三個(gè)基礎(chǔ)飲料實(shí)現(xiàn)類(lèi)，紅茶、綠茶和咖啡：
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;
}
}
...// 咖啡省略
定義調(diào)料，也就是裝飾者的基類(lèi)，此類(lèi)必須繼承自 Beverage：
// 調(diào)料
public abstract class Condiment extends Beverage {
}
然后我們來(lái)定義檸檬、芒果等具體的調(diào)料，它們屬于裝飾者，毫無(wú)疑問(wèn)，這些調(diào)料肯定都需要繼承調(diào)料 Condiment 類(lèi)：
public class Lemon extends Condiment {
private Beverage bevarage;
// 這里很關(guān)鍵，需要傳入具體的飲料，如需要傳入沒(méi)有被裝飾的紅茶或綠茶，
// 當(dāng)然也可以傳入已經(jīng)裝飾好的芒果綠茶，這樣可以做芒果檸檬綠茶
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 元
}
}
...// 給每一種調(diào)料都加一個(gè)類(lèi)
看客戶(hù)端調(diào)用：
public static void main(String[] args) {
// 首先，我們需要一個(gè)基礎(chǔ)飲料，紅茶、綠茶或咖啡
Beverage beverage = new GreenTea();
// 開(kāi)始裝飾
beverage = new Lemon(beverage); // 先加一份檸檬
beverage = new Mongo(beverage); // 再加一份芒果
System.out.println(beverage.getDescription() + " 價(jià)格：￥" + beverage.cost());
//"綠茶, 加檸檬, 加芒果 價(jià)格：￥16"
}
如果我們需要 芒果-珍珠-雙份檸檬-紅茶：
Beverage beverage = new Mongo(new Pearl(new Lemon(new Lemon(new BlackTea()))));
是不是很變態(tài)？
看看下圖可能會(huì)清晰一些：
到這里，大家應(yīng)該已經(jīng)清楚裝飾模式了吧。
下面，我們?cè)賮?lái)說(shuō)說(shuō) java IO 中的裝飾模式。看下圖 InputStream 派生出來(lái)的部分類(lèi)：
我們知道 InputStream 代表了輸入流，具體的輸入來(lái)源可以是文件（FileInputStream）、管道（PipedInputStream）、數(shù)組（ByteArrayInputStream）等，這些就像前面奶茶的例子中的紅茶、綠茶，屬于基礎(chǔ)輸入流。
FilterInputStream 承接了裝飾模式的關(guān)鍵節(jié)點(diǎn)，它的實(shí)現(xiàn)類(lèi)是一系列裝飾器，比如 BufferedInputStream 代表用緩沖來(lái)裝飾，也就使得輸入流具有了緩沖的功能，LineNumberInputStream 代表用行號(hào)來(lái)裝飾，在操作的時(shí)候就可以取得行號(hào)了，DataInputStream 的裝飾，使得我們可以從輸入流轉(zhuǎn)換為 java 中的基本類(lèi)型值。
當(dāng)然，在 java IO 中，如果我們使用裝飾器的話，就不太適合面向接口編程了，如：
InputStream inputStream = new LineNumberInputStream(new BufferedInputStream(new FileInputStream("")));
這樣的結(jié)果是，InputStream 還是不具有讀取行號(hào)的功能，因?yàn)樽x取行號(hào)的方法定義在 LineNumberInputStream 類(lèi)中。
我們應(yīng)該像下面這樣使用：
DataInputStream is = new DataInputStream(
new BufferedInputStream(
new FileInputStream("")));
所以說(shuō)嘛，要找到純的嚴(yán)格符合設(shè)計(jì)模式的代碼還是比較難的。
門(mén)面模式
門(mén)面模式（也叫外觀模式，F(xiàn)acade Pattern）在許多源碼中有使用，比如 slf4j 就可以理解為是門(mén)面模式的應(yīng)用。這是一個(gè)簡(jiǎn)單的設(shè)計(jì)模式，我們直接上代碼再說(shuō)吧。
首先，我們定義一個(gè)接口：
public interface Shape {
void draw();
}
定義幾個(gè)實(shí)現(xiàn)類(lèi)：
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()");
}
}
客戶(hù)端調(diào)用：
public static void main(String[] args) {
// 畫(huà)一個(gè)圓形
Shape circle = new Circle();
circle.draw();
// 畫(huà)一個(gè)長(zhǎng)方形
Shape rectangle = new Rectangle();
rectangle.draw();
}
以上是我們常寫(xiě)的代碼，我們需要畫(huà)圓就要先實(shí)例化圓，畫(huà)長(zhǎng)方形就需要先實(shí)例化一個(gè)長(zhǎng)方形，然后再調(diào)用相應(yīng)的 draw() 方法。
下面，我們看看怎么用門(mén)面模式來(lái)讓客戶(hù)端調(diào)用更加友好一些。
我們先定義一個(gè)門(mén)面：
public class ShapeMaker {
private Shape circle;
private Shape rectangle;
private Shape square;
public ShapeMaker() {
circle = new Circle();
rectangle = new Rectangle();
square = new Square();
}
/**
* 下面定義一堆方法，具體應(yīng)該調(diào)用什么方法，由這個(gè)門(mén)面來(lái)決定
*/
public void drawCircle(){
circle.draw();
}
public void drawRectangle(){
rectangle.draw();
}
public void drawSquare(){
square.draw();
}
}
看看現(xiàn)在客戶(hù)端怎么調(diào)用：
public static void main(String[] args) {
ShapeMaker shapeMaker = new ShapeMaker();
// 客戶(hù)端調(diào)用現(xiàn)在更加清晰了
shapeMaker.drawCircle();
shapeMaker.drawRectangle();
shapeMaker.drawSquare();
}
門(mén)面模式的優(yōu)點(diǎn)顯而易見(jiàn)，客戶(hù)端不再需要關(guān)注實(shí)例化時(shí)應(yīng)該使用哪個(gè)實(shí)現(xiàn)類(lèi)，直接調(diào)用門(mén)面提供的方法就可以了，因?yàn)殚T(mén)面類(lèi)提供的方法的方法名對(duì)于客戶(hù)端來(lái)說(shuō)已經(jīng)很友好了。
組合模式
組合模式用于表示具有層次結(jié)構(gòu)的數(shù)據(jù)，使得我們對(duì)單個(gè)對(duì)象和組合對(duì)象的訪問(wèn)具有一致性。
直接看一個(gè)例子吧，每個(gè)員工都有姓名、部門(mén)、薪水這些屬性，同時(shí)還有下屬員工集合（雖然可能集合為空），而下屬員工和自己的結(jié)構(gòu)是一樣的，也有姓名、部門(mén)這些屬性，同時(shí)也有他們的下屬員工集合。
public class Employee {
private String name;
private String dept;
private int salary;
private List subordinates; // 下屬
public Employee(String name,String dept, int sal) {
this.name = name;
this.dept = dept;
this.salary = sal;
subordinates = new ArrayList();
}
public void add(Employee e) {
subordinates.add(e);
}
public void remove(Employee e) {
subordinates.remove(e);
}
public List getSubordinates() {
return subordinates;
}
public String toString(){
return ("Employee :[ Name : " + name + ", dept : " + dept + ", salary :" + salary+" ]");
}
}
通常，這種類(lèi)需要定義 add(node)、remove(node)、getChildren() 這些方法。
這說(shuō)的其實(shí)就是組合模式，這種簡(jiǎn)單的模式我就不做過(guò)多介紹了，相信各位讀者也不喜歡看我寫(xiě)廢話。
享元模式
英文是 Flyweight Pattern，不知道是誰(shuí)最先翻譯的這個(gè)詞，感覺(jué)這翻譯真的不好理解，我們?cè)囍鴱?qiáng)行關(guān)聯(lián)起來(lái)吧。Flyweight 是輕量級(jí)的意思，享元分開(kāi)來(lái)說(shuō)就是 共享 元器件，也就是復(fù)用已經(jīng)生成的對(duì)象，這種做法當(dāng)然也就是輕量級(jí)的了。
復(fù)用對(duì)象最簡(jiǎn)單的方式是，用一個(gè) HashMap 來(lái)存放每次新生成的對(duì)象。每次需要一個(gè)對(duì)象的時(shí)候，先到 HashMap 中看看有沒(méi)有，如果沒(méi)有，再生成新的對(duì)象，然后將這個(gè)對(duì)象放入 HashMap 中。
這種簡(jiǎn)單的代碼我就不演示了。
結(jié)構(gòu)型模式總結(jié)
前面，我們說(shuō)了代理模式、適配器模式、橋梁模式、裝飾模式、門(mén)面模式、組合模式和享元模式。讀者是否可以分別把這幾個(gè)模式說(shuō)清楚了呢？在說(shuō)到這些模式的時(shí)候，心中是否有一個(gè)清晰的圖或處理流程在腦海里呢？
代理模式是做方法增強(qiáng)的，適配器模式是把雞包裝成鴨這種用來(lái)適配接口的，橋梁模式做到了很好的解耦，裝飾模式從名字上就看得出來(lái)，適合于裝飾類(lèi)或者說(shuō)是增強(qiáng)類(lèi)的場(chǎng)景，門(mén)面模式的優(yōu)點(diǎn)是客戶(hù)端不需要關(guān)心實(shí)例化過(guò)程，只要調(diào)用需要的方法即可，組合模式用于描述具有層次結(jié)構(gòu)的數(shù)據(jù)，享元模式是為了在特定的場(chǎng)景中緩存已經(jīng)創(chuàng)建的對(duì)象，用于提高性能。
行為型模式
行為型模式關(guān)注的是各個(gè)類(lèi)之間的相互作用，將職責(zé)劃分清楚，使得我們的代碼更加地清晰。
策略模式
策略模式太常用了，所以把它放到最前面進(jìn)行介紹。它比較簡(jiǎn)單，我就不廢話，直接用代碼說(shuō)事吧。
下面設(shè)計(jì)的場(chǎng)景是，我們需要畫(huà)一個(gè)圖形，可選的策略就是用紅色筆來(lái)畫(huà)，還是綠色筆來(lái)畫(huà)，或者藍(lán)色筆來(lái)畫(huà)。
首先，先定義一個(gè)策略接口：
public interface Strategy {
public void draw(int radius, int x, int y);
}
然后我們定義具體的幾個(gè)策略：
public class RedPen implements Strategy {
@Override
public void draw(int radius, int x, int y) {
System.out.println("用紅色筆畫(huà)圖，radius:" + radius + ", x:" + x + ", y:" + y);
}
}
public class GreenPen implements Strategy {
@Override
public void draw(int radius, int x, int y) {
System.out.println("用綠色筆畫(huà)圖，radius:" + radius + ", x:" + x + ", y:" + y);
}
}
public class BluePen implements Strategy {
@Override
public void draw(int radius, int x, int y) {
System.out.println("用藍(lán)色筆畫(huà)圖，radius:" + radius + ", x:" + x + ", y:" + y);
}
}
使用策略的類(lèi)：
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);
}
}
客戶(hù)端演示：
public static void main(String[] args) {
Context context = new Context(new BluePen()); // 使用綠色筆來(lái)畫(huà)
context.executeDraw(10, 0, 0);
}
放到一張圖上，讓大家看得清晰些：
這個(gè)時(shí)候，大家有沒(méi)有聯(lián)想到結(jié)構(gòu)型模式中的橋梁模式，它們其實(shí)非常相似，我把橋梁模式的圖拿過(guò)來(lái)大家對(duì)比下：
要我說(shuō)的話，它們非常相似，橋梁模式在左側(cè)加了一層抽象而已。橋梁模式的耦合更低，結(jié)構(gòu)更復(fù)雜一些。
觀察者模式
觀察者模式對(duì)于我們來(lái)說(shuō)，真是再簡(jiǎn)單不過(guò)了。無(wú)外乎兩個(gè)操作，觀察者訂閱自己關(guān)心的主題和主題有數(shù)據(jù)變化后通知觀察者們。
首先，需要定義主題，每個(gè)主題需要持有觀察者列表的引用，用于在數(shù)據(jù)變更的時(shí)候通知各個(gè)觀察者：
public class Subject {
private List observers = new ArrayList();
private int state;
public int getState() {
return state;
}
public void setState(int state) {
this.state = state;
// 數(shù)據(jù)已變更，通知觀察者們
notifyAllObservers();
}
// 注冊(cè)觀察者
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();
}
其實(shí)如果只有一個(gè)觀察者類(lèi)的話，接口都不用定義了，不過(guò)，通常場(chǎng)景下，既然用到了觀察者模式，我們就是希望一個(gè)事件出來(lái)了，會(huì)有多個(gè)不同的類(lèi)需要處理相應(yīng)的信息。比如，訂單修改成功事件，我們希望發(fā)短信的類(lèi)得到通知、發(fā)郵件的類(lèi)得到通知、處理物流信息的類(lèi)得到通知等。
我們來(lái)定義具體的幾個(gè)觀察者類(lèi)：
public class BinaryObserver extends Observer {
// 在構(gòu)造方法中進(jìn)行訂閱主題
public BinaryObserver(Subject subject) {
this.subject = subject;
// 通常在構(gòu)造方法中將 this 發(fā)布出去的操作一定要小心
this.subject.attach(this);
}
// 該方法由主題類(lèi)在數(shù)據(jù)變更的時(shí)候進(jìn)行調(diào)用
@Override
public void update() {
String result = Integer.toBinaryString(subject.getState());
System.out.println("訂閱的數(shù)據(jù)發(fā)生變化，新的數(shù)據(jù)處理為二進(jìn)制值為：" + 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("訂閱的數(shù)據(jù)發(fā)生變化，新的數(shù)據(jù)處理為十六進(jìn)制值為：" + result);
}
}
客戶(hù)端使用也非常簡(jiǎn)單：
public static void main(String[] args) {
// 先定義一個(gè)主題
Subject subject1 = new Subject();
// 定義觀察者
new BinaryObserver(subject1);
new HexaObserver(subject1);
// 模擬數(shù)據(jù)變更，這個(gè)時(shí)候，觀察者們的 update 方法將會(huì)被調(diào)用
subject.setState(11);
}
output:
訂閱的數(shù)據(jù)發(fā)生變化，新的數(shù)據(jù)處理為二進(jìn)制值為：1011
訂閱的數(shù)據(jù)發(fā)生變化，新的數(shù)據(jù)處理為十六進(jìn)制值為：B
當(dāng)然，jdk 也提供了相似的支持，具體的大家可以參考 java.util.Observable 和 java.util.Observer 這兩個(gè)類(lèi)。
實(shí)際生產(chǎn)過(guò)程中，觀察者模式往往用消息中間件來(lái)實(shí)現(xiàn)，如果要實(shí)現(xiàn)單機(jī)觀察者模式，筆者建議讀者使用 Guava 中的 EventBus，它有同步實(shí)現(xiàn)也有異步實(shí)現(xiàn)，本文主要介紹設(shè)計(jì)模式，就不展開(kāi)說(shuō)了。
還有，即使是上面的這個(gè)代碼，也會(huì)有很多變種，大家只要記住核心的部分，那就是一定有一個(gè)地方存放了所有的觀察者，然后在事件發(fā)生的時(shí)候，遍歷觀察者，調(diào)用它們的回調(diào)函數(shù)。
責(zé)任鏈模式
責(zé)任鏈通常需要先建立一個(gè)單向鏈表，然后調(diào)用方只需要調(diào)用頭部節(jié)點(diǎn)就可以了，后面會(huì)自動(dòng)流轉(zhuǎn)下去。比如流程審批就是一個(gè)很好的例子，只要終端用戶(hù)提交申請(qǐng)，根據(jù)申請(qǐng)的內(nèi)容信息，自動(dòng)建立一條責(zé)任鏈，然后就可以開(kāi)始流轉(zhuǎn)了。
有這么一個(gè)場(chǎng)景，用戶(hù)參加一個(gè)活動(dòng)可以領(lǐng)取獎(jiǎng)品，但是活動(dòng)需要進(jìn)行很多的規(guī)則校驗(yàn)然后才能放行，比如首先需要校驗(yàn)用戶(hù)是否是新用戶(hù)、今日參與人數(shù)是否有限額、全場(chǎng)參與人數(shù)是否有限額等等。設(shè)定的規(guī)則都通過(guò)后，才能讓用戶(hù)領(lǐng)走獎(jiǎng)品。
如果產(chǎn)品給你這個(gè)需求的話，我想大部分人一開(kāi)始肯定想的就是，用一個(gè) List 來(lái)存放所有的規(guī)則，然后 foreach 執(zhí)行一下每個(gè)規(guī)則就好了。不過(guò)，讀者也先別急，看看責(zé)任鏈模式和我們說(shuō)的這個(gè)有什么不一樣？
首先，我們要定義流程上節(jié)點(diǎn)的基類(lèi)：
public abstract class RuleHandler {
// 后繼節(jié)點(diǎn)
protected RuleHandler successor;
public abstract void apply(Context context);
public void setSuccessor(RuleHandler successor) {
this.successor = successor;
}
public RuleHandler getSuccessor() {
return successor;
}
}
接下來(lái)，我們需要定義具體的每個(gè)節(jié)點(diǎn)了。
校驗(yàn)用戶(hù)是否是新用戶(hù)：
public class NewUserRuleHandler extends RuleHandler {
public void apply(Context context) {
if (context.isNewUser()) {
// 如果有后繼節(jié)點(diǎn)的話，傳遞下去
if (this.getSuccessor() != null) {
this.getSuccessor().apply(context);
}
} else {
throw new RuntimeException("該活動(dòng)僅限新用戶(hù)參與");
}
}
}
校驗(yàn)用戶(hù)所在地區(qū)是否可以參與：
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("非常抱歉，您所在的地區(qū)無(wú)法參與本次活動(dòng)");
}
}
}
校驗(yàn)獎(jiǎng)品是否已領(lǐng)完：
public class LimitRuleHandler extends RuleHandler {
public void apply(Context context) {
int remainedTimes = activityService.queryRemainedTimes(context); // 查詢(xún)剩余獎(jiǎng)品
if (remainedTimes > 0) {
if (this.getSuccessor() != null) {
this.getSuccessor().apply(userInfo);
}
} else {
throw new RuntimeException("您來(lái)得太晚了，獎(jiǎng)品被領(lǐng)完了");
}
}
}
客戶(hù)端：
public static void main(String[] args) {
RuleHandler newUserHandler = new NewUserRuleHandler();
RuleHandler locationHandler = new LocationRuleHandler();
RuleHandler limitHandler = new LimitRuleHandler();
// 假設(shè)本次活動(dòng)僅校驗(yàn)地區(qū)和獎(jiǎng)品數(shù)量，不校驗(yàn)新老用戶(hù)
locationHandler.setSuccessor(limitHandler);
locationHandler.apply(context);
}
代碼其實(shí)很簡(jiǎn)單，就是先定義好一個(gè)鏈表，然后在通過(guò)任意一節(jié)點(diǎn)后，如果此節(jié)點(diǎn)有后繼節(jié)點(diǎn)，那么傳遞下去。
至于它和我們前面說(shuō)的用一個(gè) List 存放需要執(zhí)行的規(guī)則的做法有什么異同，留給讀者自己琢磨吧。
模板方法模式
在含有繼承結(jié)構(gòu)的代碼中，模板方法模式是非常常用的。
通常會(huì)有一個(gè)抽象類(lèi)：
public abstract class AbstractTemplate {
// 這就是模板方法
public void templateMethod() {
init();
apply(); // 這個(gè)是重點(diǎn)
end(); // 可以作為鉤子方法
}
protected void init() {
System.out.println("init 抽象層已經(jīng)實(shí)現(xiàn)，子類(lèi)也可以選擇覆寫(xiě)");
}
// 留給子類(lèi)實(shí)現(xiàn)
protected abstract void apply();
protected void end() {
}
}
模板方法中調(diào)用了 3 個(gè)方法，其中 apply() 是抽象方法，子類(lèi)必須實(shí)現(xiàn)它，其實(shí)模板方法中有幾個(gè)抽象方法完全是自由的，我們也可以將三個(gè)方法都設(shè)置為抽象方法，讓子類(lèi)來(lái)實(shí)現(xiàn)。也就是說(shuō)，模板方法只負(fù)責(zé)定義第一步應(yīng)該要做什么，第二步應(yīng)該做什么，第三步應(yīng)該做什么，至于怎么做，由子類(lèi)來(lái)實(shí)現(xiàn)。
我們寫(xiě)一個(gè)實(shí)現(xiàn)類(lèi)：
public class ConcreteTemplate extends AbstractTemplate {
public void apply() {
System.out.println("子類(lèi)實(shí)現(xiàn)抽象方法 apply");
}
public void end() {
System.out.println("我們可以把 method3 當(dāng)做鉤子方法來(lái)使用，需要的時(shí)候覆寫(xiě)就可以了");
}
}
客戶(hù)端調(diào)用演示：
public static void main(String[] args) {
AbstractTemplate t = new ConcreteTemplate();
// 調(diào)用模板方法
t.templateMethod();
}
代碼其實(shí)很簡(jiǎn)單，基本上看到就懂了，關(guān)鍵是要學(xué)會(huì)用到自己的代碼中。
狀態(tài)模式
update: 2017-10-19
廢話我就不說(shuō)了，我們說(shuō)一個(gè)簡(jiǎn)單的例子。商品庫(kù)存中心有個(gè)最基本的需求是減庫(kù)存和補(bǔ)庫(kù)存，我們看看怎么用狀態(tài)模式來(lái)寫(xiě)。
核心在于，我們的關(guān)注點(diǎn)不再是 Context 是該進(jìn)行哪種操作，而是關(guān)注在這個(gè) Context 會(huì)有哪些操作。
定義狀態(tài)接口：
public interface State {
public void doAction(Context context);
}
定義減庫(kù)存的狀態(tài)：
public class DeductState implements State {
public void doAction(Context context) {
System.out.println("商品賣(mài)出，準(zhǔn)備減庫(kù)存");
context.setState(this);
//... 執(zhí)行減庫(kù)存的具體操作
}
public String toString() {
return "Deduct State";
}
}
定義補(bǔ)庫(kù)存狀態(tài)：
public class RevertState implements State {
public void doAction(Context context) {
System.out.println("給此商品補(bǔ)庫(kù)存");
context.setState(this);
//... 執(zhí)行加庫(kù)存的具體操作
}
public String toString() {
return "Revert State";
}
}
前面用到了 context.setState(this)，我們來(lái)看看怎么定義 Context 類(lèi)：
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;
}
}
我們來(lái)看下客戶(hù)端調(diào)用，大家就一清二楚了：
public static void main(String[] args) {
// 我們需要操作的是 iPhone X
Context context = new Context("iPhone X");
// 看看怎么進(jìn)行補(bǔ)庫(kù)存操作
State revertState = new RevertState();
revertState.doAction(context);
// 同樣的，減庫(kù)存操作也非常簡(jiǎn)單
State deductState = new DeductState();
deductState.doAction(context);
// 如果需要我們可以獲取當(dāng)前的狀態(tài)
// context.getState().toString();
}
讀者可能會(huì)發(fā)現(xiàn)，在上面這個(gè)例子中，如果我們不關(guān)心當(dāng)前 context 處于什么狀態(tài)，那么 Context 就可以不用維護(hù) state 屬性了，那樣代碼會(huì)簡(jiǎn)單很多。
不過(guò)，商品庫(kù)存這個(gè)例子畢竟只是個(gè)例，我們還有很多實(shí)例是需要知道當(dāng)前 context 處于什么狀態(tài)的。
行為型模式總結(jié)
行為型模式部分介紹了策略模式、觀察者模式、責(zé)任鏈模式、模板方法模式和狀態(tài)模式，其實(shí)，經(jīng)典的行為型模式還包括備忘錄模式、命令模式等，但是它們的使用場(chǎng)景比較有限，而且本文篇幅也挺大了，我就不進(jìn)行介紹了。
總結(jié)
學(xué)習(xí)設(shè)計(jì)模式的目的是為了讓我們的代碼更加的優(yōu)雅、易維護(hù)、易擴(kuò)展。這次整理這篇文章，讓我重新審視了一下各個(gè)設(shè)計(jì)模式，對(duì)我自己而言收獲還是挺大的。我想，文章的最大收益者一般都是作者本人，為了寫(xiě)一篇文章，需要鞏固自己的知識(shí)，需要尋找各種資料，而且，自己寫(xiě)過(guò)的才最容易記住，也算是我給讀者的建議吧。
來(lái)源：https://javadoop.com/post/design-pattern
PS：如果覺(jué)得我的分享不錯(cuò)，歡迎大家隨手點(diǎn)贊、在看。
（完） 加我"微信" 獲取一份 最新Java面試題資料 請(qǐng)備注：666，不然不通過(guò)～
最近好文
1、Spring Boot 實(shí)現(xiàn)掃碼登錄，這種方式太香了！！
2、SpringSecurity + JWT 實(shí)現(xiàn)單點(diǎn)登錄
3、基于 Vue+Spring 前后端分離管理系統(tǒng)ELAdmin
最近面試BAT，整理一份面試資料《Java面試BAT通關(guān)手冊(cè)》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫(kù)、數(shù)據(jù)結(jié)構(gòu)等等。 獲取方式：關(guān)注公眾號(hào)并回復(fù) java 領(lǐng)取，更多內(nèi)容陸續(xù)奉上。 明天見(jiàn)(??ω??)??