前言
分析
1.一个客户类需要和多个业务类交互,而这些需要交互的业务类经常会作为一个整体
2.引入一个新的外观类(Facade)来负责和多个业务类子系统( Subsystem)进行交互,而客户类只需与外观类交互
3.为多个业务类的调用提供了一个统一的入口,简化了类与类之间的交互
4.没有外观类:每个客户类需要和多个子系统之间进行复杂的交互,系统的耦合度将很大。
5.引入外观类:客户类只需要直接与外观类交互,客户类与子系统之间原有的复杂引用关系由外观类来实现从而降低了系统的耦合度。
系统的外部与其内部的通信通过一个统一的外观类进行,外观类将客户类与子系统的内部复杂性分隔开,使得客户类只需要与外观角色打交道,而不需要与子系统内部的很多对象打交
1.外观模式定义
系统中的一组接口提供一个统一的入口观模式定义了一个高层接口这个使得这一子系统更容易使用
1.又称为门面模式
2.是迪米特法则的一种具体实现
3.通过引入一个新的外观角色来降低原有系统的复杂度,同时降低客户类与子系统的耦合度
4.所指的子系统是一个广义的概念,它可以是一个类,一个功能模块,系统的一个组成部分或者一个完整的系统
2.外观模式的结构与实现
外观模式包含以下2个角色
Facade(外观角色)
Subsystem(子系统角色)
实例说明
某软要开发应用于多个软件的文件加密模块,该模块文件中的数据进行加密并将加密之后的数据存储在一个新文件中,具体的流程包括3个部分,分别是读取源文件、加密、保存加密之后的文件，其中,读取文件和保存文件使用流来实现,加密操作通过求模运算实现.这3个操作相对独立,为了实现代码的独立重用,让设计更符合单一职责原则,这3个操作的业务代码封装在3个不同的类中.
现使用外观模式设计该文件加密模块
