YSL_Monet的博客

主要是对前面的设计模式进行一个总结，主要掌握以下十大设计模式，其他的设计模式后面的在慢慢熟悉。

在生活中，可以看到不少网红在直播卖货，也可以看出中介者模式。在主播卖货的过程中，由于设计到多个对象，比如商品、观众、平台等，每个对象都有自己的任务和职责，但是它们之间需要相互协调和交互才能顺利完成卖货的过程。其中主播可以充当中介者的角色，负责协调和调度各个对象的交互。

例如编译器将源代码作为输入，通过词法分析和语法分析，构建抽象语法树（AST）。然后编译器使用解释器模式来遍历和执行这个抽象语法树，将源代码转换为机器码，并执行该机器码。

在现代办公场景中，备忘录模式可以应用于文档编辑工具中。以Office工具为例，当用户在云文档中进行编辑时，系统会自动将当前的文档内容保存在一个备忘录对象中，并将备忘录对象存储在云端的服务器上。每隔一段时间，系统会判断是否需要保存文档的状态，如果需要，则将当前的备忘录对象保存为一个快照，以便日后恢复文档的状态。

我们可以将一个购物商场中的商品类作为元素类，不同的销售人员可以作为访问者类。当销售人员需要对商品进行销售操作时，可以创建一个具体的访问者对象，然后通过商品类的接受访问者的方法将访问者对象传入。然后商品类再根据传入的访问者对象调用相应的访问者方法，从而实现对商品的不同销售策略，如打折、促销等。

比如在设计一个电梯系统时，可以使用状态模式来管理电梯的不同状态，如开门、关门、上升、下降等。将电梯的这几种状态封装成一个独立的状态类，并定义了该状态下的具体行为，通过将状态切换的逻辑分布到各个状态类中，可以使得电梯的状态切换更加清晰、易于维护和扩展。

在餐饮业中，命令模式可以用于实现订单的处理流程。例如在餐厅中，当我们在客户端或者小程序上进行点单，客户端 / 小程序会将我们在上面下的订单请求封装成为一个对象，通过发送命令给后厨的工作人员上，而他们就会根据我们下的具体订单进行菜品备菜、菜品制作、菜品上菜等一系列操作。

在我们公司内部审批流程中，若某个员工提交了请假申请，需要经过上级的一系列的审批过程，例如小组长审批、部门经理审批、人事部审批、总经理审批等。这些审批过程可以采用责任链模式来实现，将每个审批者看作一个处理器，若某个处理者无法处理该申请，则将该申请传递给下一个处理者，直到有一个处理者同意或拒绝该申请为止。

在我们进行的烹饪的过程中，有些菜肴的制造步骤是固定的，比如炒菜之前要先热锅冷油、加入姜蒜葱爆香，然后加入要炒的备菜，最后放入调料调味进行翻炒，然后出锅。不同的菜肴可能只需要在某些步骤上有所差异，比如加入的调料不同，要炒的备菜不同。这种情况下，就可以使用模板方法模式，先定义一个基本的烹饪流程(模板方法)，然后让不同的菜肴根据需求实现不同的细节(抽象方法)。

在购物平台上，我们需要实现一个促销活动功能。可以通过使用策略模式来实现不同类型的促销策略，比如折扣、满减、赠品等，每个促销策略可以被封装成一个独立的策略类，客户端根据不同的促销需求来选择不同的策略进行结算。

例如在操作系统中的文件夹结构可以使用迭代器模式实现，通过迭代器模式，可以实现对文件夹中文件和子文件夹的遍历，从而无需暴露文件夹的内部实现细节，这样用户就可以方便地浏览文件夹的内容，并执行相应的操作，如复制文件、删除文件、打开文件

在我们生活中，用户可以在音乐播放平台关注多个歌手，而当有歌手发布新的歌曲时，可以将歌曲发布到音乐播放平台，而平台会将新的歌曲详细信息发送给关注该歌手的用户。而此时歌手就相当于是观察者模式的主题对象，每个关注的用户则是观察者模式中的观察者对象，通过该模式，用户可以很及时的听到歌手的新歌曲，而歌手也可以很轻松的通知用户新歌曲的发布。

