配置环境

JDK: 17

创建型设计模式

单例（Singleton）

场景：电商系统中需要一个全局的订单号生成器（OrderIdGenerator）。它必须在多线程环境下保证唯一、性能开销小、允许延迟初始化并能在单个应用实例内被全局访问。 请设计该组件的类结构与获取方式，使其既线程安全又易于测试（可替换/模拟）。

工厂方法（Factory Method）

场景：支付服务需要支持多种支付渠道（微信、支付宝、信用卡、钱包等），并且未来会不断增加新的渠道。每种渠道有各自的处理流程和配置项。 请设计一个工厂方法结构，使得新增渠道时最小化改动（对现有代码开闭原则友好），并支持按配置动态创建对应的支付处理器。

抽象工厂（Abstract Factory）

场景：公司做跨平台客户端 SDK，要在不同平台/主题下生成一套相关联的 UI 组件族（例如：Button、TextField、Dialog），要保证同一套样式（如 iOS 风格 或 Material 风格）内部组件能互相配合。 请设计抽象工厂如何组织不同平台/主题的组件家族，以及客户端如何按需切换产品族。

建造者（Builder）

场景：订单系统需要创建复杂的 Order 对象——包含必填的商品清单、用户信息，以及大量可选项（发票、配送方式、优惠策略、礼品包装、订单备注、第三方保险、分期信息等）。 请设计一个 Builder，使得构造调用链可读、避免构造函数参数炸裂（telescoping constructor），并支持可变的必选/可选字段校验与最终不可变的 Order 对象。

原型（Prototype）

场景：在商品管理后台，常见“复制商品”操作：管理员经常基于现有商品快速克隆并只调整少量字段（价格、库存、活动标签）。系统要求克隆操作性能要高（避免重新查询/构建大量子对象），并且有选择性地浅拷贝或深拷贝某些关联数据（如图片、属性、评论）。 请设计一个原型复制方案，说明如何控制浅/深拷贝以及扩展新字段的拷贝策略。

结构型设计模式

适配器模式（Adapter） — 第三方支付接入

业务场景：你的电商系统需要接入两家第三方支付：PayFast（提供 REST API，方法名 payOrder(amountCents)）和 QuickPay（旧系统，只能用 processPayment(dollars)）。你希望在系统内部统一调用 PaymentGateway.charge(amountInCents)。 要求/考点：定义统一接口并实现两个适配器，处理单位转换（美元/分）与异常封装；展示如何在订单结算处无差异地切换支付实现。

桥接（Bridge） — 多渠道通知系统

业务场景：平台要发送通知，通知分为不同“内容类型”（订单通知、营销通知、系统告警），同时有多种“发送渠道”（Email、SMS、Push）。未来可能新增渠道或通知类型。 要求/考点：使用桥接将“通知内容（抽象）”与“发送实现（实现者）”解耦，演示如何在运行时组合任意通知类型与渠道，并保持扩展性。

组合（Composite） — 权限菜单与UI树

业务场景：后台管理系统的菜单支持任意层级（目录/菜单项），并对某些节点设置权限（例如角色能看到的菜单）。前端需要遍历树渲染，也需要按角色过滤树。 要求/考点：用组合模式实现 MenuComponent（目录/叶子），支持 render()、filterByRole(role)、add/remove 操作；说明如何用统一接口对叶子与组合进行操作。

装饰者（Decorator） — 动态给文本添加功能

业务场景：一个文本处理管道，基础是 Text 对象。业务需要按需给文本添加“加密”、“压缩”、“HTML 转义”、“拼写检查”等功能，且这些功能可以自由组合和顺序叠加。 要求/考点：用装饰者模式实现可组合的文本处理器（动态添加/移除装饰行为），展示装饰器链的构造与执行顺序对结果的影响。

外观（Facade） — 订单下单外观

业务场景：下单流程涉及库存检查、价格计算（含优惠/积分）、支付、发货排队、通知。上层只想调用 OrderService.placeOrder(orderDto)。 要求/考点：设计一个外观类封装复杂子系统调用，确保事务边界、错误回滚或补偿策略的基本说明（不用实现复杂事务，只说明点），并示例如何降低上层耦合。

享元（Flyweight） — 文档编辑器的字符/样式复用

