1. 程式人生 > >23種設計模式-門面模式(外觀模式)Facade

23種設計模式-門面模式(外觀模式)Facade

1.產生背景

  • 為什麼需要門面模式
    這裡寫圖片描述

我是一個辛苦一輩子的農民,攢了幾十年錢,現在日子好了,也想建一套屬於自己的小洋樓;

首先,我要僱一個搬磚的和一個和泥的,還要一個會砌牆的人;可是我到哪裡去找這些人,還要一個一個跟他們談價錢;不知道他們和不和得來,會不會幹一半不幹了;

哎,好煩;

要是有一個人什麼都會就好,我只要跟他談,他一個人就能幫我把房子建好;
總之,我就是想省心;
這裡寫圖片描述

2.概念

提供一個統一的介面去訪問多個子系統的多個不同的介面,它為子系統中的一組介面提供一個統一的高層介面。使用子系統更容易使用。

本質:就是化零為整;引入一箇中介類,把各個分散的功能組合成一個整體,只對外暴露一個統一的介面;

這兩年流行微服務,即化整為零,把一個大服務拆分成一個個零部件;
而門面模式則是反其道,是化零為整;

3.目的

為了使用者使用方便,把過度拆分的分散功能,組合成一個整體,對外提供一個統一的介面

4.解決方案

本質:引入一個第三方中介類,這個類集合了多個零部件類的功能,實際功能則委託給這些零部件物件,這個類只是做為對外的統一介面,只是一個馬甲;

  • 引入中介物件
  • 有許多細粒度的小物件
  • 中介物件暴露了這些小物件的功能;
  • 中介物件實際功能委託給這些小物件
  • 中介物件提供給外部使用(對外隱藏那些小物件)

圖片來自百科
這裡寫圖片描述

 
  • 1

5. 類圖

所有實現類的地方都可以面向抽像程式設計(增加介面)
這裡寫圖片描述

6.優缺點

優點:

  • 鬆耦合
    使用者與子系統解耦,遮蔽子系統;可以提高子系統的獨立性;

  • 使用簡單
    簡化使用者與子系統的依賴關係;
    使用者只與門面對接,有統一的入口;不需要知道所有子系統及內部構造;

缺點:

  • 不規範的程式設計方式
    沒有面向抽象程式設計,而是通過增加中介層,轉換服務提供方的服務介面;

最核心的目的:簡化子系統,簡化客戶使用,遮蔽多個子系統

7.應用場景

  • A:簡化子系統複雜性時。
  • B:監控所有子系統時;通過門面控制了入口,可以統一監控;
  • C:希望封裝和隱藏子系統時;
  • D:兩歷史系統進行改造並打通關係時;

8.現實案例

spring ApplicationContext;
它實現了Factory、ResourceLoader等介面,並通過引用這些介面的例項,對外統一提供:載入配置、解析資源、建立Bean、提供環境、啟動流程等功能;

客戶程式碼只需要操作context就可以獲取spring的提供的功能,而無需關心內部的細節;

9.注意事項

“與代理模式的區別”
在瞭解門面模式時,會發現它不僅與代理模式很像,與裝飾器模式也很類似;
它們之間到底有什麼樣的區別呢?

相似點:
- 都引入了中介類(物件)
- 中介物件都引用並把功能委託給了原物件
- 都起到了”代理”功能

區別
- 代理側重於對原物件的訪問控制(當然也可以不是控制而是功能增強)
- 代理與原類實現相同的抽象(相同介面或直接繼承原業)
- 代理只代理一個類
- 門面側重於功能整合(多個小系統或小物件整合成一個功能豐富的大物件)
- 門面可以與子系統具有不同的抽象(具有不同的介面,可以對方法重新起名)
- 門面代理的是一系列類

--------------------- 本文來自 老楊叔叔csdn 的CSDN 部落格 ,全文地址請點選:https://blog.csdn.net/yangspgao/article/details/80602794?utm_source=copy23種設計模式-門面模式(外觀模式)