用食物解释设计模式 🥕
用C#实现的GOF设计模式,附带受食物启发的工作示例
这个仓库是为了展示和学习Gang of Four设计模式(Gamma、Helm、Johnson和Vlissides编写的《设计模式 - 可复用面向对象软件的基础》)而创建的,使用了相对真实的例子。
正在进行的YouTube系列视频详细介绍了每个项目。从这里开始:https://www.youtube.com/watch?v=C_6uQwBjsmk
动机
在线教学中的许多设计模式示例通常避免包含外部依赖,如数据库、AMQP队列、用于电子邮件和HTTP API等的外部服务。虽然避免在示例代码中添加这些依赖可以更容易地展示设计模式的核心动机,但也使人更难想象这些模式在实际场景中的应用。本仓库中的项目包含了这些类型依赖的模拟版本,并将其融入各种可能的业务场景中。这些示例旨在保持精简,以便每种模式的主要优势能够明显体现,但又足够复杂以避免过于简化的场景。
示例程序
每种设计模式都有一个对应的.NET 5.0控制台应用程序。
模式 | 类型 | 示例程序 | 使用原因 |
---|---|---|---|
抽象工厂 | 创建型 | 自定义膳食规划器 | 我们希望能够以可扩展的方式创建具有自身行为的饮食系列,用于生成杂货清单等数据,而无需在客户端中指定具体类 |
建造者 | 创建型 | 面包店采购订单系统 | 我们希望将用于构建采购订单的复杂逻辑与其表示分离。我们可以提供一种流畅的语法来创建新的采购订单,并在构建完成时无缝地使用建造者作为它负责构建的类的实例。 |
工厂方法 | 创建型 | 食品配送服务 | 我们希望更容易地扩展配送类型的构建。我们可以引入新的配送类型而无需修改客户端代码。 |
原型 | 创建型 | 餐厅设计器 | 在我们的图形设计应用程序中,我们希望更容易地创建昂贵或难以获得的图标。我们可以为设计师创建椅子和桌子对象的深层副本 - 无需了解被复制对象的内部状态 - 这些副本可以在克隆后独立使用和修改。 |
单例 | 创建型 | 配料数据库连接池 | 我们创建一个单例连接池管理器,供不同客户端连接数据库使用。如果尝试连接的客户端超过池允许的数量,它会阻止进一步连接。使用延迟初始化以确保线程安全。 |
适配器 | 结构型 | 食谱搜索 | 我们需要使用JSON来填充网站的食谱文档存储,但我们最喜欢的API返回XML。我们可以使用适配器来匹配我们所需的接口,并按原样使用现有资源。 |
桥接 | 结构型 | 农贸市场模拟器 | 农贸市场模拟器为供应商类型和支付处理器类型提供不同的类层次结构。由于任何供应商都应与任何支付处理器兼容,我们倾向于使用桥接进行组合,以独立开发供应商抽象和支付处理器实现。 |
组合 | 结构型 | 茶叶包装器 | 我们按箱销售茶叶。箱子可以包含更多箱子。我们希望在任何箱子外打印服务份数,即使它包含许多其他箱子。我们可以使用组合模式以相同的方式处理聚合和单个对象,暴露获取服务份数的行为,而不考虑具体对象细节,统一处理聚合和单个对象。 |
装饰器 | 结构型 | 前厅服务 | 我们有一个自动系统,让就餐者知道他们的桌子准备好了。默认情况下,我们通过餐厅内部通讯系统发布通知。但是,我们希望扩展通过电子邮件或短信通知客户的能力,并需要一种方法来轻松添加、删除和组合这些选项,而不增加大量复杂逻辑或指数级增加子类数量。 |
外观 | 结构型 | 杂货店报告 | 帮助我们制作杂货店报告的底层服务提供者复杂且难以使用。我们希望在客户端代码中使用一个易于使用的接口来隐藏这种复杂性 |
享元 | 结构型 | 杂货店城市规划模拟 | 作为我们城市规划工作的一部分,我们想在最佳位置建造一家杂货店。我们正在构建一个模拟,模拟城市居民的位置和移动,这些居民是包含字段和其他对象的对象。其中一些对象代表不变的、静态的数据,这些数据由大部分其他居民共享,如社区和出行方式。一些数据在模拟过程中是居民本身固有的,如其纬度和经度。享元可以用于在模拟过程中通过缓存外在数据作为共享资源来节省内存,供数十万居民对象使用。 |
代理 | 结构型 | 食品银行捐赠处理器 | 我们的食品银行处理器使用现成系统接受食品捐赠。但是,我们希望控制对这个资源的访问,同时保持相同的接口。我们需要记录资源的使用情况并防止某些物品被捐赠,所以我们使用代理。 |
责任链 | 行为型 | 康普茶订单处理器 | 我们的康普茶客户订单处理流程相当简单。我们装箱、查询忠诚度计划、如果是在线订单则打印运输标签,并通过电子邮件或打印收据。这些步骤的一些细节会根据某些状态而变化 - 比如订单是否在线,客户是否是忠诚会员。例如,我们希望在非忠诚会员客户的收据上打印广告。我们可以使用责任链模式来组合和执行订单处理流程的每个阶段。 |
命令 | 行为型 | 堆肥注册表单 | 我们经营一家公司,允许我们社区的人们注册有机堆肥收集服务。在幕后发生一些复杂的业务逻辑,包括向AWS SQS队列发送消息供车辆路由服务使用,并发送欢迎电子邮件。我们希望有一种方法在入职流程的不同点执行这些逻辑,因此我们创建命令对象来封装完成这些操作所需的逻辑和数据,并允许我们的客户端在其入职算法的特定时间执行任意命令类型。 |
解释器 | 行为型 | 巧克力店条形码读取器 | 我们开始了一家低浪费的巧克力店,为顾客提供散装的公平贸易巧克力。每个巧克力容器都需要使用自定义条形码扫描器进行扫描。条形码需要由我们的软件解释,以执行与库存和报告相关的下游操作。我们将构建并集成一个解释器供扫描器使用,以使这成为可能。 |
迭代器 | 行为型 | 最佳餐厅查找器 | 我们开发了一个应用,让用户按"最佳到最差"的顺序浏览他们喜爱的餐厅,但不同用户对餐厅排名的标准不同。我们通常希望能够遍历餐厅集合,而不用担心底层细节或甚至不暴露其结构。因此,我们将使用迭代器模式,而不暴露这些实现细节。 |
中介者 | 行为型 | 食品车协调员 | 我们需要一种方法来协调城市中的食品车和食品推车。这些不同的车辆需要相互通信,但随着我们尝试添加新类型的车辆和通信原因,情况变得混乱。我们将构建一个中介者来处理这种复杂的协作,以便我们可以独立地改变它们的交互。 |
备忘录 | 行为型 | 甜甜圈店购物车 | 我们经营一家销售城市最佳甜甜圈的商店。我们运营一个在线电子商务商店,允许用户将甜甜圈添加到购物车。我们希望客户能够撤销将甜甜圈添加到购物车的操作,所以我们使用备忘录模式实现了这个功能的基本版本。 |
观察者 | 行为型 | 饮食计划跟踪应用 | 我们刚刚推出了饮食计划跟踪应用,用户不断更新他们的个人资料,包括新的体重、锻炼目标和照片。每次个人资料更新时,我们需要启动其他流程来实现我们服务的许多不同功能。我们尝试过轮询变化,但这变得太昂贵,而且我们错过了间隔之间的更新。让我们使用观察者模式从"拉"切换到"推"设计,这样我们所有依赖的服务都可以订阅个人资料变更事件。 |
状态 | 行为型 | 咖啡厅奖励计划 | 我们家族咖啡店为常客提供分级奖励。客户获得的积分越多,他们的等级就越高。我们希望在每次购买时检查和调整客户等级,因此我们将实现状态模式,使奖励评估器根据客户的奖励等级进行行为。 |
策略 | 行为型 | 餐厅菜单更改器 | 我们经营一家全天候变更菜单的餐厅。我们有不同的流程来制作早餐、午餐和晚餐菜单,但高层流程保持不变。我们全天都在烹饪和上菜,但完成这些工作的策略会根据情况而变化。我们还希望能够轻松地为不同位置生成高价或低价范围的菜单,而不重复代码或在高层对象中塞满条件逻辑。我们可以依赖组合优于继承的好处,并实现策略模式来保持代码更加整洁。 |
模板方法 | 行为型 | 食谱打印机 | 我们经营一家为自出版厨师打印食谱的业务。我们用于打印食谱的大部分流程完全相同,但根据食谱略有不同。我们使用具有默认行为的模板方法,并通过继承由具体食谱强制或可选地重写虚拟行为。 |
访问者 | 行为型 | 农贸市场研究 | 我们为一家为区域农贸市场提供销售和营销报告的公司工作。不同的农贸市场及其供应商有自己的逻辑来生成我们可用于报告的数据,但我们需要能够生成报告,而不显著修改任何现有的数据生成类。我们让它们可以被我们自己的类"访问",这些类反过来可以根据需要使用它们来为销售和营销团队生成自定义报告。 |