Facade，Adapter，Proxy模式有點類似，功能上都是對調用者提供調用接口，但他們的目的就有些不同。最近正在做一個域名系統，其中就用到了Facade和Adapter模式。正好結合項目來分析下這幾種設計模式的不同。
Adapter是爲了保持已有接口的不變性，而不管調用模塊或者層次間代碼的變化。因爲需求及性能等的不同考慮，我們的DNS服務器即有傳統的較高性能的BIND，又有性能較低但是靈活性大大提高的BIND DLZ。而添加一條紀錄必須要能夠往這兩種服務器中添加。顯然上層不會考慮添加這個紀錄的區別，所以我們需要一個Adapter層來提供統一接口屏蔽掉兩種不同系統的區別。
Facade是爲了屏蔽掉被調用者的一系列複雜操作，對調用者提供的一個接口來完成一系列的工作。
在我們的域名系統中數據中心也就是管理BIND,BIND DLZ中記錄的模塊只提供了最基本的記錄操作以及一些簡單的基本組合操作。而註冊域名及IP等需要數條操作才能完成工作，此時我們的Agent並不想要進行那麼複雜的一系列操作，所以我們提供了一個Facade，來對這些操作進行包裝，Agent只需要調用一個接口就可以完成它的工作了。
圖並沒有採用什麼的例子，而是採用update=del+add的一張圖，因爲覺得這個例子非常適合理解Facade模式，刪除原有數據{KEY:VALUE1}，新增數據{KEY:VALUE2}，這樣實際上就組成了Update操作(不要說誰會將Update修改成Del和Add，這個應該是大家最能理解的例子之一)。所以我們可以新增一個Facade類，對Caller提供Update接口，這樣Caller完成這項工作就輕鬆了很多。
Adapter跟Facade在實現上往往有點像，但是從目的上來區分卻是一目瞭然的：
Adapter提供一個接口來屏蔽一些代碼的不確定性：第三方庫的改變，系統平臺層次的改變，方案的改變等
Facade提供一個接口來屏蔽一系列操作的複雜性：我只想要結果，隨你怎麼玩
Proxy與Adapter的區別應該還是很好理解的，但是與Facade的區別在於哪兒呢？說實話我在項目中並沒有在代碼層次直接使用過這個模式。但是在項目層次中確也有使用過，如使用nginx來做反向代理來達到負載均衡的目的，我的理解是Proxy比Facade的區別在於更加獨立，客戶端完全不知道也不需要知道具體的實現，只是通過Proxy來完成即可。所以Facade應該是調用較多，而Proxy很多情況都是不同系統間的通訊，通過發送消息來完成通訊。理解的不一定對，記錄下先。