在棋类游戏中，棋子可以看作是享元对象，因为棋子与棋子之间有着相同的属性和方法，例如在颜色、大小、移动规则上都有着相同的特质。因此在棋类游戏中，可以使用享元模式来共享相同的棋子对象，避免创建大量的棋子对象，从而提高游戏性能。

在文件系统中，比如目录和文件就形成了一个树形结构，目录可以包含文件以及子目录，而子目录同样的也可以包含文件以及子目录的子目录。

比如在路上随处可见的汽车，汽车和引擎之间可以使用桥接模式。抽象部分可以是一个汽车的抽象类，实现部分可以是不同类型的汽车，如轿车、SUV等。而引擎可以是抽象部分的扩展类，实现部分可以是不同的引擎类型，如电动、燃油、混油引擎等。而我们可以创建多个引擎和汽车，而每个引擎和汽车之间都是独立的，通过桥接模式将不同类型的汽车和引擎进行组合，实现灵活的汽车配置。

当我们想看电视时，在电视上或者电视遥控器上都有一个电源启动 / 关闭按钮，这个按钮掩盖了电视机内部的所有复杂性，当我们想看电视时按下遥控器上的电源启动按钮，或者想调整电视音量时，又或者想调换电视节目等，也是通过电视遥控器上的某一个按钮来控制电视机，完成对应的电视复杂操作。

当我们去一家咖啡店时，点了一杯咖啡。这时，你觉得咖啡有点苦，或者说咖啡的味道不够丰富，就可以给店员 / 咖啡师说，希望可以在我们的咖啡中添加糖、牛奶等不同的食材以此来丰富我们咖啡。这些食物都可以看作是装饰者，然后我们可以根据自己的具体口味，添加不同程度的以及不同风味的食材。

在我们去某个地方旅游时，我们可以报名旅行社，通过旅行社来给我们安排行程、酒店、机票等等一些服务，旅行社就是我们去旅游时的代理对象，他们代表我们与航空公司、酒店、旅游景点等去进行交涉和预订，为我们提供我们在某个地方时的各种旅游服务。

在我们生活中可以看见的电源转换器，根据不同的国家和地区有着不同的电源标准，比如我国国内使用的是普通的扁平两项或三项插头，而德国使用的是两项圆头的插头。因此，若是在德国使用手机充电器插头无法直接使用上德国的电源插排，就无法给手机供电，生活中有一款电源转换器，就好比一个适配器，其插头既符合德国标准，可以在德国的电源插排中使用。而上面的电源接口也符合国内标准，这样就可以通过电源转换器实现手机充电。

优点：减少对象的创建和初始化开销，提高性能总结：无需再次调用构造函数就能通过复制已有对象来创建新对象场景：适用于频繁创建和销毁大量相似对象的场景。

将⼀个复杂对象的构建与其表示分离，通过将构建复杂对象的过程抽象出来，可以使客户端代码与具体的构建过程解耦同样的构建过程可以创建不同的表示总结：将复杂对象的构建过程与其表示分离，以使同样的构建过程可以创建不同的表示场景：适用于构建复杂对象的场景，并且希望将构建逻辑与表示分离的情况。

优点：由于简单工厂模式只依赖于产品的接口，添加新产品时就只需要增加相应的实现类和工厂类总结：根据参数的不同返回不同类的实例场景：适用于单一类产品的情况。

优点：由于简单工厂模式只依赖于产品的接口，添加新产品时就只需要增加相应的实现类和工厂类总结：根据参数的不同返回不同类的实例场景：适用于单一产品的情况。

​ 我们只有一个大脑，但是我们需要频繁地使用它来思考、记忆和判断。因此，我们只需要一个大脑实例，并通过全局访问点（例如我们的嘴巴和眼睛）来使用它。小明去了一家大型商场，拿到了一个购物车，并开始购物。请你设计一个购物车管理器，记录商品添加到购物车的信息（商品名称和购买数量），并在购买结束后打印出商品清单。​ 单例模式确保一个类只有一个实例，并提供一个全局访问点来访问该实例，通常用于需要频繁创建和销毁同一对象的场景，以避免资源浪费和提高性能。输入包含若干行，每行包含两部分信息，分别是商品名称和购买数量。

软件设计模式（Software Design Pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。