2023-6-27-第九式外观模式

简介: 2023-6-27-第九式外观模式

😉一、基础概念

外观模式(Facade Pattern)是一种结构型设计模式,它提供了一个高层次的统一接口,用来简化一组子系统的使用。外观模式隐藏了子系统的复杂性,使得客户端能够更加方便地使用子系统功能,同时也降低了客户端与子系统之间的耦合度

在外观模式中,外观类(Facade Class)充当了客户端与子系统之间的中介,它向客户端提供了一个简单的接口,同时协调并调用子系统中的各个组件完成特定的功能。客户端只需要通过外观类使用子系统,而无需理解其具体实现细节。

外观模式的主要优点包括:

1.简化了客户端的调用过程,降低了客户端的学习成本和使用成本;

2.减少了客户端与各个子系统之间的耦合,提高了系统的灵活性和可维护性;

3.使得子系统内部的变化和修改不会影响到客户端的使用;

4.便于扩展子系统和修改子系统中的功能。

外观模式在实际编程中经常被用到,例如,一个复杂的操作系统的 API 就可以实现为一个外观类,而具体的系统调用则由子系统实现。在使用操作系统的时候,用户只需要调用外观类中的方法,而不用去关心具体的系统调用。


🐱‍🐉二、外观模式实现

以下是一个简单的 C++ 外观模式实现示例:

#include <iostream>
using namespace std;
// 子系统接口1
class Subsystem1 {
public:
    void Operation1() {
        cout << "Subsystem1 Operation1" << endl;
    }
};
// 子系统接口2
class Subsystem2 {
public:
    void Operation2() {
        cout << "Subsystem2 Operation2" << endl;
    }
};
// 外观类
class Facade {
public:
    void Operation() {
        subsystem1.Operation1();
        subsystem2.Operation2();
        cout << "Facade Operation" << endl;
    }
private:
    Subsystem1 subsystem1;
    Subsystem2 subsystem2;
};
// 客户端代码
int main() {
    Facade facade;
    facade.Operation();
    return 0;
}

在上述代码中,Subsystem1 和 Subsystem2 分别表示两个子系统,它们各自实现了自己的功能。而 Facade 则充当了这两个子系统的外观类,它提供了一个 Operation() 接口,将 Subsystem1 和 Subsystem2 的操作整合在一起,从而向客户端提供了一个简单的接口。当客户端需要使用 Subsystem1 和 Subsystem2 时,只需要调用 Facade 类的 Operation() 方法即可。

在实际编程中,外观模式可以适用于很多场景,例如,一个电视机的遥控器就是一个外观模式,用户只需要通过遥控器的按钮来控制电视机,而不用了解电视机内部的电路原理和具体操作。


🎉三、模块之间的关系

外观模式主要用于简化复杂系统的使用和维护,将子系统的多个模块组合起来提供一个更加简单、易于使用的接口给客户端使用。在外观模式中,各个子系统之间的关系是相互独立的,由外观类来协调他们之间的通信,实现系统的组装和解耦。

在外观模式中,子系统之间的关系是通过外观类来建立的。外观类封装了多个子系统之间的复杂关系,在外观类中提供一个简单的接口供客户端使用。客户端只需要通过外观类来访问各个子系统即可,而不必关心子系统之间的复杂关系。

通常情况下,子系统之间通过直接调用的方式来进行交互。外观类将多个子系统整合起来,对外提供一个更简单的接口。这种组合和解耦的方式使得系统更加易于扩展和维护,同时也提高了系统的灵活性和可维护性。

总的来说,外观模式实现了子系统之间的松耦合,提高了系统的可维护性和可扩展性,同时也为客户端提供了更友好、易于使用的接口。


🐱‍🚀四、注意事项

