設計模式之門面模式

門面模式

一:門面模式概述

在現實世界中,外牆都在咱們身邊。操做系統就是這樣一個例子 - 您沒有看到計算機的全部內部工做方式,但操做系統提供了使用機器的簡化界面。簡而言之,門面模式旨在使事物看起來更清潔,更容易操做。java


定義:爲子系統中的一組接口提供統一接口。Façade定義了一個更高級別的接口,使子系統更易於使用。dom


門面模式只是將客戶端與子系統隔離,結構圖以下:this

1545747978153

角色:spa

  • **Facade(外觀角色):**在客戶端能夠調用它的方法,在外觀角色中能夠知道相關的(一個或者多個)子系統的功能和責任;在正常狀況下,它將全部從客戶端發來的請求委派到相應的子系統去,傳遞給相應的子系統對象處理。操作系統

  • SubSystem(子系統角色):在軟件系統中能夠有一個或者多個子系統角色,每個子系統能夠不是一個單獨的類,而是一個類的集合,它實現子系統的功能;每個子系統均可以被客戶端直接調用,或者被外觀角色調用,它處理由外觀類傳過來的請求;子系統並不知道外觀的存在,對於子系統而言,外觀角色僅僅是另一個客戶端而已。3d

與適配器模式同樣,Facade可用於隱藏第三方庫或某些遺留代碼的內部工做方式。客戶端須要作的就是與Facade交互,而不是它所包含的子系統.code

二 :門面模式實戰

某購物系統須要用戶登陸支付,客戶端不清楚裏面會調用哪些系統,它只管提供負責調用購買方法來達到購買的目的。cdn

登陸子系統:對象

// 登陸子系統
public class Login {
    public void Login(String username, String password){
        // 登陸相關
    }
}
複製代碼

生成訂單子系統:blog

//生成訂單子系統
public class Order {
    public void createOrder(String userName){
        // 生成訂單相關
    }
}
複製代碼

支付子系統:

// 支付子系統
public class Pay {
    public void payOrder(String username){
        // 支付相關
        System.out.println("尊敬的" + username + ",您的商品購買成功" + ";請保管好您的訂單號:"
                + UUID.randomUUID().toString());
    }
}
複製代碼

購買外觀類:

// 購買外觀類
public class ShopingFacade {
    private Login loginHelp;
    private Order orderHelp;
    private Pay payHelp;

    public ShopingFacade(){
        this.loginHelp = new Login();
        this.orderHelp = new Order();
        this.payHelp = new Pay();
    }

    // 用戶購買商品
    public void shop(String userName, String password){
        loginHelp.Login(userName, password);
        orderHelp.createOrder(userName);
        payHelp.payOrder(userName);
    }
}
複製代碼

客戶端:

public class Client {
    public static void main(String[] args) {
        // 購買外觀類,客戶端並不知道里面調用了登陸,訂單和支付子系統
        ShopingFacade shopingFacade = new ShopingFacade();
        shopingFacade.shop("tom", "123");
    }
}
複製代碼

運行結果:

尊敬的tom,您的商品購買成功;請保管好您的訂單號:438e379c-2c03-4579-b732-8bd23daf8e0b

在整個實例中,外觀類對客戶端屏蔽了3個子系統,減小了客戶端要處理的對象,使得客戶端代碼變得很簡單。


三:門面模式總結

優點:

  1. 使客戶端和子系統隔離,客戶端代碼變得很簡單,不須要跟多個子系統進行關聯。
  2. 子系統的變化不會影響客戶端的代碼。
  3. 子系統直接鬆耦合,一個系統的修改對其餘系統沒有影響。

劣勢:

  1. 增長新的子類系統須要可能須要修改外觀類的源碼,違背開閉原則。

使用場景

  1. 當要爲訪問一系列複雜的子系統提供一個簡單入口時可使用外觀模式。
  2. 客戶端程序與多個子系統之間存在很大的依賴性。引入外觀類能夠將子系統與客戶端解耦,從而提升子系統的獨立性和可移植性。
  3. 在層次化結構中,可使用外觀模式定義系統中每一層的入口,層與層之間不直接產生聯繫,而經過外觀類創建聯繫,下降層之間的耦合度。
相關文章
相關標籤/搜索