这种类型的设计模式属于结构型模式。

一、组合模式介绍

1.1 含义

外观模式（Facade Pattern）隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性。

这种模式涉及到一个单一的类，该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。

在日常编码工作中，我们都在有意无意的大量使用外观模式。只要是上层模块需要调度多个子系统（2个以上的类对象），我们都会自觉地创建一个新的类封装这些子系统，提供精简的接口，让上层模块可以更加容易地间接调用这些子系统的功能。

例如现阶段各种第三方SDK、开源类库，很多都会使用外观模式。

1.2 适用场景

① 为复杂的模块或子系统提供外界访问的模块或者接口。

② 子系统相对独立，外界对子系统的访问只要黑箱操作即可。

③ 预防低水平人员带来的风险。

1.3 主要解决

降低访问复杂系统的内部子系统时的复杂度，简化客户端之间的接口。

关键代码：在客户端和复杂系统之间再加一层，这一层将调用顺序、依赖关系等处理好。

1.4 应用实例

① JAVA 的三层开发模式；

② 基金（用户只和基金打交道，实际操作为基金经理人与股票和其它投资品打交道）；

③ 去医院看病，可能要去挂号、门诊、划价、取药，让患者或患者家属觉得很复杂，如果有提供接待人员，只让接待人员来处理，就很方便。

④ 最原始的写信，先写信的内容，然后写信封，然后把信放到信封中，封好，投递到信箱中进行邮递；

1.5 优缺点

外观（Facade）模式是“迪米特法则”的典型应用，其优点有：

① 减少系统相互依赖，降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。

② 提高灵活性，对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。

③ 提高了安全性，降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象。

缺点：

① 不符合开闭原则，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”，继承重写都不合适。

② 不能很好地限制客户使用子系统类，很容易带来未知风险。

注意事项：在层次化结构中，可以使用外观模式定义系统中每一层的入口。

二、组合模式实现

所有设计模式的代码实现例子都可在码云上查看哦，感兴趣的可以查看哈，码云地址：https://gitee.com/no8g/java-design-patterns

2.1 类图

2.2 角色分析

外观（Facade）角色：为多个子系统对外提供一个共同的接口。

子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。

客户（Client）角色：通过一个外观角色访问各个子系统的功能。

外观（Facade）模式的结构比较简单，主要是定义了一个高层接口。它包含了对各个子系统的引用，客户端可以通过它访问各个子系统的功能。

2.3 代码实现

三、源码分析

暂无，后续再更新！

完结！