[Blog][Domain] programb.blog.csdn.net

| **需要多次重放同一数据集** | 使用 `reset()` + 不可变快照（如 `List.copyOf()`） || **高并发、低延迟要求** | 不可变快照 + `AtomicInteger` 游标（无锁） || **必须反映实时数据变更** | ❌ 迭代器模式本身不适用 → 改用观察者模式、数据库游标、或流式拉取（如 `Stream.iterate` + 状态回调） || **Java 8+ 环境** | 直接使用 `Spliterator`（支持并行、特征标记、trySplit），它是

- ❌ 避免用 `list.append/pop` 手动模拟栈并让所有 Expression 共享同一 `Context.env_stack` —— 易引发并发或递归调用时的状态混乱；- ✅ 推荐将 `Environment` 作为不可变快照（每次 `enterScope()` 返回新环境），或使用 `with` 上下文管理器封装生命周期；- 🔐 安全增强：可添加 `readonly` 标志防止外部篡改全局环境；敏感 DSL（如策略引擎）应禁用 `eval` 类操作，只允许白名单函数调用；- 🚀

- **Client** 负责解析原始输入（如字符串），构建由 `AbstractExpression` 派生对象组成的 AST，并启动解释；- **Context** 作为共享上下文（如变量环境、状态栈、作用域信息），供各表达式节点在解释过程中读写；- **AbstractExpression** 定义统一接口 `interpret(Context context)`，体现里氏替换与组合复用；- **TerminalExpression** 处理最小不可分单元（如数字、标识符、常量），不包含子表达式

📌 补充说明：- 若命令不可逆（如发送 HTTP 请求、删除文件），`undo()` 应抛出 `UnsupportedOperationException` 或实现补偿事务（如“删除”对应“从回收站恢复”）。- 生产级系统常结合 **Command + Memento + Caretaker** 构建健壮撤销栈（尤其编辑类应用）。- Java 中还可利用 `AutoCloseable` 或 try-with-resources 模拟命令生命周期，但非标准做法。

- 避免副作用叠加（如重复扣款）→ Handler 必须设计为**幂等**或引入去重 ID / 分布式锁；- 性能敏感场景需考虑短路优化（如“只要有一个拒绝就终止审批” → 此时应回归经典责任链）；- 日志/监控建议记录每个 Handler 的执行耗时与结果，便于链路追踪（如集成 Sleuth + Zipkin）。

- 某些模式存在边界模糊性（如 Proxy 和 Decorator 在代码结构上相似），**区分关键在于意图与上下文**：若重点是“控制访问权限/延迟初始化/远程调用”，选 Proxy；若重点是“叠加横切功能/日志/缓存/验证”，选 Decorator。 - 观察者与中介者均降低耦合，但观察者是**一对多通知**（发布-订阅），中介者是**多对多协调**（中心化通信枢纽）；责任链与策略均支持运行时选择，但责任链是**顺序尝试+可中断**，策略是**显式选择+一次性委托**。

- 启动耗时 Bean：如 `DataSource` 初始化、`ElasticsearchRestTemplate` 连接建立；- 循环依赖解耦：A 依赖 B，B 依赖 A → 将其中一个标 `@Lazy`，Spring 用代理打破强初始化依赖；- 测试/配置隔离：非核心模块 Bean（如邮件服务、短信 SDK）仅在业务触发时加载，提升主流程启动速度。

- 工厂（`FlyweightFactory`）依赖内部状态构造唯一键（如 `hash((font_name, font_size))`）。若内部状态被修改，该对象的逻辑身份与工厂缓存键脱节，既无法被正确复用，也无法被安全回收。4. **违反封装与契约，破坏 LSP 和里氏替换** - Client 假设享元是“只读资源”，若意外修改影响全局行为，下游模块将出现未声明的副作用，违背面向对象设计原则。---

1. **存在大量高度相似的对象**（如文本编辑器中数百万字符、游戏地图中十万棵树）； 2. **这些对象的大部分状态是重复且不变的**（如字符的字体、字号、样式；树的模型、贴图、材质）； 3. **变化的部分（如位置、颜色、生命值）可由外部统一管理并作为参数传入**，且客户端有能力承担该职责。

🔍 **关键辨析点：** - **外观不隐藏“谁在干活”，而是隐藏“怎么一起干活”**； - **代理不简化“做什么”，而是控制“何时/如何/能否做”**。 例如：`VideoPlayerFacade.play()` 封装了视频解码、音频解码、字幕渲染三步调用；而 `ImageProxy.load()` 在首次调用时才真正创建并加载 `RealImage`，接口签名（`load()`）与 `RealImage` 完全一致——这就是代理的“透明性”。

