中介者模式通过引入一个中介对象，让原本相互依赖的多个对象改为通过中介者间接通信，从而降低耦合、提高灵活性和可维护性。 场景 有时会遇到这样的开发场景：多个组件互相依赖、交互，整体构成了一个大的应用。 最常见的例子是GUI，一个窗口内包含了各种组件，例如文本框、标签、按钮等。组件之间可能存在依赖关系。例如点击提交按钮，会对其他文本框的内容进行校验；选择某个单选按钮，其他按钮就会移除被选中的状态

迭代器模式是一种行为设计模式，让你能在不暴露集合底层表现形式 （列表、 栈和树等） 的情况下遍历集合中所有的元素。 场景 迭代器实在是太常见了，已经成为了很多现代编程语言本身的一部分。 在日常开发过程中，处理同类型的多个数据对象的场景太常见了。我们通常会用集合表示这些同类型的一组对象。为了了解集合构成，需要不重复地访问元素，这个过程称为遍历。 学过算法和数据结构，或者刷过leetcode

命令模式是一种行为设计模式，它可以将请求转换为一个包含与请求相关的所有信息的独立对象。该转换让你能根据不同的请求将方法参数化、延迟请求执行或将其放入队列中，且能实现可撤销操作。 场景 假设正在开发一款软件的GUI，界面上有许多功能不同的按钮。这些按钮有很多相似的地方，直觉上会把这些共性提取到一个按钮基类中。而每个具体按钮不同的实际功能，则需要在继承的子类中实现区分。 123456789101

总算到了行为模式。回顾前文，在创建型模式中，关注如何创建某类实例，在结构型模式中，关注将不同类和对象组装到一起，以扩展或适配功能。而在行为模式中，关注对象间的交互和职责划分。 首先介绍责任链模式（Chain of Responsibility, CoR）。责任链模式允许将请求沿着处理链传递，直到有一个处理器能够处理它。每个处理器决定是否处理请求或将其传递给链中的下一个处理器。 场景 在业务代

代理模式是一种结构型设计模式，通过引入代理对象来控制对原始对象的访问，常用于功能扩展、访问控制或性能优化。 场景 在编写代码时，经常会出现需要在方法开始或结尾，编写固定格式代码的情况。例如在接口层方法中，需要对入参和出参进行日志打印；又或者是在业务逻辑方法中，执行前需要开启事务，结束时需要提交/回滚事务。 我们当然可以在这些方法中显式编码日志输出，也能正确执行。但当日志输出需要调整时，需要对

享元模式（Flyweight）是一种结构型设计模式，它摒弃了在每个对象中保存所有数据的方式，旨在通过共享对象来减少内存使用和提高性能。 场景 在一些2D平面游戏中，玩家可以控制一个角色，在地图中移动，和不同单位交互。对于这类游戏，内存中存在一个数组，表示游戏的地图数据，包含例如某个地格的地形、位置、障碍物、是否有道具/角色可交互对象等数据。游戏的图像引擎，通过遍历每个地格的数据，渲染成游戏界面

外观/门面模式(Facade)是一种结构型设计模式，能为程序库、框架或其他复杂类提供一个简单的接口。 场景 为了通用性，第三方库/子系统会把功能设计得完备，但客户端通常只使用其中非常少的功能。客户端直接使用第三方库类，会引入过多不必要的功能与方法细节，也会导致客户端会与第三方类的实现细节紧密耦合。当想尝试替换其他功能相似的第三方库时，客户端需要调整所有调用第三方库方法的位置。如果客户端需要同时

由于工作的主要内容还是CRUD，对于软件架构设计鲜有接触，对相关概念的理解是欠缺的。这些欠缺在最近一次面试中暴露出来。虽然内心也在为面试造火箭，实际拧螺丝愤愤不平。很多架构的设计，对开发人员编码的影响是透明或极小的，因为这部分内容通常被框架完成或者进行了很好的封装，以让开发人员可以将注意力集中到业务逻辑上。但冷静后还是觉得，有必要去学习和实践，就算这些新玩意不一定用得到。这是一个拥抱进步的程序员该

装饰模式（Decorator Pattern）是一种结构型设计模式，允许在不修改现有对象结构的前提下向对象添加新的功能。 场景 假设我们正在开发一款爬虫软件，并准备将爬取到的数据写入csv文件中。按照模块化编程的思想，会把csv相关的代码保存到一个独立的类CsvWriter中。而后可能又需要把同样的数据写入txt、json、数据库中，也会诞生相应的TxtWriter、JsonWriter、S

组合模式(composite)是一种结构型设计模式，可以使用它将对象组合成树状结构， 并且能像使用独立对象一样使用它们。 场景 在开发中会遇到需要处理/统计的对象们，属于层级或者包含关系。学过数据结构的同学肯定知道，通常用树来组织这些对象。 树由节点和边构成。其中节点用于存储数据，而边构建了节点之间的关系。一个节点通过持有另一些节点的引用，来构建边。一段典型树结构代码如下所示。 1234