Java 設計模式

轉自 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 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(); 就可以了。

介面卡模式總結

類適配和物件適配的異同

一個採用繼承，一個採用組合；

類適配屬於靜態實現，物件適配屬於組合的動態實現，物件適配需要多例項化一個物件。

總體來說，物件適配用得比較多。
介面卡模式和代理模式的異同

比較這兩種模式，其實是比較物件介面卡模式和代理模式，在程式碼結構上，它們很相似，都需要一個具體的實現類的例項。但是它們的目的不一樣，代理模式做的是增強原方法的活；介面卡做的是適配的活，為的是提供“把雞包裝成鴨，然後當做鴨來使用”，而雞和鴨它們之間原本沒有繼承關係。

橋樑模式

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

我們首先需要一個橋樑，它是一個介面，定義提供的介面方法。

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 中。

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

結構型模式總結

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

代理模式是做方法增強的，介面卡模式是把雞包裝成鴨這種用來適配介面的，橋樑模式做到了很好的解耦，裝飾模式從名字上就看得出來，適合於裝飾類或者說是增強類的場景，門面模式的優點是客戶端不需要關心例項化過程，只要呼叫需要的方法即可，組合模式用於描述具有層次結構的資料，享元模式是為了在特定的場景中快取已經建立的物件，用於提高效能。

參考文章