设计模式-06 设计模式-Facade Pattern门面模式

2024-05-09 02:04

本文主要是介绍设计模式-06 设计模式-Facade Pattern门面模式,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

设计模式-06 设计模式-Facade Pattern门面模式

1.定义


门面模式(Facade Pattern)定义

门面模式为一个子系统提供了一个统一的接口,从而简化了对该子系统中多个组件的访问。

它通过为客户端提供一个单一的入口点来隐藏子系统的复杂性,从而使客户端能够以更简单的方式与子系统交互。

门面模式结构

Facade(门面):这是一个包装类,提供了一个简化的接口来访问子系统。
Subsystem(子系统):这是门面模式表示的实际子系统。它由多个组件组成,这些组件共同提供一些功能。


门面模式工作原理

客户端通过门面类与子系统进行交互。门面类将客户端的请求委派给适当的子系统组件,并处理子系统之间的交互。

通过这种方式,客户端不必了解子系统的内部复杂性,从而简化了与子系统的交互。


2.内涵

门面模式(Facade Pattern)的内涵:

  • 抽象和封装:门面模式抽象了子系统的复杂性,为客户端提供了一个简化的接口。它封装了子系统中的组件,使客户端不必了解这些组件的内部工作原理。
  • 解耦:门面模式将客户端与子系统解耦,使客户端和子系统可以独立开发和维护。这提高了代码的可维护性和可测试性,因为更改子系统不会影响客户端代码。
  • 灵活性:门面模式提供了灵活性,允许在不影响客户端代码的情况下更改子系统。当需要添加或删除组件或更改子系统的行为时,这非常有用。
  • 控制和安全性:门面模式可以充当控制和安全层,仅允许经过授权的客户端访问子系统。它还可以隐藏子系统中的敏感信息或操作。
  • 可扩展性:门面模式支持可扩展性,允许在需要时轻松地添加新的子系统或功能。客户端代码不需要修改,只需更新门面类即可。

门面模式的内涵还包括:

  • 单一职责原则:门面类只负责提供一个简化的接口,而子系统负责实现实际功能。这符合单一职责原则,使代码更易于理解和维护。
  • 依赖反转原则:门面模式通过将依赖关系反转到门面类来实现依赖反转原则。客户端依赖于门面类,而不是具体的子系统组件。
  • 开放-封闭原则:门面模式遵循开放-封闭原则,允许在不修改客户端代码的情况下扩展子系统。
  • 总体而言,门面模式的内涵在于提供一个简化、解耦、灵活、可控和可扩展的接口来访问复杂子系统。
3.使用示例
#include <iostream>// Subsystem 1
class Engine {
public:void Start(){std::cout << "Engine started" << std::endl;}void Stop(){std::cout << "Engine stopped" << std::endl;}
};// Subsystem 2
class Lights {
public:void TurnOn() { std::cout << "Lights on" << std::endl; }void TurnOff(){std::cout << "Lights off" << std::endl;}
};// Facade
class Car {
private:Engine engine;Lights lights;public:void StartCar(){engine.Start();lights.TurnOn();std::cout << "Car is ready to drive" << std::endl;}void StopCar(){lights.TurnOff();engine.Stop();std::cout << "Car has stopped" << std::endl;}
};int main()
{// Using the Facade to start and stop the carCar car;car.StartCar();// Simulate some drivingcar.StopCar();return 0;
}

4.注意事项

使用门面模式时需要注意以下事项:

  • 过度封装:避免过度封装子系统,以至于隐藏了重要的功能或使客户端难以访问所需的特性。
  • 性能开销:门面模式在客户端和子系统之间添加了一层间接,这可能会引入额外的性能开销。在对性能要求较高的场景中,需要考虑这一点。
  • 灵活性受限:门面模式可能会隐藏子系统的一些功能,从而限制了客户端的灵活性。如果需要对子系统进行精细的控制,则可能不适合使用门面模式。
  • 复杂性:当需要处理多个子系统或复杂的交互时,门面模式可能会增加复杂性。在这种情况下,可能需要考虑其他设计模式,例如中介者模式或观察者模式。
  • 测试困难:门面模式可能会使测试变得困难,因为客户端代码依赖于门面类而不是直接与子系统交互。需要仔细考虑测试策略以确保子系统功能的正确性。


