筆記：Design Patter for facade（門面模式）

在程式設計中，這應該是最常見到的模式之一（只是有時候沒有發現而已）。

Facade Pattern 核心概念是：將多個子系統整合起來提供一個一致的介面讓 client 使用。也就是將一堆子系統的功能往上抽了一層，然後定義了一個統一入口。這個入口 client 不用管這個介面底下呼叫了多少個子系統，就只管 call 這個統一的入口即可達到想要的功能。

範例

假設要跟銀行對接 API，其中一個功能是要讓 client 進行領錢的動作。

這時候對開發的人來說，簡單的實作就是打銀行的某一個 API 入口，然後傳給他需要的相關欄位，接著收 resonpse 看有沒有成功。

對於用這支 API 的人（開發的人）來說，我們只會對到一個動作的入口。

但其實在銀行這支 API 的實作裡，可能做了很多的事。例：身份的認證、餘額確認 or 當日上限金額……等。這些細節的事情對打 API 的人來說完全不用曉得。

也就是銀行將底下這些功能都打包起來了，然後開一個口，讓外面的人可以簡單使用。

這種把多個動作或功能包起來，提供一個統一介面給別人使用，就是 facade pattern 要解決的情境。

優點

-簡化介面，讓 client 不用管到那麼底下的子系統功能
-解耦合，因為 client 不會跟底下的子系統綁在一起（但我個人看到的案例，這個優點也要看實作的架構）

個人經驗

這個模式在一般的系統裡到處可見。比如打第三方或內部不同 module 的 API 時，其實對 client 來講都是打一個入口，致於裡面要做哪些事其實根本就不用管。

又或著在自己同一個系統裡，去呼叫某一個 domain service method，而在這個方法裡，間接的有呼叫了很多其他不同 domain service 的方法。

在這二種情境下，確實對用的人來說，都是只管那一個統一的介面（入口），裡面的細節都可能完全不管。

這的確是大幅的簡化使用的複雜度，因為不用自己來呼叫一個又一個的子系統功能。

致於解耦合為什麼我個人認為是不一定，這要看 facade 這個的實作被抽出來後，是放在哪裡被使用。

假設簡單點，就是透過 API 讓 client 來進行呼叫，那的確對 client 來說會跟那些拉哩拉雜的子系統完全切開來。不會和子系統的元件 or 套件相依。

但如果是在同一個系統裡，但是是用參考元件的方法來進行使用，那就沒有所謂的解耦合的優點。因為這代表子系統（domain service）裡所有會相依的元件 or 套件，在你的主系統裡也都要被全部綁住。

這就代表之後某一個子系統他的相依元件有變 or 套件更換或版本升級，你的主系統都要被牽著鼻子走。

然後更慘的情況，就是你的主系統參考了很多個子系統，其中一個子系統有相依的異動，但其他的子系統又沒有，這時候就很容易掉進所謂的參照地獄裡了。