“Github:https://github.com/nateshao/design-demo/tree/main/JavaDesignPatterns/13-facade
两种喝茶方式示意图
分析
没有外观类:每个客户类需要和多个子系统之间进行复杂的交互,系统的耦合度将很大
引入外观类 :客户类只需要直接与外观类交互,客户类与子系统之间原有的复杂引用关系由外观类来实现,从而降低了系统的耦合度
一个子系统的外部与其内部的通信通过一个统一的外观类进行,外观类将客户类与子系统的内部复杂性分隔开,使得客户类只需要与外观角色打交道,而不需要与子系统内部的很多对象打交道
为复杂子系统提供一个简单的访问入口
外观模式的定义
“外观模式:为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
对象结构型模式
外观模式的结构
外观模式包含以下2个角色:
Facade
(外观角色)SubSystem
(子系统角色)子系统类典型代码:
public class SubSystemA {
public void methodA() {
//业务实现代码
}
}
public class SubSystemB {
public void methodB() {
//业务实现代码
}
}
public class SubSystemC {
public void methodC() {
//业务实现代码
}
}
外观类典型代码:
public class Facade {
private SubSystemA obj1 = new SubSystemA();
private SubSystemB obj2 = new SubSystemB();
private SubSystemC obj3 = new SubSystemC();
public void method() {
obj1.method();
obj2.method();
obj3.method();
}
}
客户类典型代码:
public class Client {
public static void main(String args[]) {
Facade facade = new Facade();
facade.method();
}
}
实例说明
“某软件公司要开发一个可应用于多个软件的文件加密模块,该模块可以对文件中的数据进行加密并将加密之后的数据存储在一个新文件中,具体的流程包括3个部分,分别是读取源文件、加密、保存加密之后的文件,其中,读取文件和保存文件使用流来实现,加密操作通过求模运算实现。这3个操作相对独立,为了实现代码的独立重用,让设计更符合单一职责原则,这3个操作的业务代码封装在3个不同的类中 现使用外观模式设计该文件加密模块。
实例类图
实例代码
FileReader
:文件读取类,充当子系统类CipherMachine
:数据加密类,充当子系统类FileWriter
:文件保存类,充当子系统类EncryptFacade
:加密外观类,充当外观类Client
:客户端测试类“动机:在标准的外观模式的结构图中,如果需要增加、删除或更换与外观类交互的子系统类,必须修改外观类或客户端的源代码,这将违背开闭原则,因此可以通过引入抽象外观类对系统进行改进,在一定程度上解决该问题
结构:
代码实现
将外观类改造成为单例类
模式优点
模式缺点
模式适用环境