<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          圖文詳解 23 種設計模式

          共 56769字,需瀏覽 114分鐘

           ·

          2021-07-12 19:42

          點擊下方“IT牧場”,選擇“設為星標”


          一直想寫一篇介紹設計模式的文章,讓讀者可以很快看完,而且一看就懂,看懂就會用,同時不會將各個模式搞混。自認為本文還是寫得不錯的,花了不少心思來寫這文章和做圖,力求讓讀者真的能看著簡單同時有所收獲。

          設計模式是對大家實際工作中寫的各種代碼進行高層次抽象的總結,其中最出名的當屬 Gang of Four(GoF)的分類了,他們將設計模式分類為 23 種經(jīng)典的模式,根據(jù)用途我們又可以分為三大類,分別為創(chuàng)建型模式、結構型模式和行為型模式。

          有一些重要的設計原則在開篇和大家分享下,這些原則將貫通全文:

          • 面向接口編程,而不是面向實現(xiàn)。這個很重要,也是優(yōu)雅的、可擴展的代碼的第一步,這就不需要多說了吧。

          • 職責單一原則。每個類都應該只有一個單一的功能,并且該功能應該由這個類完全封裝起來。

          • 對修改關閉,對擴展開放。對修改關閉是說,我們辛辛苦苦加班寫出來的代碼,該實現(xiàn)的功能和該修復的 bug 都完成了,別人可不能說改就改;對擴展開放就比較好理解了,也就是說在我們寫好的代碼基礎上,很容易實現(xiàn)擴展。


          創(chuàng)建型模式比較簡單,但是會比較沒有意思,結構型和行為型比較有意思。


          創(chuàng)建型模式


          創(chuàng)建型模式的作用就是創(chuàng)建對象,說到創(chuàng)建一個對象,最熟悉的就是 new 一個對象,然后 set 相關屬性。但是,在很多場景下,我們需要給客戶端提供更加友好的創(chuàng)建對象的方式,尤其是那種我們定義了類,但是需要提供給其他開發(fā)者用的時候。

          簡單工廠模式

          和名字一樣簡單,非常簡單,直接上代碼吧:

          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,里面有一個靜態(tài)方法,根據(jù)我們不同的參數(shù),返回不同的派生自同一個父類(或實現(xiàn)同一接口)的實例對象。
          我們強調職責單一原則,一個類只提供一種功能,F(xiàn)oodFactory 的功能就是只要負責生產(chǎn)各種 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();
                  // 由第一步的工廠產(chǎn)生具體的對象,不同的工廠造出不一樣的對象
                  Food food = factory.makeFood("A");
              }
          }

          雖然都是調用 makeFood("A") 制作 A 類食物,但是,不同的工廠生產(chǎn)出來的完全不一樣。

          第一步,我們需要選取合適的工廠,然后第二步基本上和簡單工廠一樣。

          核心在于,我們需要在第一步選好我們需要的工廠。比如,我們有 LogFactory 接口,實現(xiàn)類有 FileLogFactory 和 KafkaLogFactory,分別對應將日志寫入文件和寫入 Kafka 中,顯然,我們客戶端第一步就需要決定到底要實例化 FileLogFactory 還是 KafkaLogFactory,這將決定之后的所有的操作。

          雖然簡單,不過我也把所有的構件都畫到一張圖上,這樣讀者看著比較清晰:


          抽象工廠模式

          當涉及到產(chǎn)品族的時候,就需要引入抽象工廠模式了。

          一個經(jīng)典的例子是造一臺電腦。我們先不引入抽象工廠模式,看看怎么實現(xiàn)。

          因為電腦是由許多的構件組成的,我們將 CPU 和主板進行抽象,然后 CPU 由 CPUFactory 生產(chǎn),主板由 MainBoardFactory 生產(chǎn),然后,我們再將 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 和相應的實現(xiàn)即可,不需要修改現(xiàn)有的工廠。

          但是,這種方式有一個問題,那就是如果 Intel 家產(chǎn)的 CPU 和 AMD 產(chǎn)的主板不能兼容使用,那么這代碼就容易出錯,因為客戶端并不知道它們不兼容,也就會錯誤地出現(xiàn)隨意組合。

          下面就是我們要說的產(chǎn)品族的概念,它代表了組成某個產(chǎn)品的一系列附件的集合:


          當涉及到這種產(chǎn)品族的問題的時候,就需要抽象工廠模式來支持了。我們不再定義 CPU 工廠、主板工廠、硬盤工廠、顯示屏工廠等等,我們直接定義電腦工廠,每個電腦工廠負責生產(chǎn)所有的設備,這樣能保證肯定不存在兼容問題。


          這個時候,對于客戶端來說,不再需要單獨挑選 CPU廠商、主板廠商、硬盤廠商等,直接選擇一家品牌工廠,品牌工廠會負責生產(chǎn)所有的東西,而且能保證肯定是兼容可用的。
          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() {};
              // 創(chuàng)建私有靜態(tài)實例,意味著這個類第一次使用的時候就會進行創(chuàng)建
              private static Singleton instance = new Singleton();

              public static Singleton getInstance() {
                  return instance;
              }
              // 瞎寫一個靜態(tài)方法。這里想說的是,如果我們只是要調用 Singleton.getDate(...),
              // 本來是不想要生成 Singleton 實例的,不過沒辦法,已經(jīng)生成了
              public static Date getDate(String mode) {return new Date();}
          }

          很多人都能說出餓漢模式的缺點,可是我覺得生產(chǎn)過程中,很少碰到這種情況:你定義了一個單例的類,不需要其實例,可是你卻把一個或幾個你會用到的靜態(tài)方法塞到這個類中。
          飽漢模式最容易出錯:

          public class Singleton {
              // 首先,也是先堵死 new Singleton() 這條路
              private Singleton() {}
              // 和餓漢模式相比,這邊不需要先實例化出來,注意這里的 volatile,它是必須的
              private static volatile Singleton instance = null;

              public static Singleton getInstance() {
                  if (instance == null) {
                      // 加鎖
                      synchronized (Singleton.class) {
                          // 這一次判斷也是必須的,不然會有并發(fā)問題
                          if (instance == null) {
                              instance = new Singleton();
                          }
                      }
                  }
                  return instance;
              }
          }

          雙重檢查,指的是兩次檢查 instance 是否為 null。

          volatile 在這里是需要的,希望能引起讀者的關注。


          很多人不知道怎么寫,直接就在 getInstance() 方法簽名上加上 synchronized,這就不多說了,性能太差。

          嵌套類最經(jīng)典,以后大家就用它吧:

          public class Singleton3 {

              private Singleton3() {}
              // 主要是使用了 嵌套類可以訪問外部類的靜態(tài)屬性和靜態(tài)方法 的特性
              private static class Holder {
                  private static Singleton3 instance = new Singleton3();
              }
              public static Singleton3 getInstance() {
                  return Holder.instance;
              }
          }

          注意,很多人都會把這個嵌套類說成是靜態(tài)內部類,嚴格地說,內部類和嵌套類是不一樣的,它們能訪問的外部類權限也是不一樣的。
          最后,我們說一下枚舉,枚舉很特殊,它在類加載的時候會初始化里面的所有的實例,而且 JVM 保證了它們不會再被實例化,所以它天生就是單例的。

          雖然我們平時很少看到用枚舉來實現(xiàn)單例,但是在 RxJava 的源碼中,有很多地方都用了枚舉來實現(xiàn)單例。

          建造者模式

          經(jīng)常碰見的 XxxBuilder 的類,通常都是建造者模式的產(chǎn)物。建造者模式其實有很多的變種,但是對于客戶端來說,我們的使用通常都是一個模式的:

          Food food = new FoodBuilder().a().b().c().build();
          Food food = Food.builder().a().b().c().build();

          套路就是先 new 一個 Builder,然后可以鏈式地調用一堆方法,最后再調用一次 build() 方法,我們需要的對象就有了。

          來一個中規(guī)中矩的建造者模式:

          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;
              }
              // 靜態(tài)方法,用于生成一個 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() 方法的時候,將這些屬性復制給實際產(chǎn)生的對象。

          看看客戶端的調用:

          public class APP {
              public static void main(String[] args) {
                  User d = User.builder()
                          .name("foo")
                          .password("pAss12345")
                          .age(25)
                          .build();
              }
          }

          說實話,建造者模式的鏈式寫法很吸引人,但是,多寫了很多“無用”的 builder 的代碼,感覺這個模式?jīng)]什么用。不過,當屬性很多,而且有些必填,有些選填的時候,這個模式會使代碼清晰很多。我們可以在 Builder 的構造方法中強制讓調用者提供必填字段,還有,在 build() 方法中校驗各個參數(shù)比在 User 的構造方法中校驗,代碼要優(yōu)雅一些。

          題外話,強烈建議讀者使用 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);

          很多人是這么用的,但是筆者覺得其實這種寫法非常地不優(yōu)雅,不是很推薦使用。
          原型模式

          這是我要說的創(chuàng)建型模式的最后一個設計模式了。

          原型模式很簡單:有一個原型實例,基于這個原型實例產(chǎn)生新的實例,也就是“克隆”了。

          Object 類中有一個 clone() 方法,它用于生成一個新的對象,當然,如果我們要調用這個方法,java 要求我們的類必須先實現(xiàn) Cloneable 接口,此接口沒有定義任何方法,但是不這么做的話,在 clone() 的時候,會拋出 CloneNotSupportedException 異常。

          protected native Object clone() throws CloneNotSupportedException;

          Java 的克隆是淺克隆,碰到對象引用的時候,克隆出來的對象和原對象中的引用將指向同一個對象。通常實現(xiàn)深克隆的方法是將對象進行序列化,然后再進行反序列化。

          原型模式了解到這里我覺得就夠了,各種變著法子說這種代碼或那種代碼是原型模式,沒什么意義。

          創(chuàng)建型模式總結

          創(chuàng)建型模式總體上比較簡單,它們的作用就是為了產(chǎn)生實例對象,算是各種工作的第一步了,因為我們寫的是面向對象的代碼,所以我們第一步當然是需要創(chuàng)建一個對象了。

          簡單工廠模式最簡單;工廠模式在簡單工廠模式的基礎上增加了選擇工廠的維度,需要第一步選擇合適的工廠;抽象工廠模式有產(chǎn)品族的概念,如果各個產(chǎn)品是存在兼容性問題的,就要用抽象工廠模式。單例模式就不說了,為了保證全局使用的是同一對象,一方面是安全性考慮,一方面是為了節(jié)省資源;建造者模式專門對付屬性很多的那種類,為了讓代碼更優(yōu)美;原型模式用得最少,了解和 Object 類中的 clone() 方法相關的知識即可。


          結構型模式


          前面創(chuàng)建型模式介紹了創(chuàng)建對象的一些設計模式,這節(jié)介紹的結構型模式旨在通過改變代碼結構來達到解耦的目的,使得我們的代碼容易維護和擴展。

          代理模式

          第一個要介紹的代理模式是最常使用的模式之一了,用一個代理來隱藏具體實現(xiàn)類的實現(xiàn)細節(jié),通常還用于在真實的實現(xiàn)的前后添加一部分邏輯。

          既然說是代理,那就要對客戶端隱藏真實實現(xiàn),由代理來負責客戶端的所有請求。當然,代理只是個代理,它不會完成實際的業(yè)務邏輯,而是一層皮而已,但是對于客戶端來說,它必須表現(xiàn)得就是客戶端需要的真實實現(xià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)得“就像是”真實實現(xiàn)類,所以需要實現(xiàn) FoodService
          public class FoodServiceProxy implements FoodService {

              // 內部一定要有一個真實的實現(xiàn)類,當然也可以通過構造方法注入
              private FoodService foodService = new FoodServiceImpl();

              public Food makeChicken() {
                  System.out.println("我們馬上要開始制作雞肉了");

                  // 如果我們定義這句為核心代碼的話,那么,核心代碼是真實實現(xiàn)類做的,
                  // 代理只是在核心代碼前后做些“無足輕重”的事情
                  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();



          我們發(fā)現(xiàn)沒有,代理模式說白了就是做 “方法包裝” 或做 “方法增強”。在面向切面編程中,其實就是動態(tài)代理的過程。比如 Spring 中,我們自己不定義代理類,但是 Spring 會幫我們動態(tài)來定義代理,然后把我們定義在 @Before、@After、@Around 中的代碼邏輯動態(tài)添加到代理中。

          說到動態(tài)代理,又可以展開說,Spring 中實現(xiàn)動態(tài)代理有兩種,一種是如果我們的類定義了接口,如 UserService 接口和 UserServiceImpl 實現(xiàn),那么采用 JDK 的動態(tài)代理,感興趣的讀者可以去看看 java.lang.reflect.Proxy 類的源碼;另一種是我們自己沒有定義接口的,Spring 會采用 CGLIB 進行動態(tài)代理,它是一個 jar 包,性能還不錯。

          適配器模式

          說完代理模式,說適配器模式,是因為它們很相似,這里可以做個比較。

          適配器模式做的就是,有一個接口需要實現(xiàn),但是我們現(xiàn)成的對象都不滿足,需要加一層適配器來進行適配。

          適配器模式總體來說分三種:默認適配器模式、對象適配器模式、類適配器模式。先不急著分清楚這幾個,先看看例子再說。

          默認適配器模式

          首先,我們先看看最簡單的適配器模式默認適配器模式(Default Adapter)是怎么樣的。

          我們用 Appache commons-io 包中的 FileAlterationListener 做例子,此接口定義了很多的方法,用于對文件或文件夾進行監(jiān)控,一旦發(fā)生了對應的操作,就會觸發(fā)相應的方法。

          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);
          }

          此接口的一大問題是抽象方法太多了,如果我們要用這個接口,意味著我們要實現(xiàn)每一個抽象方法,如果我們只是想要監(jiān)控文件夾中的文件創(chuàng)建和文件刪除事件,可是我們還是不得不實現(xiàn)所有的方法,很明顯,這不是我們想要的。

          所以,我們需要下面的一個適配器,它用于實現(xiàn)上面的接口,但是所有的方法都是空方法,這樣,我們就可以轉而定義自己的類來繼承下面這個類即可。

          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) {
              }
          }

          比如我們可以定義以下類,我們僅僅需要實現(xiàn)我們想實現(xiàn)的方法就可以了:

          public class FileMonitor extends FileAlterationListenerAdaptor {
              public void onFileCreate(final File file) {
                  // 文件創(chuàng)建
                  doSomething();
              }

              public void onFileDelete(final File file) {
                  // 文件刪除
                  doSomething();
              }
          }

          當然,上面說的只是適配器模式的其中一種,也是最簡單的一種,無需多言。下面,再介紹“正統(tǒng)的”適配器模式。

          對象適配器模式

          來看一個《Head First 設計模式》中的一個例子,我稍微修改了一下,看看怎么將雞適配成鴨,這樣雞也能當鴨來用。因為,現(xiàn)在鴨這個接口,我們沒有合適的實現(xiàn)類可以用,所以需要適配器。

          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() 方法是現(xiàn)成的,但是雞不會鴨的呱呱叫,沒有 quack() 方法。這個時候就需要適配了:

          // 毫無疑問,首先,這個適配器肯定需要 implements Duck,這樣才能當做鴨來用
          public class CockAdapter implements Duck {

              Cock cock;
              // 構造方法中需要一個雞的實例,此類就是將這只雞適配成鴨來用
                public CockAdapter(Cock cock) {
                  this.cock = cock;
              }

              // 實現(xiàn)鴨的呱呱叫方法
              @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);
                ...
          }

          到這里,大家也就知道了適配器模式是怎么回事了。無非是我們需要一只鴨,但是我們只有一只雞,這個時候就需要定義一個適配器,由這個適配器來充當鴨,但是適配器里面的方法還是由雞來實現(xiàn)的。

          我們用一個圖來簡單說明下:


          上圖應該還是很容易理解的,我就不做更多的解釋了。下面,我們看看類適配模式怎么樣的。

          類適配器模式

          廢話少說,直接上圖:


          看到這個圖,大家應該很容易理解的吧,通過繼承的方法,適配器自動獲得了所需要的大部分方法。這個時候,客戶端使用更加簡單,直接 Target t = new SomeAdapter(); 就可以了。

          適配器模式總結

          類適配和對象適配的異同:

          • 一個采用繼承,一個采用組合;

          • 類適配屬于靜態(tài)實現(xiàn),對象適配屬于組合的動態(tài)實現(xiàn),對象適配需要多實例化一個對象;

          • 總體來說,對象適配用得比較多。


          適配器模式和代理模式的異同:比較這兩種模式,其實是比較對象適配器模式和代理模式,在代碼結構上,它們很相似,都需要一個具體的實現(xiàn)類的實例。但是它們的目的不一樣,代理模式做的是增強原方法的活;適配器做的是適配的活,為的是提供“把雞包裝成鴨,然后當做鴨來使用”,而雞和鴨它們之間原本沒有繼承關系。


          橋梁模式

          理解橋梁模式,其實就是理解代碼抽象和解耦。

          我們首先需要一個橋梁,它是一個接口,定義提供的接口方法。

          public interface DrawAPI {
             public void draw(int radius, int x, int y);
          }

          然后是一系列實現(xiàn)類:

          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);
              }
          }

          定義一個抽象類,此類的實現(xiàn)類都需要使用 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();
          }

          可能大家看上面一步步還不是特別清晰,我把所有的東西整合到一張圖上:


          這回大家應該就知道抽象在哪里,怎么解耦了吧。橋梁模式的優(yōu)點也是顯而易見的,就是非常容易進行擴展。
          本節(jié)引用了https://www.tutorialspoint.com/design_pattern/bridge_pattern.htm的例子,并對其進行了修改。
          裝飾模式

          要把裝飾模式說清楚明白,不是件容易的事情。也許讀者知道 Java IO 中的幾個類是典型的裝飾模式的應用,但是讀者不一定清楚其中的關系,也許看完就忘了,希望看完這節(jié)后,讀者可以對其有更深的感悟。

          首先,我們先看一個簡單的圖,看這個圖的時候,了解下層次結構就可以了:


          我們來說說裝飾模式的出發(fā)點,從圖中可以看到,接口 Component 其實已經(jīng)有了 ConcreteComponentA 和 ConcreteComponentB 兩個實現(xiàn)類了,但是,如果我們要增強這兩個實現(xiàn)類的話,我們就可以采用裝飾模式,用具體的裝飾器來裝飾實現(xiàn)類,以達到增強的目的。
          從名字來簡單解釋下裝飾器。既然說是裝飾,那么往往就是添加小功能這種,而且,我們要滿足可以添加多個小功能。最簡單的,代理模式就可以實現(xiàn)功能的增強,但是代理不容易實現(xiàn)多個功能的增強,當然你可以說用代理包裝代理的多層包裝方式,但是那樣的話代碼就復雜了。
          首先明白一些簡單的概念,從圖中我們看到,所有的具體裝飾者們 ConcreteDecorator*** 都可以作為 Component 來使用,因為它們都實現(xiàn)了 Component 中的所有接口。它們和 Component 實現(xiàn)類 ConcreteComponent* 的區(qū)別是,它們只是裝飾者,起裝飾作用,也就是即使它們看上去牛逼轟轟,但是它們都只是在具體的實現(xiàn)中加了層皮來裝飾**而已。
          注意這段話中混雜在各個名詞中的 Component 和 Decorator,別搞混了。
          下面來看看一個例子,先把裝飾模式弄清楚,然后再介紹下 java io 中的裝飾模式的應用。

          最近大街上流行起來了“快樂檸檬”,我們把快樂檸檬的飲料分為三類:紅茶、綠茶、咖啡,在這三大類的基礎上,又增加了許多的口味,什么金桔檸檬紅茶、金桔檸檬珍珠綠茶、芒果紅茶、芒果綠茶、芒果珍珠紅茶、烤珍珠紅茶、烤珍珠芒果綠茶、椰香胚芽咖啡、焦糖可可咖啡等等,每家店都有很長的菜單,但是仔細看下,其實原料也沒幾樣,但是可以搭配出很多組合,如果顧客需要,很多沒出現(xiàn)在菜單中的飲料他們也是可以做的。

          在這個例子中,紅茶、綠茶、咖啡是最基礎的飲料,其他的像金桔檸檬、芒果、珍珠、椰果、焦糖等都屬于裝飾用的。當然,在開發(fā)中,我們確實可以像門店一樣,開發(fā)這些類:LemonBlackTea、LemonGreenTea、MangoBlackTea、MangoLemonGreenTea......但是,很快我們就發(fā)現(xiàn),這樣子干肯定是不行的,這會導致我們需要組合出所有的可能,而且如果客人需要在紅茶中加雙份檸檬怎么辦?三份檸檬怎么辦?

          不說廢話了,上代碼。

          首先,定義飲料抽象基類:

          public abstract class Beverage {
                // 返回描述
                public abstract String getDescription();
                // 返回價格
                public abstract double cost();
          }

          然后是三個基礎飲料實現(xiàn)類,紅茶、綠茶和咖啡:

          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;
              // 這里很關鍵,需要傳入具體的飲料,如需要傳入沒有被裝飾的紅茶或綠茶,
              // 當然也可以傳入已經(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 元
              }
          }
          ...// 給每一種調料都加一個類

          看客戶端調用:

          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())))); 

          是不是很變態(tài)?

          看看下圖可能會清晰一些:


          到這里,大家應該已經(jīng)清楚裝飾模式了吧。

          下面,我們再來說說 Java IO 中的裝飾模式。看下圖 InputStream 派生出來的部分類:


          我們知道 InputStream 代表了輸入流,具體的輸入來源可以是文件(FileInputStream)、管道(PipedInputStream)、數(shù)組(ByteArrayInputStream)等,這些就像前面奶茶的例子中的紅茶、綠茶,屬于基礎輸入流。

          FilterInputStream 承接了裝飾模式的關鍵節(jié)點,它的實現(xiàn)類是一系列裝飾器,比如 BufferedInputStream 代表用緩沖來裝飾,也就使得輸入流具有了緩沖的功能,LineNumberInputStream 代表用行號來裝飾,在操作的時候就可以取得行號了,DataInputStream 的裝飾,使得我們可以從輸入流轉換為 Java 中的基本類型值。

          當然,在 Java IO 中,如果我們使用裝飾器的話,就不太適合面向接口編程了,如:

          InputStream inputStream = new LineNumberInputStream(new BufferedInputStream(new FileInputStream("")));

          這樣的結果是,InputStream 還是不具有讀取行號的功能,因為讀取行號的方法定義在 LineNumberInputStream 類中。

          我們應該像下面這樣使用:

          DataInputStream is = new DataInputStream(
                                        new BufferedInputStream(
                                            new FileInputStream("")));

          所以說嘛,要找到純的嚴格符合設計模式的代碼還是比較難的。
          門面模式

          門面模式(也叫外觀模式,F(xiàn)acade Pattern)在許多源碼中有使用,比如 SLF4J 就可以理解為是門面模式的應用。這是一個簡單的設計模式,我們直接上代碼再說吧。

          首先,我們定義一個接口:

          public interface Shape {
             void draw();
          }

          定義幾個實現(xiàn)類:

          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();
             }
          }

          看看現(xiàn)在客戶端怎么調用:

          public static void main(String[] args) {
            ShapeMaker shapeMaker = new ShapeMaker();

            // 客戶端調用現(xiàn)在更加清晰了
            shapeMaker.drawCircle();
            shapeMaker.drawRectangle();
            shapeMaker.drawSquare();        
          }

          門面模式的優(yōu)點顯而易見,客戶端不再需要關注實例化時應該使用哪個實現(xiàn)類,直接調用門面提供的方法就可以了,因為門面類提供的方法的方法名對于客戶端來說已經(jīng)很友好了。

          組合模式

          組合模式用于表示具有層次結構的數(shù)據(jù),使得我們對單個對象和組合對象的訪問具有一致性。

          直接看一個例子吧,每個員工都有姓名、部門、薪水這些屬性,同時還有下屬員工集合(雖然可能集合為空),而下屬員工和自己的結構是一樣的,也有姓名、部門這些屬性,同時也有他們的下屬員工集合。

          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,不知道是誰最先翻譯的這個詞,感覺這翻譯真的不好理解,我們試著強行關聯(lián)起來吧。Flyweight 是輕量級的意思,享元分開來說就是 共享 元器件,也就是復用已經(jīng)生成的對象,這種做法當然也就是輕量級的了。

          復用對象最簡單的方式是,用一個 HashMap 來存放每次新生成的對象。每次需要一個對象的時候,先到 HashMap 中看看有沒有,如果沒有,再生成新的對象,然后將這個對象放入 HashMap 中。

          這種簡單的代碼我就不演示了。

          結構型模式總結

          前面,我們說了代理模式、適配器模式、橋梁模式、裝飾模式、門面模式、組合模式和享元模式。讀者是否可以分別把這幾個模式說清楚了呢?在說到這些模式的時候,心中是否有一個清晰的圖或處理流程在腦海里呢?

          代理模式是做方法增強的,適配器模式是把雞包裝成鴨這種用來適配接口的,橋梁模式做到了很好的解耦,裝飾模式從名字上就看得出來,適合于裝飾類或者說是增強類的場景,門面模式的優(yōu)點是客戶端不需要關心實例化過程,只要調用需要的方法即可,組合模式用于描述具有層次結構的數(shù)據(jù),享元模式是為了在特定的場景中緩存已經(jīng)創(chuàng)建的對象,用于提高性能。


          行為型模式


          行為型模式關注的是各個類之間的相互作用,將職責劃分清楚,使得我們的代碼更加地清晰。

          策略模式

          策略模式太常用了,所以把它放到最前面進行介紹。它比較簡單,我就不廢話,直接用代碼說事吧。

          下面設計的場景是,我們需要畫一個圖形,可選的策略就是用紅色筆來畫,還是綠色筆來畫,或者藍色筆來畫。

          首先,先定義一個策略接口:

          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);
          }

          放到一張圖上,讓大家看得清晰些:


          這個時候,大家有沒有聯(lián)想到結構型模式中的橋梁模式,它們其實非常相似,我把橋梁模式的圖拿過來大家對比下:


          要我說的話,它們非常相似,橋梁模式在左側加了一層抽象而已。橋梁模式的耦合更低,結構更復雜一些。

          觀察者模式

          觀察者模式對于我們來說,真是再簡單不過了。無外乎兩個操作,觀察者訂閱自己關心的主題和主題有數(shù)據(jù)變化后通知觀察者們。

          首先,需要定義主題,每個主題需要持有觀察者列表的引用,用于在數(shù)據(jù)變更的時候通知各個觀察者:

          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;
                  // 數(shù)據(jù)已變更,通知觀察者們
                  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();
          }

          其實如果只有一個觀察者類的話,接口都不用定義了,不過,通常場景下,既然用到了觀察者模式,我們就是希望一個事件出來了,會有多個不同的類需要處理相應的信息。比如,訂單修改成功事件,我們希望發(fā)短信的類得到通知、發(fā)郵件的類得到通知、處理物流信息的類得到通知等。

          我們來定義具體的幾個觀察者類:

          public class BinaryObserver extends Observer {
              // 在構造方法中進行訂閱主題
              public BinaryObserver(Subject subject) {
                  this.subject = subject;
                  // 通常在構造方法中將 this 發(fā)布出去的操作一定要小心
                  this.subject.attach(this);
              }
              // 該方法由主題類在數(shù)據(jù)變更的時候進行調用
              @Override
              public void update() {
                  String result = Integer.toBinaryString(subject.getState());
                  System.out.println("訂閱的數(shù)據(jù)發(fā)生變化,新的數(shù)據(jù)處理為二進制值為:" + 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ù)處理為十六進制值為:" + result);
              }
          }

          客戶端使用也非常簡單:

          public static void main(String[] args) {
              // 先定義一個主題
              Subject subject1 = new Subject();
              // 定義觀察者
              new BinaryObserver(subject1);
              new HexaObserver(subject1);

              // 模擬數(shù)據(jù)變更,這個時候,觀察者們的 update 方法將會被調用
              subject.setState(11);
          }

          output:

          訂閱的數(shù)據(jù)發(fā)生變化,新的數(shù)據(jù)處理為二進制值為:1011
          訂閱的數(shù)據(jù)發(fā)生變化,新的數(shù)據(jù)處理為十六進制值為:B

          當然,JDK 也提供了相似的支持,具體的大家可以參考 java.util.Observable 和 java.util.Observer 這兩個類。

          實際生產(chǎn)過程中,觀察者模式往往用消息中間件來實現(xiàn),如果要實現(xiàn)單機觀察者模式,筆者建議讀者使用 Guava 中的 EventBus,它有同步實現(xiàn)也有異步實現(xiàn),本文主要介紹設計模式,就不展開說了。

          還有,即使是上面的這個代碼,也會有很多變種,大家只要記住核心的部分,那就是一定有一個地方存放了所有的觀察者,然后在事件發(fā)生的時候,遍歷觀察者,調用它們的回調函數(shù)。

          責任鏈模式

          責任鏈通常需要先建立一個單向鏈表,然后調用方只需要調用頭部節(jié)點就可以了,后面會自動流轉下去。比如流程審批就是一個很好的例子,只要終端用戶提交申請,根據(jù)申請的內容信息,自動建立一條責任鏈,然后就可以開始流轉了。

          有這么一個場景,用戶參加一個活動可以領取獎品,但是活動需要進行很多的規(guī)則校驗然后才能放行,比如首先需要校驗用戶是否是新用戶、今日參與人數(shù)是否有限額、全場參與人數(shù)是否有限額等等。設定的規(guī)則都通過后,才能讓用戶領走獎品。
          如果產(chǎn)品給你這個需求的話,我想大部分人一開始肯定想的就是,用一個 List 來存放所有的規(guī)則,然后 foreach 執(zhí)行一下每個規(guī)則就好了。不過,讀者也先別急,看看責任鏈模式和我們說的這個有什么不一樣?
          首先,我們要定義流程上節(jié)點的基類:

          public abstract class RuleHandler {
              // 后繼節(jié)點
              protected RuleHandler successor;

              public abstract void apply(Context context);

              public void setSuccessor(RuleHandler successor) {
                  this.successor = successor;
              }

              public RuleHandler getSuccessor() {
                  return successor;
              }
          }

          接下來,我們需要定義具體的每個節(jié)點了。

          校驗用戶是否是新用戶:

          public class NewUserRuleHandler extends RuleHandler {
              public void apply(Context context) {
                  if (context.isNewUser()) {
                      // 如果有后繼節(jié)點的話,傳遞下去
                      if (this.getSuccessor() != null) {
                          this.getSuccessor().apply(context);
                      }
                  } else {
                      throw new RuntimeException("該活動僅限新用戶參與");
                  }
              }
          }

          驗用戶所在地區(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ū)無法參與本次活動");
                  }
              }
          }

          校驗獎品是否已領完:

          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();

              // 假設本次活動僅校驗地區(qū)和獎品數(shù)量,不校驗新老用戶
              locationHandler.setSuccessor(limitHandler);

              locationHandler.apply(context);
          }

          代碼其實很簡單,就是先定義好一個鏈表,然后在通過任意一節(jié)點后,如果此節(jié)點有后繼節(jié)點,那么傳遞下去。

          至于它和我們前面說的用一個 List 存放需要執(zhí)行的規(guī)則的做法有什么異同,留給讀者自己琢磨吧。

          模板方法模式

          在含有繼承結構的代碼中,模板方法模式是非常常用的。

          通常會有一個抽象類:

          public abstract class AbstractTemplate {
              // 這就是模板方法
              public void templateMethod() {
                  init();
                  apply(); // 這個是重點
                  end(); // 可以作為鉤子方法
              }

              protected void init() {
                  System.out.println("init 抽象層已經(jīng)實現(xiàn),子類也可以選擇覆寫");
              }

              // 留給子類實現(xiàn)
              protected abstract void apply();

              protected void end() {
              }
          }

          模板方法中調用了 3 個方法,其中 apply() 是抽象方法,子類必須實現(xiàn)它,其實模板方法中有幾個抽象方法完全是自由的,我們也可以將三個方法都設置為抽象方法,讓子類來實現(xiàn)。也就是說,模板方法只負責定義第一步應該要做什么,第二步應該做什么,第三步應該做什么,至于怎么做,由子類來實現(xiàn)。

          我們寫一個實現(xiàn)類:

          public class ConcreteTemplate extends AbstractTemplate {
              public void apply() {
                  System.out.println("子類實現(xiàn)抽象方法 apply");
              }

              public void end() {
                  System.out.println("我們可以把 method3 當做鉤子方法來使用,需要的時候覆寫就可以了");
              }
          }

          客戶端調用演示:

          public static void main(String[] args) {
              AbstractTemplate t = new ConcreteTemplate();
              // 調用模板方法
              t.templateMethod();
          }

          代碼其實很簡單,基本上看到就懂了,關鍵是要學會用到自己的代碼中。

          狀態(tài)模式

          廢話我就不說了,我們說一個簡單的例子。商品庫存中心有個最基本的需求是減庫存和補庫存,我們看看怎么用狀態(tài)模式來寫。

          核心在于,我們的關注點不再是 Context 是該進行哪種操作,而是關注在這個 Context 會有哪些操作。

          定義狀態(tài)接口:

          public interface State {
              public void doAction(Context context);
          }

          定義減庫存的狀態(tài):

          public class DeductState implements State {

              public void doAction(Context context) {
                  System.out.println("商品賣出,準備減庫存");
                  context.setState(this);

                  //... 執(zhí)行減庫存的具體操作
              }

              public String toString() {
                  return "Deduct State";
              }
          }

          定義補庫存狀態(tài):

          public class RevertState implements State {

              public void doAction(Context context) {
                  System.out.println("給此商品補庫存");
                  context.setState(this);

                  //... 執(zhí)行加庫存的具體操作
              }

              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);

                // 如果需要我們可以獲取當前的狀態(tài)
              // context.getState().toString();
          }

          讀者可能會發(fā)現(xiàn),在上面這個例子中,如果我們不關心當前 context 處于什么狀態(tài),那么 Context 就可以不用維護 state 屬性了,那樣代碼會簡單很多。

          不過,商品庫存這個例子畢竟只是個例,我們還有很多實例是需要知道當前 context 處于什么狀態(tài)的。

          行為型模式總結

          行為型模式部分介紹了策略模式、觀察者模式、責任鏈模式、模板方法模式和狀態(tài)模式,其實,經(jīng)典的行為型模式還包括備忘錄模式、命令模式等,但是它們的使用場景比較有限,而且本文篇幅也挺大了,我就不進行介紹了。


          總結


          學習設計模式的目的是為了讓我們的代碼更加的優(yōu)雅、易維護、易擴展。這次整理這篇文章,讓我重新審視了一下各個設計模式,對我自己而言收獲還是挺大的。我想,文章的最大收益者一般都是作者本人,為了寫一篇文章,需要鞏固自己的知識,需要尋找各種資料,而且,自己寫過的才最容易記住,也算是我給讀者的建議吧。

          原文鏈接:https://javadoop.com/post/design-pattern

          干貨分享

          最近將個人學習筆記整理成冊,使用PDF分享。關注我,回復如下代碼,即可獲得百度盤地址,無套路領取!

          ?001:《Java并發(fā)與高并發(fā)解決方案》學習筆記;?002:《深入JVM內核——原理、診斷與優(yōu)化》學習筆記;?003:《Java面試寶典》?004:《Docker開源書》?005:《Kubernetes開源書》?006:《DDD速成(領域驅動設計速成)》?007:全部?008:加技術群討論

          加個關注不迷路

          喜歡就點個"在看"唄^_^

          瀏覽 75
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  中文无码破解 | 中文在线观看一区二区三区四区 | 免费日批网站 | 在线免费精品福利 | 久久精品久久ai 久久精品内射国产 |