外观模式

我个人还是比较喜欢玩的，但是考虑资金问题，所以穷游居多。之前一般和三五好友约游，后来去的远了就和户外团队一起出去，我们用一个城市的旅游业来模拟一下旅游的应用场景：一个城市有N个（假设有2个）旅游景点需要门票，去这个城市的交通有M种（假设只有火车和飞机），租不同类型装备的门店有Q种（假设只有租登山用具和滑雪用具两种店），酒店有P个（假设只有两个五星级酒店），那么如果你想自己规划旅游行程要怎么做呢？

这是类结构图，每一个应用场景（驴友）都会根据实际情况有选择的依赖部分类，这样被依赖者接口发生变化，依赖者都要变化，耦合度大大增加，那么怎么解耦呢？

 

其实可以把这个城市的旅游业想象成一个子系统，为上层应用场景提供旅游服务。其实上层应用场景（驴友）可以完全不用考虑系统中每一个类的调用细节，可以为这个子系统做进一步封装，同时提供一个层更高的接口，我们把这种类叫做门面类（或外观类），而应用场景只需要与此门面类交互即可。现实中，当地旅行社即提供此职责，如果我不想自己规划旅游行程，那我就去找旅行社，告诉他我可以接受的价位，都想玩什么，其他询价等工作就不用你去操心了。

 

外观模式：为子系统的一组接口提供一个一致的界面，并定义高层接口，用来简化对此子系统的访问。

 

特征：

一、子系统，此模式多用在子系统与子系统之间的交互上，用来实现层与层之间的解耦，是高内聚低耦合的一种体现。

 

实现：

   一、 Facade门面角色

                客户端可以调用这个角色的方法。此角色知晓子系统的所有功能和责任。一般情况下,本角色会将所有从客户端发来的请求委派到相应的子系统去,也就说该角色没有实际的业务逻辑,只是一个委托类。

  二、subsystem子系统角色

                可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类,而是一个类的集合。子系统并不知道门面的存在。对于子系统而言,门面仅仅是另外一个客户端而已。

 

上面的旅行的例子，我们使用外观模式实现如下：