# 语言哲学：面向对象与组合的边界

学习目标：从已有报告输出与装饰器示例出发，理解继承与组合在面对需求变化时的修改成本、扩展边界与责任分配。

前置阅读：将报告写入不同目标 与 组合与委托：输出组件增强。本篇不提供新实作代码，专注于从真实示例代码分析架构取舍。

# 从扩展新输出目标说起

在将报告写入不同目标中，核心报告生成函数 write_report 接收一个通用的输出目标参数。在需求变化为“增加文件输出”或在组合与委托中“为输出增加统一日志前缀”时，我们观察到两种截然不同的架构路线：

1. 类继承体系（Inheritance）：定义 ReportWriterBase 基类，派生 ConsoleReportWriter、FileReportWriter，并让 LoggingReportWriter 再次派生。
2. 行为接口与组合（Composition）：定义微小的写入协议（如 Go 的 io.Writer、Rust 的 std::io::Write、Java 的 Appendable/Writer），核心逻辑只依赖协议，通过装饰器包装实现增强。

# 继承带来的隐性耦合

当试图通过类继承扩展组件行为时，系统常面临以下结构性成本：

• 脆弱基类问题（Fragile Base Class）：基类为了给子类提供便利，往往在内部包含状态字段或方法间的隐式相互调用。一旦基类调整了某个内部调用时序，深层派生类预设的不变式会瞬间崩塌。
• 组合爆炸：若系统既需要“文件输出”，又需要“网络输出”，同时各自需要“带日志前缀”、“带压缩”或“带加密”，使用多重继承或子类派生将导致类数量呈指数级膨胀（例如 EncryptedLoggingCompressedFileWriter）。
• 语言天然阻隔：现代系统语言如 Go 和 Rust 在设计之初就彻底删除了类的实现继承机制，正是为了从源头消除复杂的虚方法查找和类层次状态混杂。

# 组合如何保持核心逻辑封闭

遵循开闭原则（Open-Closed Principle）：

• 修改范围：使用组合与装饰器模式时，报告生成函数自身的代码行数为 0 修改。
• 正交增强：一个 LoggingSink 可以无差别地包装内存缓冲、控制台输出或磁盘文件。日志逻辑与具体的持久化介质在代码结构上完全正交。
• 反馈时机：接口契约（如是否具备 write 能力）在静态语言中由编译器在编译期验证；实现者只需满足极小的单一职责接口。

# 各语言的机制设计取舍

# 相关阅读

• 将报告写入不同目标
• 组合与委托：输出组件增强
• 继承与重写：类层次与方法覆盖
• 抽象与成本：编译、运行与心智成本