在使用外观模式时,需要注意以下几个方面:

  1. 对于多层次的系统,需要设计合适的外观类来对系统进行整合。外观类应该尽可能简单,只提供必要的接口给客户端使用。
  2. 外观模式并不限制系统中子系统的使用方式,对于不同的子系统可以采用不同的访问方式。例如,有些子系统可能需要经过复杂的初始化和配置过程才能使用,而有些子系统则可以直接访问。
  3. 外观模式可以用来解决多个子系统间相互依赖而引起的循环依赖问题。但是,需要注意控制外观类的复杂度,避免过多的子系统依赖导致外观类变得臃肿不易维护。
  4. 在设计外观类时,需要尽可能避免暴露子系统底层的实现细节,保证客户端无需了解子系统的具体实现就能够直接使用。
  5. 外观模式本质上是将复杂的系统从客户端中抽象出来,因此需要考虑到系统的发展变化、用户需求等因素,设计出具有弹性和可扩展性的系统。

总之,在使用外观模式时需要根据实际情况进行设计和调整,使得系统的内部子系统能够更加灵活、简单、易于维护和扩展。


🎂五、使用场景

外观模式适用于以下场景:

  1. 系统复杂,包含多个子系统且子系统之间存在相互依赖关系,需要提供一个统一的接口给客户端使用。
  2. 不同子系统的接口复杂度不同,客户端需要通过一个简单的接口访问这些子系统。
  3. 需要改变或替换系统中的子系统时,外观模式可以降低重构的难度和影响范围。
  4. 需要减少客户端与子系统之间的耦合度,从而降低客户端代码的复杂度。

具体的应用场景包括:

  1. 操作系统的API或Windows的API就是一种外观模式,将复杂的操作系统功能抽象为简单的API接口供应用程序使用。
  2. 商城平台订单交易系统,将订单接收、处理、支付、配送的过程封装在外观类中,客户端只需调用外观类的一个接口即可完成整个订单的处理。
  3. 电影院售票系统,将座位选择、支付、票务打印等过程封装在外观类中,客户端只需调用外观类的一个接口即可完成整个购票过程。

在这些应用场景中,外观模式的作用都是将复杂的系统和子系统进行封装,提供一个更加简单易用的接口给客户端使用。这种模式可以降低客户端和子系统之间的耦合度,提高系统的可维护性和可扩展性。


🍳参考文献

🧊文章总结

提示:这里对文章进行总结:

   本文讲了关于外观模式的知识。


目录
相关文章
|
2月前
|
设计模式 缓存 算法
C#一分钟浅谈:组合模式与外观模式
【10月更文挑战第15天】本文介绍了面向对象设计模式中的组合模式和外观模式。组合模式通过树形结构表示“部分-整体”的层次关系,适用于文件系统、图形界面等场景;外观模式提供统一接口简化复杂系统的使用,适用于视频播放器等多模块系统。文章详细解释了这两种模式的基本概念、应用场景、实现方式及常见问题和解决方法,帮助读者更好地理解和应用。
43 9
|
6月前
|
设计模式 算法 关系型数据库
设计模式第七讲-外观模式、适配器模式、模板方法模式详解
系统要求所有的数据库帮助类必须实现ISqlHelp接口,面向该接口编程,如SQLServerHelp类。 此时第三方提供了一个新的MySql的帮助类(假设是dll,不能修改),它的编程规范和ISqlHelp不兼容,这个时候就需要引入适配器类,使二者能相互兼容。
181 0
|
7月前
|
前端开发
结构型 外观模式
结构型 外观模式
33 0
|
应用服务中间件 智能硬件 容器
结构型模式-外观模式
结构型模式-外观模式
87 0
|
设计模式
我学会了,外观模式
外观模式属于结构型模式,这个类型的设计模式总结出了 类、对象组合后的经典结构,将类、对象的结构和使用解耦了,花式的去借用对象。
130 0
我学会了,外观模式
门面模式 与 装饰器模式(2)
门面模式 与 装饰器模式(2)
121 0
门面模式 与 装饰器模式(2)
|
前端开发 uml
门面模式 与 装饰器模式(1)
门面模式 与 装饰器模式(1)
132 0
门面模式 与 装饰器模式(1)
|
SQL Java Linux
门面模式 与 装饰器模式(3)
门面模式 与 装饰器模式(3)
126 0
|
XML 设计模式 Java

热门文章

最新文章