此外,还需要注意以下几点:

  • 门面模式不适合所有场景:门面模式最适合于子系统复杂且与客户端交互频繁的情况。
  • 门面类需要精心设计:门面类的接口应简洁且易于使用,同时还应提供对子系统功能的足够访问。
  • 避免创建上帝对象:门面类不应成为一个庞大的上帝对象,负责处理所有与子系统的交互。它应该只提供一个简化的接口,而子系统应该负责实现实际功能。
  • 总体而言,门面模式是一种有用的设计模式,但重要的是要了解其注意事项并在适当的情况下使用它。
5.最佳实践


发挥门面模式长处的技巧:

  • 仔细选择要封装的子系统:门面模式最适合于封装复杂、相互依赖的子系统。选择与客户端交互频繁且具有复杂接口的子系统。
  • 提供一个简洁易用的接口:门面类的接口应该清晰简洁,易于客户端使用。避免暴露子系统的内部细节,只提供与客户端相关的高级操作。
  • 保持灵活性:门面模式应该允许客户端在不修改客户端代码的情况下扩展或修改子系统。通过使用抽象类或接口来定义门面接口,可以实现这种灵活性。
  • 关注核心功能:门面类应该专注于提供对子系统核心功能的访问。避免在门面类中添加不必要的逻辑或功能,因为这会增加复杂性和降低可维护性。
  • 利用依赖反转:通过将对子系统的依赖关系反转到门面类,可以提高代码的可测试性和可维护性。客户端代码应该依赖于门面接口,而不是具体的子系统组件。
  • 谨慎处理性能开销:门面模式在客户端和子系统之间添加了一层间接,这可能会引入额外的性能开销。在对性能要求较高的场景中,需要仔细考虑门面模式的引入。


其他发挥门面模式长处的技巧:

  • 使用门面模式隐藏子系统的变化:当需要更改子系统的实现时,门面模式可以作为缓冲层,使客户端代码不受影响。
  • 简化客户端与子系统的交互:门面模式可以简化客户端与子系统的交互,使其更容易使用和维护。
  • 提高可测试性:通过将对子系统的依赖关系反转到门面类,可以提高子系统功能的测试性。
  • 促进代码重用:门面模式可以促进代码重用,因为门面类可以被多个客户端共享。
  • 通过遵循这些技巧,可以充分发挥门面模式的长处,为复杂子系统的访问提供一个简化、解耦、灵活和可扩展的接口。

6.总结

门面模式图例:

+-------------------------+|                         ||                         ||       Facade Pattern    ||                         |+-------------------------+/|\\                   /|\\|||||                   ||||||||||       ----->      ||||||||||         |         |||||\\|/                   \\|/+-----------------+| SubSystem 1     |+-----------------++-----------------+| SubSystem 2     |+-----------------++-----------------+| SubSystem 3     |+-----------------+


门面模式(Facade Pattern):一个用于简化复杂子系统访问的接口。
子系统(SubSystem):多个相互依赖的类或模块,它们共同实现一个复杂的功能。
客户端(Client):使用门面模式访问子系统的代码。
 

客户端通过门面模式与子系统交互:客户端代码只知道门面模式的接口,而不是子系统的内部细节。
门面模式将客户端请求转发给子系统:门面模式接收来自客户端的请求,并将其转发给适当的子系统。
子系统处理请求并返回响应:子系统处理请求并返回响应,门面模式将其传递回客户端。


通过使用门面模式,客户端可以与复杂子系统交互,而无需了解其内部实现。这简化了代码并提高了可维护性。
 

这篇关于设计模式-06 设计模式-Facade Pattern门面模式的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/972077

相关文章

06 C++Lambda表达式

