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

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

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

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

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

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

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

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

最近读了Martin Fowler关于IoC和DI的文章，觉得之前SpringBoot-IoC-DI写的还是太过狭隘。因此本篇对这个话题进行补充。 IoC 和 DI 的关系 在上一篇文章中，首段的描述似乎把DI定义为与IoC同级的概念，这种暗示是错误的。 而Spring Core完成了两个关键概念：IoC（Inversion of Control，控制反转）和DI（Dependency

桥接模式(Bridge Pattern)是一种结构型模式。它的主要作用是将抽象部分与实现部分分离，使它们可以独立变化。 场景 有一个形状Shape类，从它扩展出两个子类：长方形Rectangle和 圆形Circle。假设需要在另一个维度颜色Color上，对Shape再进行扩展细分。如果只有红色Red和蓝色Blue两种颜色，那么一共需要四个类覆盖所有的组合。 12345