目录

前言

　　今天一起来看看外观模式，外观模式也是我们介绍的结构型设计模式的第五个模式了。外观外表，有句话是这么说的人靠衣装 佛靠金装。打扮的好，整理的好。外观靠上去整整齐齐，精气神一下就上来了。在开发中依然如此。客户端完成一个功能，可能需要调用许多的接口来配合。按照开发逻辑一个一个依次对接下来。客户端代码复杂，看上去一团糟。不说其他的，就表面上看起来就不怎么好吧。那么不如我们把调用的接口进行再次的封装。统一规范。这样整理下来。客户端就明了多了。

外观模式介绍

一、来由

　　在软件系统开发中，我们经常会遇到客户端与内部子系统进行负责耦合的情况。从而导致客户端随着子系统的变化而变化。为了解决客户端与子系统直接的高耦合，并且简化接口的调用。也就有了外观模式。

二、意图

　　为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

三、案例图

四、外观模式代码示例

　　看上面我们发现外观模式包含以下角色：

　　　　外观角色：在客户端调用外观角色的方法，其中与一个或多个子系统相关联。在运行情况下，客户端请求传递到外观角色然后传递给对应的子系统。

　　　　子系统：在软件系统中包含一个或者多个子系统，子系统可以单独被客户端调用，子系统不知道外观角色的存在。相对而言，也可以当外观角色为客户端。

　　我们看这么一个案例，通过案例我们来详细了解外观模式到底是怎么一回事以及如何运行的。例如我们现在有的软件系统。新用户在输入手机号填入验证码就登录注册都搞定了。同时还附加了一些第一次登录注册的奖励。如果不按外观模式来的话，我们在登录按钮后面的客户端依次调用了注册、登录、赠送奖励等等方法。那么我们看看外观模式如何解决呢：

namespace Facade_Pattern {