# 1. Decorator 模式作为组合的动态扩展（Java IO 流、JS HOC） A 装饰器会改变被装饰对象的接口 B 装饰器必须继承多层子类 C 装饰器只能静态固定 D 装饰器通过组合动态叠加职责，不改变接口，是组合优于继承的体现 ✓ 正确答案
# 2. Effective Java 的"组合优于继承"原则；继承的破坏性（脆弱基类问题、菱形继承） A 菱形继承无问题 B 继承总是优于组合 C 组合无法复用代码 D 继承泄漏基类封装，组合通过委托隔离变化，更安全 ✓ 正确答案
# 3. Fragile Base Class Problem（脆弱基类问题）中基类修改导致子类行为不可预期 A 脆弱基类问题只存在于 C++ B 基类修改不影响子类 C 基类内部实现变化可能导致子类行为不可预期，应用组合规避 ✓ 正确答案 D 组合无法避免脆弱基类问题
# 4. Mixin / Trait 模式作为"受限组合"（Ruby、Scala、Rust） A 只能用于一个类 B 它们是强耦合的继承 C 它们横向复用行为而非建立深层继承层级，避免菱形歧义 ✓ 正确答案 D 与组合无关
# 5. State 模式作为组合的状态机替换 A 状态模式仍用 if-else 判断状态 B 上下文组合状态对象并委托行为，用多态替换 if-else 分支 ✓ 正确答案 C 状态模式增加状态耦合 D 状态模式与组合无关
# 6. 组合优于继承的例外场景中何时继承框架基类仍是唯一现实选择（如 ORM 实体、框架 Controller 基类），如何用工程规则约束其滥用边界？ A 业务代码之间应任意继承 B 继承永远可以用组合替代 C 框架强制继承（如 ORM 实体、Controller 基类）是合理例外，但应用规则约束滥用 ✓ 正确答案 D 例外场景无需任何约束
# 7. final class 的设计意图（不可继承）vs open class 的扩展空间 A final 类永远无法扩展 B final 冻结类型禁止继承，open 留出扩展空间，现代倾向默认 final ✓ 正确答案 C open 类更安全 D 默认都应 open
# 8. protected 字段/方法的耦合泄漏风险与替代（package-private、protected accessor） A protected 与封装无关 B protected 字段完全安全 C 应尽量用 public 字段 D protected 直接暴露内部实现，应用 package-private 或 protected accessor 替代 ✓ 正确答案
# 10. 「组合的过度使用」反模式中仅为了复用而强行组合导致的对象图爆炸与间接调用链，何时应回归简单继承、接口默认方法或静态工具函数？ A 对象图越深越好 B 组合永远是正确选择 C 仅为复用而强行组合会导致对象图爆炸与间接调用链，应适时回归简单方式 ✓ 正确答案 D 静态工具函数无法复用
# 11. Template Method 模式中继承复用算法骨架的经典场景，与策略或组合方案相比的取舍与滥用边界？ A 基类定义骨架，子类实现可变步骤；骨架稳定时适用，多用策略/组合替换 ✓ 正确答案 B 模板方法用组合复用骨架 C 模板方法无滥用风险 D 模板方法与策略等价
# 12. 扩展第三方类时的继承覆写 vs 组合包装（Adapter/委托）中对升级兼容性与可测试性的影响如何取舍？ A 组合包装无法隔离第三方升级 B 继承覆写最安全 C 组合包装只依赖公开 API，升级兼容性与可测试性更好 ✓ 正确答案 D 继承不影响升级
# 13. 继承层级深度（≤3-4 层）的项目约束与可视化工具 A 无法可视化继承 B 继承深度越深越好 C 深继承无危害 D 用 DIT 指标监控继承深度，超限（如 >3-4 层）提示过度继承 ✓ 正确答案
# 16. 何时继承仍合适，is-a 关系的确认？ A 继承永远不适用 B 只要语义叫 is-a 就可继承 C 继承合适需成立"行为可替换"的 is-a，且父类契约稳定 ✓ 正确答案 D is-a 与 LSP 无关
# 19. 多重继承的语言机制差异中 C++ 多继承、Java 接口默认方法与 Ruby mixin 各自的问题与组合替代？ A C++ 用虚继承、Java 用接口默认覆写、Ruby 用线性化解冲突，组合委托可避免冲突 ✓ 正确答案 B 三种语言机制完全相同 C 多继承无冲突 D 组合无法替代多继承