✅ **关键优势**： - ✅ 开闭原则友好：新增功能只需新增具体装饰器类，无需修改已有代码； - ✅ 职责单一：每个装饰器只关注一个附加职责（如日志、缓存、权限校验）； - ✅ 可组合、可嵌套、可撤销：装饰器可自由组合、顺序可调、也可选择性移除； - ✅ 透明性：客户端面向 Component 接口编程，无需感知是否被装饰。

- 不要在 `parent` 属性的 getter 中做耗时或副作用操作（弱引用解包是轻量的，但需确保 `parent` 存在性检查）；- 若需在父对象销毁时触发回调（如自动从父中移除自己），可结合 `weakref.finalize`，但应谨慎——通常由 Composite 在 `remove()` 中显式管理更清晰；- 在多线程环境下，`weakref` 本身是线程安全的，但 `get_path()` 等遍历逻辑仍需注意并发修改树结构的风险（此时应加锁或使用不可变快照）。

❌ **1. 彻底丧失“抽象与实现解耦”的核心价值** 桥接模式的核心目标是让抽象层（如 `Shape`）和实现层（如 `Renderer`）**独立演化**。一旦 `Abstraction` 继承自 `Implementor`（例如 `Circle extends OpenGLRenderer`），二者在编译期即强绑定，无法在运行时切换实现（如从 OpenGL 切换到 Vulkan 渲染器），也无法为同一抽象（`Circle`）复用不同实现（如 `MetalRenderer`、`WebGLRender

- 👉 看到**老系统SDK/第三方库接口和你当前代码不匹配** → 选 **适配器（优先对象适配器）** - 👉 预判**未来要频繁增删“类型×策略/平台×渲染/设备×协议”等正交组合** → 选 **桥接模式** - 👉 二者都用？✅ 常见场景：用桥接构建主框架（如 `Renderer` × `Shape`），再用适配器接入某厂商私有 `LegacyRendererAPI`。

🔹 **继承表达的是“is-a”关系**（强语义、紧耦合），应仅用于真正存在自然分类层级的场景（如 `Dog is-a Animal`）； 🔹 **组合表达的是“has-a”或“uses-a”关系**（弱语义、松耦合），更贴近现实协作逻辑（如 `Adapter uses-an Adaptee`）。 Adapter 模式本质是**协作而非泛化**：Adapter 并非 Adaptee 的一种，而是“使用 Adaptee 来满足 Target 接口”，因此组合在语义上更准确、更安全、更可演进。

- 普通类反序列化时，JVM 会调用 `ObjectInputStream.readObject()` → 触发无参构造器（或 `readResolve()` 钩子）； - 但**枚举类型的反序列化完全 bypass 构造过程**： - JVM 严格规定：反序列化枚举时，**必须通过 `Enum.valueOf(Class<T>, String)` 查找已存在的、由类加载器初始化的枚举常量**； - 即：反序列化得到的对象 **必然是类定义中声明的那几个静态常量之一**（如 `Singl

✅ **浅拷贝（Shallow Copy）** - ✅ **定义**：仅复制对象本身（字段值），对引用类型字段**只复制引用地址**，新旧对象共享同一底层对象（如 List、Map、自定义对象等）。 - ✅ **优点**：速度快、内存占用小、实现简单（如 Java `Object.clone()` 默认行为、Python `copy.copy()`）。 - ⚠️ **风险**：修改克隆体中的可变引用对象，会**意外影响原始原型**（违反“隔离性”契约）。 - 🎯 **适用场景**：

⚠️ **反模式警示**： ❌ 若 Creator 的默认实现 **硬编码了唯一具体类**（如 `return new MySQLConnection()`）且 **不允许子类覆盖**（如方法被 `final` 修饰），则确实违背模式——此时已退化为简单工厂（Simple Factory），丧失多态扩展能力。 ✅ 正确做法：即使提供默认，也必须保持 **可重写性（overridability）** 和 **语义开放性（open for extension）**。

