文章目录
🙊 前言：本文章为瑞_系列专栏之《23种设计模式》的外观模式篇。本文中的部分图和概念等资料，来源于博主学习设计模式的相关网站《菜鸟教程 | 设计模式》和《黑马程序员Java设计模式详解》，特此注明。本文中涉及到的软件设计模式的概念、背景、优点、分类、以及UML图的基本知识和设计模式的6大法则等知识，建议阅读 《瑞_23种设计模式_概述》
本系列 - 设计模式 - 链接：《瑞_23种设计模式_概述》
⬇️本系列 - 创建型模式 - 链接🔗单例模式：《瑞_23种设计模式_单例模式》
工厂模式：《瑞_23种设计模式_工厂模式》
原型模式：《瑞_23种设计模式_原型模式》
抽象工厂模式：《瑞_23种设计模式_抽象工厂模式》
建造者模式：《瑞_23种设计模式_建造者模式》⬇️本系列 - 结构型模式 - 链接🔗
代理模式：《瑞_23种设计模式_代理模式》
适配器模式：《瑞_23种设计模式_适配器模式》
装饰者模式：《瑞_23种设计模式_装饰者模式》
桥接模式：《瑞_23种设计模式_桥接模式》
外观模式：《瑞_23种设计模式_外观模式》
组合模式：《瑞_23种设计模式_组合模式》
享元模式：《瑞_23种设计模式_享元模式》⬇️本系列 - 行为型模式 - 链接🔗
模板方法模式：《瑞_23种设计模式_模板方法模式》
策略模式：《瑞_23种设计模式_策略模式》
命令模式：《瑞_23种设计模式_命令模式》
职责链模式：《瑞_23种设计模式_职责链模式》
状态模式：《瑞_23种设计模式_状态模式》
观察者模式：《瑞_23种设计模式_观察者模式》
中介者模式：《瑞_23种设计模式_中介者模式》
迭代器模式：《瑞_23种设计模式_迭代器模式》
访问者模式：《瑞_23种设计模式_访问者模式》
备忘录模式：《瑞_23种设计模式_备忘录模式》
解释器模式：《瑞_23种设计模式_解释器模式》
1 外观模式（Facade Pattern）
外观模式（Facade Pattern）隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性。
瑞：结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者釆用组合或聚合来组合对象。由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象结构型模式比类结构型模式具有更大的灵活性。
这种模式涉及到一个单一的类，该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。
1.1 介绍
-
意图：为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
-
主要解决：降低访问复杂系统的内部子系统时的复杂度，简化客户端之间的接口。
-
何时使用：
1️⃣ 客户端不需要知道系统内部的复杂联系，整个系统只需提供一个"接待员"即可。
2️⃣ 定义系统的入口。 -
如何解决：客户端不与系统耦合，外观类与系统耦合。
-
关键代码：在客户端和复杂系统之间再加一层，这一层将调用顺序、依赖关系等处理好。
-
应用实例：
1️⃣ 去医院看病，可能要去挂号、门诊、划价、取药，让患者或患者家属觉得很复杂，如果有提供接待人员，只让接待人员来处理，就很方便。
2️⃣ JAVA 的三层开发模式。
瑞：JAVA的三层开发模式通常指的是将应用程序划分为三个主要部分：表示层（Presentation Layer）、业务逻辑层（Business Logic Layer）和数据访问层（Data Access Layer）
-
优点：
1️⃣ 减少系统相互依赖。
2️⃣ 提高灵活性。
3️⃣ 提高了安全性。 -
缺点：不符合开闭原则，如果要改东西很麻烦，继承重写都不合适。
-
使用场景：
1️⃣ 为复杂的模块或子系统提供外界访问的模块。
2️⃣ 子系统相对独立。
3️⃣ 预防低水平人员带来的风险。 -
注意事项：在层次化结构中，可以使用外观模式定义系统中每一层的入口。
1.2 概述
定义：又名门面模式，是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体的细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。
有些人可能炒过股票，但其实大部分人都不太懂，这种没有足够了解证券知识的情况下做股票是很容易亏钱的，刚开始炒股肯定都会想，如果有个懂行的帮帮手就好，其实基金就是个好帮手，支付宝里就有许多的基金，它将投资者分散的资金集中起来，交由专业的经理人进行管理，投资于股票、债券、外汇等领域，而基金投资的收益归持有者所有，管理机构收取一定比例的托管管理费用。
瑞：外观模式是“迪米特法则”的典型应用。"迪米特法则"是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立
外观（Facade）模式用图片描述如下：
1.3 外观模式的结构
- 外观（Facade）模式包含以下主要角色：
1️⃣ 外观（Facade）角色：为多个子系统对外提供一个共同的接口。
2️⃣ 子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。
2 案例一
【案例】智能家电控制
2.1 需求
小明的爷爷已经60岁了，一个人在家生活：每次都需要打开灯、打开电视、打开空调；睡觉时关闭灯、关闭电视、关闭空调；操作起来都比较麻烦。所以小明给爷爷买了智能音箱，可以通过语音直接控制这些智能家电的开启和关闭。类图如下：
2.2 代码实现
/**
* 电灯类
*
* @author LiaoYuXing-Ray
**/
public class Light {
//开灯
public void on() {
System.out.println("打开电灯。。。。");
}
//关灯
public void off() {
System.out.println("关闭电灯。。。。");
}
}
/**
* 电视机类
*
* @author LiaoYuXing-Ray
**/
public class TV {
public void on() {
System.out.println("打开电视机。。。。");
}
public void off() {
System.out.println("关闭电视机。。。。");
}
}
/**
* 空调类
*
* @author LiaoYuXing-Ray
**/
public class AirCondition {
public void on() {
System.out.println("打开空调。。。。");
}
public void off() {
System.out.println("关闭空调。。。。");
}
}
/**
* 外观类，用户主要和该类对象进行交互
*
* @author LiaoYuXing-Ray
**/
public class SmartAppliancesFacade {
// 聚合电灯对象，电视机对象，空调对象
private final Light light;
private final TV tv;
private final AirCondition airCondition;
public SmartAppliancesFacade() {
light = new Light();
tv = new TV();
airCondition = new AirCondition();
}
// 通过语言控制
public void say(String message) {
if(message.contains("打开")) {
on();
} else if(message.contains("关闭")) {
off();
} else {
System.out.println("我还听不懂你说的！！！");
}
}
// 一键打开功能
private void on() {
light.on();
tv.on();
airCondition.on();
}
// 一键关闭功能
private void off() {
light.off();
tv.off();
airCondition.off();
}
}
/**
* 测试类
*
* @author LiaoYuXing-Ray
**/
public class Client {
public static void main(String[] args) {
// 创建智能音箱对象
SmartAppliancesFacade facade = new SmartAppliancesFacade();
// 控制家电
facade.say("打开家电");
System.out.println("==================");
facade.say("关闭家电");
}
}
代码运行结果如下：
打开电灯。。。。
打开电视机。。。。
打开空调。。。。
==================
关闭电灯。。。。
关闭电视机。。。。
关闭空调。。。。
好处：
- 降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。
- 对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。
缺点：
- 不符合开闭原则，修改很麻烦
使用场景：
- 对分层结构系统构建时，使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
- 当一个复杂系统的子系统很多时，外观模式可以为系统设计一个简单的接口供外界访问。
- 当客户端与多个子系统之间存在很大的联系时，引入外观模式可将它们分离，从而提高子系统的独立性和可移植性。
3 案例二
本案例为菜鸟教程中的案例
3.1 需求
我们将创建一个 Shape 接口和实现了 Shape 接口的实体类。下一步是定义一个外观类 ShapeMaker。
ShapeMaker 类使用实体类来代表用户对这些类的调用。FacadePatternDemo 类使用 ShapeMaker 类来显示结果。
3.2 代码实现
步骤 1
创建一个接口。
public interface Shape {
void draw();
}
步骤 2
创建实现接口的实体类。
public class Rectangle implements Shape {
@Override
public void draw() {
System.out.println("Rectangle::draw()");
}
}
public class Square implements Shape {
@Override
public void draw() {
System.out.println("Square::draw()");
}
}
public class Circle implements Shape {
@Override
public void draw() {
System.out.println("Circle::draw()");
}
}
步骤 3
创建一个外观类。
public class ShapeMaker {
private Shape circle;
private Shape rectangle;
private Shape square;
public ShapeMaker() {
circle = new Circle();
rectangle = new Rectangle();
square = new Square();
}
public void drawCircle(){
circle.draw();
}
public void drawRectangle(){
rectangle.draw();
}
public void drawSquare(){
square.draw();
}
}
步骤 4
使用该外观类画出各种类型的形状。
public class FacadePatternDemo {
public static void main(String[] args) {
ShapeMaker shapeMaker = new ShapeMaker();
shapeMaker.drawCircle();
shapeMaker.drawRectangle();
shapeMaker.drawSquare();
}
}
步骤 5
执行程序，输出结果：
Circle::draw()
Rectangle::draw()
Square::draw()
4 jdk源码解析
使用 tomcat 作为 web 容器时，接收浏览器发送过来的请求，tomcat 会将请求信息封装成 ServletRequest 对象，如下图①处对象。但是大家想想 ServletRequest 是一个接口，它还有一个子接口 HttpServletRequest ，而我们知道该 request 对象肯定是一个 HttpServletRequest 对象的子实现类对象，到底是哪个类的对象呢？可以通过输出 request 对象，我们就会发现是一个名为 RequestFacade 的类的对象。
RequestFacade类就使用了外观模式。先看结构图：
RequestFacade类使用外观模式的原因：定义 RequestFacade 类，分别实现 ServletRequest ，同时定义私有成员变量 Request ，并且方法的实现调用 Request 的实现。然后，将 RequestFacade上转为 ServletRequest 传给 servlet 的 service 方法，这样即使在 servlet 中被下转为 RequestFacade ，也不能访问私有成员变量对象中的方法。既用了 Request ，又能防止其中方法被不合理的访问。
如果觉得这篇文章对您有所帮助的话，请动动小手点波关注💗，你的点赞👍收藏⭐️转发🔗评论📝都是对博主最好的支持~
917
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