业务场景：一个富文本编辑器需要展示和处理非常大的文档（百万字符），每个字符有可能带有样式（字体、大小、颜色）。为节省内存，需要大量共享样式对象。 要求/考点：实现享元工厂管理共享的 TextStyle（内在状态），将字符对象分离为内在/外在状态，指出何时不能使用享元（可变内在状态的风险）。

代理（Proxy） — 远程服务调用与缓存

业务场景：系统需要频繁查询商品详情，但后端服务响应慢或带宽贵。设计一个代理层，在本地缓存热数据、在未命中时调用远程服务并异步刷新缓存。同时需要控制并发访问（防止缓存击穿）。 要求/考点：用代理模式封装缓存逻辑与远程调用，演示同步代理或智能代理的不同（缓存、访问控制、懒加载、并发保护），并说明缓存一致性与失效策略。

行为型设计模式

责任链 — 在线贷款审批流程

业务背景：一家线上贷款平台，根据不同贷款额度与风险，会把申请依次发给「自动风控 → 人工客服 → 风控主管 → 法务」四个审批节点。每个节点可以：通过（下一节点）、拒绝（终止并返回原因）、或在特定条件下直接放款（终止并返回结果）。 要求实现：设计责任链结构，能动态调整链中节点顺序与启/停某些节点；节点可访问并修改申请上下文（如信用评分、逾期记录、附加证件）；支持并发申请处理。 交付物：描述各节点职责与触发条件；定义 LoanApplication 上下文类；定义抽象 Handler 接口与链构建器。 示例输入/输出：输入：申请金额 50,000，信用评分 720，逾期 0。输出：通过（并返回放款流水号）；另一输入：申请金额 300,000，信用评分 580，逾期 2 → 输出：拒绝 + 拒绝原因。 额外约束：日志必须记录每个节点的决策；系统应允许某些规则（阈值）在运行时热更新（例如信用分阈值）。

命令 — 后台任务调度与撤销（运维场景）

业务背景：一个分布式运维系统，需要封装各种运维操作为命令（例如：启动服务、停止服务、发布配置、回滚配置、清理临时文件）。运维人员可以排队执行、异步执行、批量执行、并支持对某些可逆命令做撤销（undo）与重做（redo）。系统还需记录命令的审计日志与执行结果。 要求实现：设计命令接口，支持同步/异步执行、执行回调、事务式批量命令（要么全部成功，要么回滚），并实现撤销机制（对可撤销命令）。 交付物：命令抽象、命令执行器（Scheduler/Invoker）、命令日志/audit 接口、示例几种具体命令（StartServiceCommand、DeployConfigCommand、RollbackConfigCommand）。 示例用例：批量部署新配置到 3 台服务器：若第 2 台失败，自动执行回滚命令撤销已部署的机器。 额外约束：撤销并非对所有命令都必须实现；命令应可序列化以便重放；考虑网络失效与幂等问题。

解释器 — 报表过滤与规则表达式引擎

业务背景：业务用户需要在 BI 系统中输入自定义过滤表达式（例如：(country == "JP" AND (revenue > 10000 OR user_age >= 30)) AND NOT test_user），系统需解析该表达式并将其应用于数据流或 SQL 查询中。表达式支持比较、逻辑运算、括号、字段存在检查与简单函数（如 contains(field, "abc")）。 要求实现：为该表达式设计解释器：词法分析、语法解析（AST）、并能将 AST 转换为（1）可执行过滤器（在内存流上过滤），或（2）等价的 SQL WHERE 子句。 交付物：定义语法（BNF/EBNF 简要版）、关键 AST 节点类、解析器接口、两个解释器实现（内存过滤与 SQL 生成）。 示例：输入表达式：email contains "@example.com" AND last_login > "2025-01-01" → 输出：对应的 Predicate（可用于 Java Stream.filter）或 SQL WHERE email LIKE '%@example.com' AND last_login > '2025-01-01'。 额外约束：要处理运算符优先级、类型安全（数字与字符串比较）、并对未知字段提供友好错误信息；解析器应易于扩展新函数。

迭代器 — 大数据分页与聚合消费（流式处理场景）