lambda表达式的定义 没有显式模版形参的lambda表达式 [捕获] 前属性 (形参列表) 说明符 异常 后属性 尾随类型 约束 {函数体} 有显式模版形参的lambda表达式 [捕获] <模版形参> 模版约束 前属性 (形参列表) 说明符 异常 后属性 尾随类型 约束 {函数体} 含义 捕获:包含零个或者多个捕获符的逗号分隔列表 模板形参:用于泛型lambda提供个模板形参的名

在JS中的设计模式的单例模式、策略模式、代理模式、原型模式浅讲

1. 单例模式(Singleton Pattern) 确保一个类只有一个实例,并提供一个全局访问点。 示例代码: class Singleton {constructor() {if (Singleton.instance) {return Singleton.instance;}Singleton.instance = this;this.data = [];}addData(value)

模版方法模式template method

学习笔记,原文链接 https://refactoringguru.cn/design-patterns/template-method 超类中定义了一个算法的框架, 允许子类在不修改结构的情况下重写算法的特定步骤。 上层接口有默认实现的方法和子类需要自己实现的方法

【iOS】MVC模式

MVC模式 MVC模式MVC模式demo MVC模式 MVC模式全称为model(模型)view(视图)controller(控制器),他分为三个不同的层分别负责不同的职责。 View:该层用于存放视图,该层中我们可以对页面及控件进行布局。Model:模型一般都拥有很好的可复用性,在该层中,我们可以统一管理一些数据。Controlller:该层充当一个CPU的功能,即该应用程序

迭代器模式iterator

学习笔记,原文链接 https://refactoringguru.cn/design-patterns/iterator 不暴露集合底层表现形式 (列表、 栈和树等) 的情况下遍历集合中所有的元素

《x86汇编语言:从实模式到保护模式》视频来了

《x86汇编语言:从实模式到保护模式》视频来了 很多朋友留言,说我的专栏《x86汇编语言:从实模式到保护模式》写得很详细,还有的朋友希望我能写得更细,最好是覆盖全书的所有章节。 毕竟我不是作者,只有作者的解读才是最权威的。 当初我学习这本书的时候,只能靠自己摸索,网上搜不到什么好资源。 如果你正在学这本书或者汇编语言,那你有福气了。 本书作者李忠老师,以此书为蓝本,录制了全套视频。 试

利用命令模式构建高效的手游后端架构

在现代手游开发中,后端架构的设计对于支持高并发、快速迭代和复杂游戏逻辑至关重要。命令模式作为一种行为设计模式,可以有效地解耦请求的发起者与接收者,提升系统的可维护性和扩展性。本文将深入探讨如何利用命令模式构建一个强大且灵活的手游后端架构。 1. 命令模式的概念与优势 命令模式通过将请求封装为对象,使得请求的发起者和接收者之间的耦合度降低。这种模式的主要优势包括: 解耦请求发起者与处理者

springboot实战学习(1)(开发模式与环境)

目录 一、实战学习的引言 (1)前后端的大致学习模块 (2)后端 (3)前端 二、开发模式 一、实战学习的引言 (1)前后端的大致学习模块 (2)后端 Validation:做参数校验Mybatis:做数据库的操作Redis:做缓存Junit:单元测试项目部署:springboot项目部署相关的知识 (3)前端 Vite:Vue项目的脚手架Router:路由Pina:状态管理Eleme

状态模式state

学习笔记,原文链接 https://refactoringguru.cn/design-patterns/state 在一个对象的内部状态变化时改变其行为, 使其看上去就像改变了自身所属的类一样。 在状态模式中,player.getState()获取的是player的当前状态,通常是一个实现了状态接口的对象。 onPlay()是状态模式中定义的一个方法,不同状态下(例如“正在播放”、“暂停

软件架构模式:5 分钟阅读

原文: https://orkhanscience.medium.com/software-architecture-patterns-5-mins-read-e9e3c8eb47d2 软件架构模式:5 分钟阅读 当有人潜入软件工程世界时,有一天他需要学习软件架构模式的基础知识。当我刚接触编码时,我不知道从哪里获得简要介绍现有架构模式的资源,这样它就不会太详细和混乱,而是非常抽象和易