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很多情况都是不同系统间的通讯，通过发送消息来完成通讯。理解的不一定对，记录下先。