# 1. Primitive Obsession（基本类型偏执）中何时应该用值对象替代散落的字符串/数字参数？ A 当某个基本类型被反复校验或承载业务规则时，应用值对象封装以获得类型安全与行为内聚 ✓ 正确答案 B 用 int 表达金额与数量是安全的，无需类型区分 C 值对象会降低类型安全 D 基本类型偏执只在字符串场景出现
# 2. 反模式的系统性治理中如何用静态分析（圈复杂度/内聚度）自动识别并纳入 CI 门禁？ A 圈复杂度越高越好，代表方法更强大 B 静态分析只能人工执行，无法自动化 C LCOM 用于衡量方法的复杂度，而非内聚度 D 用圈复杂度与内聚度指标配合 CI 门禁，可自动识别反模式并阻止新债进入 ✓ 正确答案
# 3. Speculative Generality 中如何识别为将来可能用到而做的过度抽象，删除时的安全步骤 A 为未来可能用到而做的过度抽象是有价值的，应保留 B 删除抽象无需验证引用，直接删即可 C 识别信号是抽象只有一个实现或参数从不被传非默认值，删除前先确认无调用方 ✓ 正确答案 D 所有抽象都应删除，无论是否有使用者
# 4. Message Chains 与 Middle Man 中链式调用如何隐藏真实依赖，中间人只做转发时如何用 Hide Delegate 与 Remove Middle Man 重构 A 链式调用让真实依赖更清晰 B 两者都用 Remove Middle Man 重构 C Message Chains 用 Hide Delegate 隐藏链结构，Middle Man 用 Remove Middle Man 删除纯转发 ✓ 正确答案 D Middle Man 是很好封装，应保留全部转发
# 5. Feature Envy（依恋情结）中方法过度访问其他类数据时如何用 Move Method 纠正？ A 方法访问其他类数据是正常的，无需处理 B Move Method 是把方法移到调用方附近 C 用 Move Method 把方法移到它依赖数据的类中，让行为与数据内聚 ✓ 正确答案 D Feature Envy 与数据归属无关
# 6. God Class 的识别与拆分中按职责内聚度拆分，如何避免拆出新的"上帝类"？ A 按职责内聚度分组，用 Extract Class 拆分，并明确每个新类的单一职责避免新上帝类 ✓ 正确答案 B God Class 拆分应盲目按大小切分，无需考虑职责 C LCOM 高说明内聚好，不是 God Class D 拆出的类无需保证单一职责
# 7. 数据泥团（Data Clump）中重复出现的一组字段如何提取为类，保持行为内聚？ A 任何成组字段都应无条件提取 B 数据泥团无需处理，重复字段无害 C 提取字段组会破坏行为内聚 D 重复成组出现的字段应提取为类，并封装相关行为，实现内聚 ✓ 正确答案
# 8. 坏味道度量指标中圈复杂度、LCOM（方法内聚缺乏度）在自动识别中的作用与局限？ A 圈复杂度高一定代表坏味道，必须重构 B LCOM 用于衡量代码行数 C LCOM 衡量方法间共享字段的程度，LCOM 高预示内聚差，但指标是启发式需人工复核 ✓ 正确答案 D 指标可完全替代人工评审
# 9. 反模式治理的落地顺序中静态扫描 → 评审清单 → 渐进重构 → 门禁的推进路径？ A 直接大规模重写，无需扫描与门禁 B 先静态扫描建立基线，再评审清单、渐进重构，最后设 CI 门禁 ✓ 正确答案 C 门禁应在静态扫描之前设置 D 评审清单可替代静态扫描与门禁
# 10. Data Class 中只有 getter/setter 的类如何用 Move Method 承载行为，何时应封装集合并暴露意图方法 A 只有 getter/setter 的类应通过 Move Method 承载行为，并对集合封装暴露意图方法 ✓ 正确答案 B Data Class 是理想设计，无需改进 C 集合应直接暴露原始引用，便于外部修改 D 意图方法会降低可读性
# 11. Long Parameter List 中参数过多的成因与 Introduce Parameter Object、Preserve Whole Object 的取舍 A 参数彼此独立时也应强行合并为参数对象 B Introduce Parameter Object 把相关参数组合成对象，Preserve Whole Object 传完整对象取字段 ✓ 正确答案 C Preserve Whole Object 一定比特参数对象优 D 过长参数列表无需处理，不影响可读性
# 12. Refused Bequest 的识别与处理中子类只使用父类部分行为时，为什么用'以委托取代继承'（Replace Inheritance with Delegation）重构？ A 委托比继承更死板，不利于复用 B Refused Bequest 说明继承关系非常合适，应保留 C 子类只使用父类部分行为时，用"以委托取代继承"重构，避免接口污染 ✓ 正确答案 D 子类应继承父类所有方法，包括不适用的
# 13. 重复造轮子（Reinventing the Wheel）的代价与边界中什么场景下自研优于复用（学习、深度定制、合规），如何评估长期维护成本？ A 自研永远优于复用，无论成本 B 重复造轮子没有成本代价 C 复用库永远比自研安全，无需评估 D 学习、深度定制、合规等场景下自研可能优于复用，但要评估长期维护成本 ✓ 正确答案
# 14. God Class 与 Long Method 的危害中为什么类/方法过长会降低可测试性与可维护性？ A 长类/长方法把职责揉在一起，导致测试难以隔离、维护牵一发动全身 ✓ 正确答案 B 长方法可测试性更好，因为逻辑集中 C 类过长只影响可读性，不影响可测试性 D 长类职责单一，利于复用
# 15. 复制粘贴代码与 DRY 的边界中复制后微调有时比抽象更安全，如何用规则判定该不该抽象？ A 任何重复都必须抽象，否则违反 DRY B 若两处代码因同一原因变化则应抽象，若会各自演化则复制更安全 ✓ 正确答案 C 复制粘贴永远比抽象安全 D 三次法则指出现一次就要抽象
# 16. Shotgun Surgery（霰弹式修改）的识别中一处需求改动散落多处文件，如何用重构收敛？ A 改动分散是正常现象，无需收敛 B 霰弹式修改代表逻辑内聚良好 C 一处需求改动需修改多处文件，可用 Move Method/Extract Class 把相关逻辑收敛 ✓ 正确答案 D 收敛后改动仍会散落多处
# 17. Shotgun Surgery 与 Divergent Change 中两者分别对应合并 vs 拆分的重构方向？ A 两者都需合并 B 两者都需拆分 C Shotgun Surgery 是"一个变化改多处"需合并，Divergent Change 是"一处因多原因改"需拆分 ✓ 正确答案 D 两者是同一概念，无区别
# 18. 过早优化（premature optimization）与性能敏感代码的取舍中为什么先测量再优化能避免过度设计？ A 优化会提升可读性，应尽早做 B 任何代码都应无条件提前优化 C 应先用 profiler 测量定位真实瓶颈，再针对性优化，避免过度设计 ✓ 正确答案 D 性能敏感代码无需考虑性能约束
# 19. 以注释代替代码（Commented-Out Code）的坏味道，为什么删除注释掉的代码并用版本控制保留历史更优？ A 版本控制无法恢复已删代码 B 注释掉的代码应永久保留以防需要 C 注释掉的代码不影响可读性 D 应删除注释掉的代码，用版本控制保留历史，避免误导与失步 ✓ 正确答案
# 20. Lazy Class 中几乎不做事的类如何识别，何时合并到相邻类或直接删除 A 几乎没有职责的类应合并到相邻类或直接删除，删除前确认无引用 ✓ 正确答案 B Lazy Class 是理想设计，应保留 C 懒散类方法越少越好，无需处理 D 任何类都不能删除
