# 1. SRP 的 Robert Martin 原意中变化原因（reason to change）唯一，而非职责单一 A 一个类应该只包含一个方法 B 一个类应该只有一个引起它变化的原因，而非笼统的"职责单一" ✓ 正确答案 C 一个类的方法数量不应超过 10 个 D 一个类应该只属于一个包
# 2. Actor（参与者）视角的 SRP 中每个类服务于一个 actor；多 actor 引起的"胖类"识别 A 类的方法过多 B 类的字段过多 C 类没有使用继承 D 类被多个参与者的不同需求共同修改，一个 actor 的变更影响另一个 actor ✓ 正确答案
# 3. SRP 与 SoC（Separation of Concerns）的边界中 SoC 是原则、SRP 是具体规则 A SRP 是比 SoC 更宏观的架构原则 B SoC 是原则，SRP 是 SoC 在类粒度上的具体规则 ✓ 正确答案 C 两者完全等价，没有区别 D SoC 只关注类的划分
# 4. 业务用例（Use Case）作为模块划分依据；DDD 的聚合（Aggregate）作为变化边界 A 聚合之间可以通过直接访问内部实体维持一致性 B 聚合越大越好，便于复用 C 聚合通过聚合根对外访问，聚合内不变式在同一事务边界内保证 ✓ 正确答案 D 聚合与业务用例无关
# 5. 变化驱动的模块边界 vs 复用驱动的模块边界（Utility、Helper）的冲突 A 所有可复用的代码都应放进 Utility 类 B Utility 类可以包含所有业务逻辑 C 含业务语义的复用代码应通过抽象/策略共享，而非全部堆进 Utility ✓ 正确答案 D 复用驱动与变化驱动从不冲突
# 6. SRP 的常见误解澄清中「一个类只有一个公共方法」不是 SRP，如何用真实重构案例向团队演示「按变化原因拆分」与「按方法数量拆分」的差异？ A 方法越多越应拆分，方法少就符合 SRP B 按方法数量拆分永远正确 C 一个类必应只有一个公共方法 D 拆分的依据应是变化原因，而非方法数量 ✓ 正确答案
# 7. 微服务的"职责"边界中 Bounded Context（限界上下文）作为 SRP 的服务级体现 A 一个微服务通常对应一个限界上下文，体现服务级的 SRP ✓ 正确答案 B 一个微服务应承载尽可能多的业务上下文以提高复用 C 限界上下文只影响领域模型，与服务划分无关 D 服务拆得越多越好
# 8. "上帝类"（God Class）的诊断中 field count、method count、fan-in、fan-out A fan-in 过高说明类被过多引用，可能成为中心枢纽 ✓ 正确答案 B method count 越低越说明是上帝类 C 上帝类只与字段数有关，与 fan-in 无关 D 上帝类符合 SRP
# 9. "业务-技术"两层职责的拆分中业务代码与基础设施代码的隔离（Hexagonal Architecture） A 核心业务应直接依赖具体的数据库驱动 B 适配器应位于核心内部 C 核心通过端口定义接口，适配器实现端口对接外部资源 ✓ 正确答案 D 六边形架构不关心依赖方向
# 10. SRP 的识别信号中一个类有多个变化原因？ A 类位于核心包内 B 列出"为什么修改这个类"可得到两个以上互不相关的理由 ✓ 正确答案 C 类被 final 修饰 D 类的方法都是 public
# 11. SRP 与横切关注点的边界中日志、鉴权、事务等横切逻辑应归入 AOP/装饰器还是业务类，如何避免职责蔓延又不破坏可读性？ A 所有横切逻辑都应塞进业务类以保证可读性 B 横切点只能用手写 if 实现 C 无业务语义的横切（事务、日志）用 AOP/装饰器，有业务语义的应显式参与 ✓ 正确答案 D AOP 能解决所有可读性问题
# 12. "核心-支撑-通用"三层架构（Clean Architecture、DDD 分层）的职责 A 核心层应依赖具体框架以实现业务 B 通用层应包含全部业务逻辑 C 支撑层是领域模型所在 D 依赖方向由外向内，核心不依赖外层 ✓ 正确答案
# 15. SRP 在模块/函数层面的应用？ A 一个函数应只做一件事、只有一个变化原因，便于命名与测试 ✓ 正确答案 B SRP 只适用于类，不适用于函数 C 函数越长越符合 SRP D 模块级 SRP 与包结构无关
# 17. SRP 的实践案例中拆分后的类职责表述？ A 一个类可以有多个职责，只要表述清晰 B 职责表述应越模糊越好 C 若类职责描述中出现"并且/同时/此外"，说明职责可能仍不单一 ✓ 正确答案 D 职责表述与变化原因无关
