标签：外观 Java Pattern 模式 接口 设计模式 子系统 客户端

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

一、组合模式介绍

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 代码实现

三、源码分析

暂无，后续再更新！

完结！

标签：外观,Java,Pattern,模式,接口,设计模式,子系统,客户端
来源： https://blog.csdn.net/weixin_44299027/article/details/120266048

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。