初探Java設計模式3：行爲型模式（策略，觀察者等）

轉自https://javadoop.com/post/design-pattern

行爲型模式

• 策略模式
• 觀察者模式
• 責任鏈模式
• 模板方法模式
• 狀態模式
• 行爲型模式總結
  *
  

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到個人倉庫裏查看

https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star、fork哈

文章也將發表在個人我的博客，閱讀體驗更佳：

www.how2playlife.com

本文是微信公衆號【Java技術江湖】的《夯實Java基礎系列博文》其中一篇，本文部份內容來源於網絡，爲了把本文主題講得清晰透徹，也整合了不少我認爲不錯的技術博客內容，引用其中了一些比較好的博客文章，若有侵權，請聯繫做者。該系列博文會告訴你如何從入門到進階，一步步地學習Java基礎知識，並上手進行實戰，接着瞭解每一個Java知識點背後的實現原理，更完整地瞭解整個Java技術體系，造成本身的知識框架。爲了更好地總結和檢驗你的學習成果，本系列文章也會提供每一個知識點對應的面試題以及參考答案。

若是對本系列文章有什麼建議，或者是有什麼疑問的話，也能夠關注公衆號【Java技術江湖】聯繫做者，歡迎你參與本系列博文的創做和修訂

行爲型模式

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

策略模式

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

下面設計的場景是，咱們須要畫一個圖形，可選的策略就是用紅色筆來畫，仍是綠色筆來畫，或者藍色筆來畫。

首先，先定義一個策略接口：

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);
}
複製代碼

放到一張圖上，讓你們看得清晰些：

轉存失敗從新上傳取消​

這個時候，你們有沒有聯想到結構型模式中的橋樑模式，它們其實很是類似，我把橋樑模式的圖拿過來你們對比下：

要我說的話，它們很是類似，橋樑模式在左側加了一層抽象而已。橋樑模式的耦合更低，結構更復雜一些。

觀察者模式

觀察者模式對於咱們來講，真是再簡單不過了。無外乎兩個操做，觀察者訂閱本身關心的主題和主題有數據變化後通知觀察者們。

首先，須要定義主題，每一個主題須要持有觀察者列表的引用，用於在數據變動的時候通知各個觀察者：

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 處於什麼狀態的。

行爲型模式總結

行爲型模式部分介紹了策略模式、觀察者模式、責任鏈模式、模板方法模式和狀態模式，其實，經典的行爲型模式還包括備忘錄模式、命令模式等，可是它們的使用場景比較有限，並且本文篇幅也挺大了，我就不進行介紹了。

總結

學習設計模式的目的是爲了讓咱們的代碼更加的優雅、易維護、易擴展。此次整理這篇文章，讓我從新審視了一下各個設計模式，對我本身而言收穫仍是挺大的。我想，文章的最大收益者通常都是做者本人，爲了寫一篇文章，須要鞏固本身的知識，須要尋找各類資料，並且，本身寫過的才最容易記住，也算是我給讀者的建議吧。

（全文完）

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到個人倉庫裏查看

https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star、fork哈

文章也將發表在個人我的博客，閱讀體驗更佳：

www.how2playlife.com

結構型模式

前面建立型模式介紹了建立對象的一些設計模式，這節介紹的結構型模式旨在經過改變代碼結構來達到解耦的目的，使得咱們的代碼容易維護和擴展。

代理模式

第一個要介紹的代理模式是最常使用的模式之一了，用一個代理來隱藏具體實現類的實現細節，一般還用於在真實的實現的先後添加一部分邏輯。

既然說是代理，那就要對客戶端隱藏真實實現，由代理來負責客戶端的全部請求。固然，代理只是個代理，它不會完成實際的業務邏輯，而是一層皮而已，可是對於客戶端來講，它必須表現得就是客戶端須要的真實實現。

理解代理這個詞，這個模式其實就簡單了。

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();
複製代碼

咱們發現沒有，代理模式說白了就是作 「方法包裝」 或作 「方法加強」。在面向切面編程中，算了仍是不要吹捧這個名詞了，在 AOP 中，其實就是動態代理的過程。好比 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(); 就能夠了。

適配器模式總結

1. 類適配和對象適配的異同

> 一個採用繼承，一個採用組合；
    > 
    > 類適配屬於靜態實現，對象適配屬於組合的動態實現，對象適配須要多實例化一個對象。
    > 
    > 整體來講，對象適配用得比較多。複製代碼

1. 適配器模式和代理模式的異同

比較這兩種模式，實際上是比較對象適配器模式和代理模式，在代碼結構上，它們很類似，都須要一個具體的實現類的實例。可是它們的目的不同，代理模式作的是加強原方法的活；適配器作的是適配的活，爲的是提供「把雞包裝成鴨，而後當作鴨來使用」，而雞和鴨它們之間本來沒有繼承關係。複製代碼

橋樑模式

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

咱們首先須要一個橋樑，它是一個接口，定義提供的接口方法。

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();
}
複製代碼

可能你們看上面一步步還不是特別清晰，我把全部的東西整合到一張圖上：

這回你們應該就知道抽象在哪裏，怎麼解耦了吧。橋樑模式的優勢也是顯而易見的，就是很是容易進行擴展。

本節引用了這裏的例子，並對其進行了修改。

裝飾模式

要把裝飾模式說清楚明白，不是件容易的事情。也許讀者知道 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 中。

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

結構型模式總結

前面，咱們說了代理模式、適配器模式、橋樑模式、裝飾模式、門面模式、組合模式和享元模式。讀者是否能夠分別把這幾個模式說清楚了呢？在說到這些模式的時候，心中是否有一個清晰的圖或處理流程在腦海裏呢？

代理模式是作方法加強的，適配器模式是把雞包裝成鴨這種用來適配接口的，橋樑模式作到了很好的解耦，裝飾模式從名字上就看得出來，適合於裝飾類或者說是加強類的場景，門面模式的優勢是客戶端不須要關心實例化過程，只要調用須要的方法便可，組合模式用於描述具備層次結構的數據，享元模式是爲了在特定的場景中緩存已經建立的對象，用於提升性能。

參考文章

轉自https://javadoop.com/post/design-pattern

本文由博客一文多發平臺 OpenWrite 發佈！