设计模式的艺术-外观模式

结构性模式的名称、定义、学习难度和使用频率如下表所示：

外观类充当了软件系统中的"服务员"，它为多个业务类的调用提供了一个统一的入口，简化了类与类之间的交互。
外观模式（Facade Pattern）：外部与一个子系统的通信通过一个统一的外观角色进行，为子系统中的一组接口提供一个一致的入口
外观模式又称为门面模式 ，它是一种对象结构型模式
外观模式的主要目的在于降低系统的复杂程度。在面向对象软件系统中，类与类之间的关系越多，并不能表示系统设计得越好，反而表示系统中类之间的耦合度太大，这样的系统在维护和修改时都缺乏灵活性，因为一个类的改动会导致多个类发生变化。
外观模式是一种使用频率非常高的设计模式，它通过引入一个外观角色来简化客户端与子系统之间的交互，为复杂的子系统调用提供一个统一的入口，使子系统与客户端的耦合度降低，且客户端调用非常方便。
在几乎所有的软件中都能够找到外观模式的应用，例如，绝大多数B/S系统都有一个首页或者导航页面，大部分C/S系统都提供了菜单或者工具栏。在这里，首页和导航页面就是B/S系统的外观角色，而菜单和工具栏就是C/S系统的外观角色，通过它们，用户可以快速访问子系统，降低了系统的复杂程度。

在很多情况下为了节约系统资源，系统中只需要一个外观类的实例。
在一个系统中可以设计多个外观类，每个外观类都负责和一些特定的子系统交互，向客户端提供相应的业务功能，例如在一个电商系统中可以设计一个订单处理外观类，主要和订单管理子系统、支付子系统等交互，为客户端提供下单、支付、查看订单状态等功能，同时还可以设计一个用户相关操作外观类专门负责与用户管理子系统和部分相关的其他子系统进行交互，为客户端提供诸如用户注册、登录、个人信息修改等业务功能。
如果我们想要增加新的行为，比如在购物流程中添加一个积分计算的步骤，应该是在子系统内部的相关模块中添加这个新的积分计算的功能，比如在订单处理模块中修改代码实现积分计算，或者创建一个新的专门用于积分计算的子系统类，并在外观类调用的内部逻辑中整合这个新的子系统。

优点
1. 简化了客户端的使用：客户端不再需要了解子系统内部的复杂结构和交互关系，只需要与外观类进行交互，降低了使用难度。
2. 减少了系统的相互依赖：子系统之间的依赖关系被隐藏在外观类之后，降低了子系统之间的耦合度。
3. 提高了代码的可维护性

缺点
1. 不符合开闭原则：如果要修改外观类的接口或者功能，可能需要修改外观类的代码，这可能会影响到所有依赖于该外观类的客户端。
2. 可能限制了功能的灵活性：某些情况下，外观类提供的统一接口可能无法满足某些特殊的需求，需要直接访问子系统。

当子系统较为复杂，而客户端需要一个简单的接口来与之交互时。比如一个包含多个复杂算法和数据结构的图像处理库，为客户端提供一个简洁的外观类来执行常见的图像处理操作，如裁剪、旋转、调整亮度等。
当多个子系统之间存在紧密的交互关系，需要协调它们的工作时。外观类可以封装这种协调逻辑，使客户端无需关心具体的协调过程。
例如在银行系统中，可以创建一个外观类 "BankFacade"。这个外观类提供了一系列经过精心设计和控制的方法，例如 "开户"、"存款"、"取款"、"转账"等。在这些方法内部，会按照正确的顺序和规则调用各个子系统的方法，并处理可能出现的异常情况。客户端只能通过这些方法来操作银行系统，而不能直接访问子系统。

以上内容为根据书本内容配合搜索引擎整理得来，目的是为了学习，要是有侵权的情况发生，请联系我，我会立即予以删除，谢谢！

一起成长，人生是马拉松，可以跑得慢，但一定要在路上。