Java設計模式學習記錄-外觀模式 Java設計模式學習記錄-GoF設計模式概述

前言

此次要介紹的是外觀模式（也稱爲門面模式），外觀模式也屬於結構型模式，其實外觀模式仍是很是好理解的，簡單的來說就是將多個複雜的業務封裝成一個方法，在調用此方法時能夠沒必要關係具體執行了哪些業務，而只關心結果便可。這個場景其實在平常開發中使用的頻率仍是很是高的，下面來簡單瞭解一下吧。

外觀模式

概念介紹

外觀模式是隱藏了系統的複雜性，可以爲子系統中的一組接口提供一個統一的接口。客戶在使用系統時沒必要和子系統打交道了，下降了客戶和子系統間的耦合。

舉例

喝茶問題，當紀大煙袋跟和二想喝茶了，這個時候他們就會本身動手，拿茶具，開水，茶葉而後就把茶泡了。過程以下圖。

 

這樣兩我的都要本身操做茶具，開水，茶葉等，可是其實他倆就是想喝茶，纔不關心茶是怎麼泡出來的。因此這個時候他們倆就去茶館了，這樣也不用本身動手泡茶了，直接告訴茶館的店小二兒就好了。此時過程就變成了下面這樣的了。

下面用代碼來實現一下這個過程：

先得到飲用水

public class DrinkableWater {

    public DrinkableWater(){
        System.out.println("可飲用水準備好了");
    }

    //煮水
    public void facadeWater(){
        System.out.println("可飲用水沸騰了");
    }
}

再得到茶葉

public class Tea {

    public Tea(){
        System.out.println("茶葉準備好了。");
    }

    //取茶
    public void facadeTea(){
        System.out.println("能夠泡茶了。");
    }

}

而後得到茶杯就能夠泡茶了。

public class TeaCup {


    public TeaCup(){
        System.out.println("茶杯準備好了");
    }

    //泡茶
    public void facadeTeaCup(Tea tea){

        tea.facadeTea();
        System.out.println("茶葉泡進茶杯了。");
        System.out.println("等了一下子，一杯又香又濃的茶衝好了。");
    }
}

店小二泡茶

public class Waiter {

    private DrinkableWater drinkableWater = new DrinkableWater();
    private TeaCup teaCup = new TeaCup();
    private Tea tea = new Tea();

    //得到一杯茶
    public void getTea(){

        drinkableWater.facadeWater();
        teaCup.facadeTeaCup(tea);

    }

}

顧客來喝茶了

public class Customer {

    public static void main(String[] args) {

        //叫店小二
        Waiter waiter = new Waiter();
        //從店小二那得到一杯茶
        waiter.getTea();

    }

}

運行結果

可飲用水準備好了
茶杯準備好了
茶葉準備好了。
可飲用水沸騰了
能夠泡茶了。
茶葉泡進茶杯了。
等了一下子，一杯又香又濃的茶衝好了。

外觀模式的分析

 外觀模式的抽象結構圖以下：

在外觀模式中主要包含以下幾個角色。

一、門面角色（facade）:這是外觀模式的核心。它被客戶角色調用，所以它熟悉子系統的功能。它內部根據客戶角色已有的需求預約了幾種功能組合。

二、子系統角色（SystemA、SystemB、SystemC）:實現了子系統的功能。對子系統角色來講，facade角色與客戶角色同樣，是未知的，它沒有任何facade角色的信息和連接。

三、客戶角色（client）：調用facade角色來完成要獲得的功能。

在上面的泡茶的例子中，和二和紀大煙袋就是客戶角色，茶館店小二兒就是門面角色，茶具、飲用水、茶葉就是子系統角色。

外觀模式的優勢 

一、對客戶端屏蔽了子系統組件，減小了客戶端處理的對象數量，也減小了客戶端的代碼量。

二、實現了客戶端和子系統的鬆散耦合，使得子系統個變化不會影響到調用它的客戶端，只須要改變外觀類便可。

三、一個子系統的變化不會影響到另外一個子系統，子系統內部變化也不會影響到外觀對象。

外觀模式的缺點

一、不能很好地限制客戶端直接使用子系統類，若是對客戶端訪問子系統類作太多的限制則減小了可變性和靈活性。

二、若是設計不當，增長新的子系統可能須要修改外觀類的源代碼，違背了開閉原則。

適用場景

當要爲訪問一系列複雜的子系統提供一個簡單入口時可使用外觀模式。

客戶端程序與多個子系統之間存在很大的依賴性。引入外觀類能夠將子系統與客戶端解耦，從而提升子系統的獨立性和可移植性。

在層次化結構中，可使用外觀模式定義系統中每一層的入口，層與層之間不直接產生聯繫，而經過外觀類創建聯繫，下降層之間的耦合度。

延伸

在上面的例子中，咱們定義的門面是一個具體的類，可是當須要增長新的功能的時候，就須要修改門面類了，因此最好的辦法是作成抽象門面，也就是將門面類的功能抽象出來，而後又不一樣的需求的時候，能夠作兩個具體的門面類。例如：紀大煙袋跟和二去茶館喝茶是一個門面類，去上街買東西又是另外一個門面類。

 

 

 

想了解更多的設計模式請查看Java設計模式學習記錄-GoF設計模式概述。

 

 

 

 

 

 

 

 

 

我不慌，世界就不慌。加油吧！