业务背景：有一套用户行为数据存储在分段文件/分片数据库中，需要逐条遍历并做聚合计算，但不能一次性加载所有数据。迭代器需要在不同后端（本地文件、远程 API、分布式存储）之间统一遍历接口，并支持筛选、跳过与 peek（查看下一个元素但不消费）。 要求实现：设计一个通用 Iterator/Iterable 体系（或增强版），支持懒加载、批量预取（prefetch）、失败重试，并能组合多个底层迭代源（合并排序）。 交付物：定义通用迭代器接口与至少两个后端实现（FileSegmentIterator、RemoteApiIterator）；示范如何用组合迭代器对多个分片进行合并（例如按时间顺序合并）。 示例：从三份分段文件中按时间合并读取用户点击事件，并在内存中每 10,000 条做一次汇总。 额外约束：内存使用受限、需要保证幂等与异常恢复能力（例如迭代器断点续读）。

中介者 — 多服务协同的订单处理总线（电商场景）

业务背景：电商平台的订单流经多个子系统：库存服务、支付服务、配送服务、通知服务、风控服务。这些子系统之间耦合复杂，频繁直接相互调用导致难以维护。需要一个中介者（或轻量总线）来协调各子系统的交互与流程（例如：支付成功触发库存锁定 → 库存锁定成功触发发货准备与通知；若任一步骤失败则触发补偿）。 要求实现：设计中介者接口，支持事件发布/订阅、命令路由、事务性协作（Saga 风格或补偿事务），并能监控当前流程状态。中介者应支持注册/注销服务、延迟/定时任务、以及优先级处理。 交付物：中介者抽象类或接口、示例服务适配器（库存适配器、支付适配器）、一个示例订单处理流程定义（顺序/补偿逻辑）。 示例流程：下单 → 扣款（支付） → 锁库存 → 创建配送单 → 发通知；若锁库存失败则退款并通知用户。 额外约束：避免服务间直接引用；保证中介者自身可横向扩展，且考虑事件去重与幂等。

备忘录（Memento） — 文档编辑器的撤销/恢复

业务场景：你正在实现一个简化的文本编辑器（或富文本笔记），需要支持“撤销（undo）”和“恢复（redo）”操作，但不希望把文档内部状态暴露给外部组件（实现信息封装）。为节省内存，只需要支持保存最近 3 次状态（环形缓冲或固定大小历史）。

观察者（Observer）— 股票价格推送服务

业务场景：一家小型金融服务要实现股票价格推送。系统有一个 StockTicker（主题/可观察者），多个 Client（观察者）可以订阅或退订。每当 StockTicker 更新某只股票价格时，所有订阅了该股票（或订阅了全部）的 Client 应收到通知。要求实现简单线程安全（可选）或至少表现一致性。

状态（State）— 电商订单处理（Order）

业务场景：实现电商系统中的 Order 对象，其行为随订单状态而变化（典型：Pending、Paid、Shipped、Delivered、Cancelled）。使用状态模式把每个状态的行为封装到独立状态类中，Order 根据当前状态委托行为。

策略模式（Strategy）

场景 你在开发一个电商订单系统，系统需要对订单进行不同的折扣计算：满减、百分比折扣、会员专属折扣（固定金额），以及无需折扣。未来可能还会增加按节日折扣或优惠券策略。

任务 设计一个使用策略模式的方案，使得折扣算法可插拔（运行时切换），并且在结算时能根据订单和用户信息选择合适策略。要求代码尽量简化、易扩展。

模板方法模式（Template Method）

场景 公司有一套“促销活动处理”流程：准备数据 → 验证规则 → 计算活动结果 → 记录日志 → 后置通知。不同类型活动（限时抢购、团购、首单立减）在“验证规则”和“计算活动结果”两步有不同实现，但整体流程一致。

任务 用模板方法模式设计促销处理框架：把固定流程写在抽象模板中，把可变步骤留给子类实现。要求示例代码简洁，能够演示两个具体活动子类的差异点。

访问者模式（Visitor）

场景 公司需要对一组报表元素执行不同的操作：生成 CSV、生成 JSON、计算统计汇总、权限校验等。报表元素包括 TextField、NumberField、DateField、以及嵌套的 Section（包含多个字段）。新需求是经常要添加新的操作（如导出到 Excel、渲染到 HTML），而元素种类相对稳定。

任务 使用访问者模式设计一套结构，使得可以在不修改元素类的情况下增加新的操作（访问者）。提供至少两个访问者实现（例如：JsonExportVisitor 与 StatisticsVisitor），并演示遍历报表元素并应用访问者的方式。代码尽量简化，重点表现 accept / visit 的结构。