外观模式(Facade Pattern)
外观模式( Facade Pattern), 也叫门面模式, 外观模式的原始定义是：为子系统中的一组接口提供统一的接口。它定义了一个更高级别的接口, 使子系统更易于使用。
外观模式, 是一种通过为多个复杂的子系统提供一个一致的接口, 而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口, 外部应用程序不用关心内部子系统的具体的细节, 这样会大大降低应用程序的复杂度, 提高了程序的可维护性。
门面模式有点类似之前讲到的迪米特法则（最少知识原则）和接口隔离原则：两个有交互的系统, 只暴露有限的必要的接口
意图: 为子系统中的一组接口提供一个一致的界面, 外观模式定义了一个高层接口, 这个接口使得这一子系统更加容易使用;
主要解决: 降低访问复杂系统的内部子系统时的复杂度, 简化客户端之间的接口;
UML类图
代码实例
例: 一个做饭流程, 包括: 买菜, 切菜, 煮饭, 炒菜等一系列复杂的流程
//找 蔬菜商 买菜
VegVendor vv = new VegVendor();
vv.sell();
//找刀子 切菜
Knife kn = new Knife();
kn.process();
//找厨师 煮饭, 炒菜
Chef chef = new Chef();
...
何不封装成一个对象, 组成门面提供一个一致对外的方法, 不必考虑内部子部件, 子系统复杂的逻辑关系;
public class Facade {VegVendor vv;Knife kn;Chef chef;Facade(){this.vv = new VegVendor();this.kn = new Knife();this.chef = new Chef();}//提供'做饭' 一致对外的方法public void cook(){vv.sell();kn.process();....}
}
测试
mian(){Facade facade = new Facade();facade.cook();
}
外观模式(Facade Pattern) 总结
关键角色
- 子系统(多个)
- 门面(组合多个子系统, 提供统一对外的方法提供服务)
外观模式的优缺点
外观模式的优点:
- 它对客户端屏蔽了子系统组件, 减少了客户端所需要处理的对象数目, 并使子系统使用起来更加的容易.通过引入外观模式, 客户端代码将变得很简单, 与之关联的对象也很少.
- 它实现了子系统与客户端之间的松耦合关系, 这使得子系统的变化不会影响到调用它的客户端, 只需要调整外观类即可
- 一个子系统的修改对其他子系统没有任何影响, 而子系统内部变化也不会影响到外观对象.
外观模式缺点:
- 不能很好的控制客户端直接使用子系统类, 如果客户端访问子系统类做太多的限制则减少了可变性和灵活性.
- 如果设计不当, 增加新的子系统可能需要修改外观类的源代码, 违背了开闭原则.
外观模式的适用场景
- 简化复杂系统。 比如, 当我们开发了一整套的电商系统后（包括订单、商品、支付、会员等系统）, 我们不能让用户依次使用这些系统后才能完成商品的购买, 而是需要一个门户网站或手机 App 这样简化过的门面系统来提供在线的购物功能。
- 减少客户端处理的系统数量。 比如, 在 Web 应用中, 系统与系统之间的调用可能需要处理 Database 数据库、Model 业务对象等, 其中使用 Database 对象就需要处理打开数据库、关闭连接等操作, 然后转换为 Model 业务对象, 实在是太麻烦了。如果能够创建一个数据库使用的门面（其实就是常说的 DAO 层）, 那么实现以上过程将变得容易很多。
- 让一个系统（或对象）为多个系统（或对象）工作。 比如, 线程池 ThreadPool 就是一个门面模式, 它为系统提供了统一的线程对象的创建、销毁、使用等。
- 联合更多的系统来扩展原有系统。 当我们的电商系统中需要一些新功能时, 比如, 人脸识别, 我们可以不需要自行研发, 而是购买别家公司的系统来提供服务, 这时通过门面系统就能方便快速地进行扩展。
- 作为一个简洁的中间层。 门面模式还可以用来隐藏或者封装系统中的分层结构, 同时作为一个简化的中间层来使用。比如, 在秒杀、库存、钱包等场景中, 我们需要共享有状态的数据时（如商品库存、账户里的钱）, 在不改变原有系统的前提下, 通过一个中间的共享层（如将秒杀活动的商品库存总数统一放在 Redis 里）, 就能统一进行各种服务（如, 秒杀详情页、商品详情页、购物车等）的调用。