大战设计模式【10】—— 外观模式

外观模式（Facade）

 

设计模式使用的例子https://github.com/LinkinStars/DesignPatternsAllExample

 

一、定义

外部与一个子系统的通信通过一个统一的外观角色进行，为子系统中的一组接口提供一个一致的入口，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

　

二、结构

Facade（外观角色）：在客户端可以调用这个角色的方法，在外观角色中可以知道相关的子系统的功能和责任；

在正常情况下，它将所有从客户端发来的请求委派到相应的子系统中去，传递给相应的子系统对象处理。

SubSystem（子系统角色）：在软件系统中可以有一个或者多个子系统角色，每一个子系统可以不是一个单独的类，而是一个类的集合，

它实现子系统的功能；子系统并不知道外观（又称为门面）的存在，对于子系统而言，外观角色仅仅是另一个客户端而已。

 

三、优点

对客户端屏蔽了子系统组件，减少了客户端需要处理的对象数量并且使得子系统使用起来更加容易。

实现了子系统与客户端之间松耦合。

提供了一个访问子系统的统一入口，并不影响客户端直接使用子系统。

 

四、缺点

使用合适的情况下没有什么问题

 

五、应用场景

想要为访问一系列复杂的子系统提供一个统一的简单入口

客户端与多个子系统之间存在很大的依赖性，引入外观类可以将子系统和客户端解耦

在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系

 

六、个人总结

1、这个模式特别容易，这也是经常被使用的一种模式，很多时候我们都在使用，只是你可能还不知道它的名字而已。

2、通过一个外观从而让访问者可以避免直接访问过多子系统的接口，可以直接通过访问外观就能达到最终的目的。

3、如果你写过J2EE的项目，很多时候我们使用service调用多个dao达到目的，从另一个角度讲，service就是一种外观。

4、与适配器模式对比：

适配器模式是把一个原来无法访问的接口，通过适配让客户端能进行访问。

外观模式原来的接口可以正常的访问，只是封装了一个更简单的接口从而方便客户端的访问。

 

 

参考博客：http://www.cnblogs.com/edisonchou/p/7124069.html