✅ **正确做法（符合 OCP）**： - `Creator` 类**只声明抽象工厂方法**（如 `def factoryMethod(self) -> Product:`），不提供任何具体产品实例化逻辑； - 或者，**可提供一个空实现/抛出异常的默认方法**（如 `raise NotImplementedError`），强制子类实现； - 若确需默认行为（如简单场景下的退化支持），应确保该默认实现**仍基于抽象 Product 接口**（例如返回一个轻量级默认实现类 `DefaultProd

- ❌ “Builder 也能创建多个对象 → 所以它就是轻量级 Abstract Factory”：错误。Builder 的多个部件是**内聚子组件**，服务于唯一产品；Abstract Factory 的多个产品是**平等并列的协作方**。 - ❌ “Abstract Factory 可以逐步构建 → 所以能替代 Builder”：不能。AF 不提供构建流程控制，也无法表达“先设A再选B，若C存在则跳过D”这类逻辑。 - ✅ 协同使用合理：`AbstractFactory` 可用来创建不同 `C

**抽象工厂模式（Abstract Factory）**和**生成器模式（Builder）**的核心思想、结构组成、适用场景及关键对比维度。以下是对二者更精炼的补充说明与辨析，便于深入理解与实践应用：

| | **Singleton（单例）** | 对象创建型 | 确保一个类仅有一个实例，并提供全局访问点 || **结构型** | **Adapter（适配器）** | 类/对象均可 | 将一个类的接口转换成客户期望的另一接口 || | **Bridge（桥接）** | 对象创建型 | 将抽象与实现解耦，使二者可独立变化 || | **Composite（组合）**

- **传承经验**：将资深开发者在大量项目中沉淀的设计智慧标准化、文档化； - **统一语言**：为团队提供高信息密度的沟通元语（如“观察者”“策略”“装饰器”），大幅降低架构讨论的认知负荷； - **权衡显性化**：通过“效果”要素，强制设计者正视取舍（如用空间换时间、用间接性换灵活性），避免盲目套用； - **面向变化编程**：所有模式本质上都是对某类变化点（如对象创建方式、算法替换、职责分配）的封装与隔离。

✅ **推荐方式：使用构造型（Stereotype） + 标签（Tagged Value）或注释（Note）** - 为通信路径添加自定义构造型，例如 `<<https-tls13>>`、`<<restricted-firewall>>`； - 配合标签值（Tagged Value）补充结构化属性，如： `tlsVersion = "1.3"`、`cipherSuite = "TLS_AES_256_GCM_SHA384"`、`allowedSources = "10.0.0.0/8"`；

- 接口 = “合同文本”（规定权利与义务）； - 端口 = “签字盖章的签约窗口”（谁在此代表构件签署该合同，并与谁对接）； - **没有脱离端口的接口部署，也没有不承载接口（或协议）的端口价值**——二者协同构成“可验证的结构契约”。-

- 在业务流程建模（工作流视角）中，优先用**中断区域 + 信号事件**建模用户取消、超时、人工干预等； - 在操作级建模（如算法逻辑）中，若需反映代码级异常（如 `try-catch`），建议结合**注释（Note）** 或使用 **UML Profile（如MARTE或自定义异常Profile）** 增强语义，而非强行套用中断区域； - 真实系统中，“取消订单”常需**分布式事务补偿**（Saga模式），此时活动图应配合**对象流（Object Flow）传递补偿指令**，并在中断处理中调用反向

UML活动图（Activity Diagram），它确实属于状态机图（State Machine Diagram）的一种变体，但更准确地说：**活动图是UML中独立的行为图（Behavior Diagram），并非“特殊的状态图”**——这是常见误解。虽然两者都使用节点与边建模行为，但本质不同：- ✅ **活动图**：强调**控制流（control flow）和数据流（object flow）**，聚焦于动作（Action）、活动（Activity）、并发、分支/合并等，适用于建模业务流程、操作算法或用

✅ **状态（State）** - 表示对象在某一时刻所处的“行为情境”，具有持续性（可停留一段时间）。 - **简单状态**：无内部结构，如 `Idle`、`Transmitting`； - **组合状态（Composite State）**：具有嵌套结构，用矩形框+分隔线表示，内含多个**子状态（Substates）**，支持层次化建模； - 子状态可进一步嵌套（形成多级组合），提升复杂行为的可读性与可维护性。

交互概览图（Interaction Overview Diagram, IOD）中的**交互片段**（如 `alt`、`opt`、`loop`、`par`）与活动图（Activity Diagram, AD）中的**决策节点**（Decision Node）虽在视觉上都体现“分支选择”，但二者在**语义层级、建模意图、抽象粒度和执行语义**上存在本质区别：

- 使用 **带实心箭头（→●）的开放箭头**（即“实心三角形”或“实心圆点+直线”，UML 2.x 规范推荐：**空心箭头 + «async» 构造型标注**，但更常见且工具支持广泛的表示是：**带「/」斜线的箭头线** 或 **带 «async» 标签的普通箭头**）。 - 更标准、无歧义的做法是：**在消息标签前添加 «async» 构造型**（如 `«async» 3:process()`），并配合**普通开放箭头（→）**。 - 语义：发送方发出消息后**不等待响应，立即继续执行**（典型

- 若需表达“可选执行”（即 `if` 无 `else`），可用 `opt` 片段（标签为 `opt`，含单一分支，守卫条件写在分支顶部）； - 守卫条件应为**逻辑表达式**，基于对象状态或参数值，**不描述实现细节**（如不写 `if (x > 0) { ... }`，而写 `[x > 0]`）； - 所有分支必须作用于**相同的生命线集合**，不可新增或缺失对象。

- 扩展用例只能在指定扩展点、且满足其**扩展条件**（如 `if student.isInternational == true`）时才被动态插入执行； - ✅ 用例图中**不显式画出扩展点**（它是规约级内容），但**必须在用例描述文档中声明**，否则 `<<extend>>` 关系缺乏可执行依据，属于建模不完整。

🔹 **语义一致性要求**： 对象图是类图的**实例化快照**，其存在前提是类图已定义了结构契约。链代表两个或多个对象之间实际存在的、符合类图中某条关联（含多重性、角色名、导航性等约束）的连接。若出现类图未声明的链，则意味着该对象图与类图不一致，违反了“实例必须遵守其类型定义”的建模范式。

**聚集（◇—）** 强调“整体-部分”的松耦合，如Department可独立于Company存在；- **泛化（△→）** 表达继承与多态，如Headquarters复用Office的共性属性；- **关联实线+角色+多重度** 揭示业务语义，如一个Department有1个manager（Person）和0..*个member（Person）；- **依赖（虚线→）** 暗示临时性或使用性联系（如方法参数），不改变生命周期；

| **语义本质** | “has-a”（拥有关系，弱整体–部分） | “contains-a” 或 “owns-a”（强整体–部分） || **生命周期** | 部分对象可独立于整体存在和消亡 | 部分对象的生命周期**完全由整体控制**；整体销毁 ⇒ 部分必然销毁 || **所有权** | 整体不独占部分；同一部分可属于多个整体（如：员工可同时属于项目组和部门） | 整体**独占**部分；部分不能同时属于多个整体（如：一个发动机只属于一辆车） |

聚集（Aggregation）与组合（Composition）都是**关联关系的特殊形式**，用于表达“整体–部分”（whole-part）结构，但二者在**语义强度、生命周期依赖和存在性约束**上存在本质区别：

- «entity» 类 → 表示该类为持久化实体（如JPA中的@Entity）； - «controller» 类 → 表示MVC架构中的控制器； - «database» 构件 → 表示一个数据库实例； - «signal» 类 → 将普通类重定义为UML信号（Signal），用于异步事件建模。

- **组合测试（Combinatorial Testing）**：对多态对象 + 不同上下文（如不同用户角色、配置开关）做笛卡尔积用例生成； - **变异测试（Mutation Testing）**：在子类中故意引入小变异（如 `if (fee > 0)` → `if (fee >= 0)`），验证原有测试能否捕获——若不能，说明测试未真正驱动多态行为； - **运行时多态探测**：利用反射或字节码分析（如Java Agent / Python `inspect`）动态枚举所有已加载子类，自动生成

| 需要共享**状态（字段）** 或 **通用逻辑实现**（如日志、缓存、模板方法骨架） | ✅ 抽象类 | 接口无法持有可变状态或提供非静态实现 || 子类间存在**强 is-a 关系**，且有共同生命周期管理（如统一资源初始化/清理） | ✅ 抽象类 | 构造/析构函数可集中控制 || 一个类需具备**多种不相关能力**（如“可序列化”+“可比较”+“可绘图”） | ✅ 接口 | 支持多重实现，避免菱形继承问题，符合单一职责 || 面向未来扩展，需**解耦调用方与具体实现**（如策略模式、回调机制

| ✅ **约束互斥优先** | 尽量让各 `requires` 分支覆盖不相交的类型集合（如 `integral` vs `floating_point`） || ✅ **显式排除已覆盖分支** | 自定义分支末尾加 `&& !A && !B`，避免隐式重叠 || ✅ **利用标准概念的正交性** | `std::integral`, `std::floating_point`, `std::is_pointer_v`, `std::is_enum_v` 等天然互斥 || ✅ **避免过度通用概念兜