类型系统视角下的组合优于继承：从子类爆炸到接口契约

继承的陷阱：子类爆炸与紧耦合

当系统需要沿多个独立维度扩展时，继承会迅速陷入 "子类爆炸" 的困境。假设一个日志系统需要支持多种输出目标（文件、Socket、Syslog）和多种过滤策略（关键字匹配、级别过滤），若采用继承实现，则需要为每种组合创建独立子类：FilteredFileLogger、FilteredSocketLogger、SeverityFileLogger…… 当维度增至 m 和 n 时，类数量将呈几何级数增长至 m×n。

更深层的隐患在于紧耦合。子类通过继承获得的不仅是接口，还有父类的实现细节。当父类修改内部实现时，所有子类都可能受到波及。这种 "脆弱的基类问题" 使得大型继承层次结构难以维护和演化。

组合的核心机制：接口契约与依赖注入

组合优于继承的本质，是将行为委托给独立组件而非从父类继承。这要求系统建立在稳定的接口契约之上 —— 组件只暴露最小化的行为接口，调用方通过依赖注入获取所需能力。

依赖注入并非框架专属概念。在 Python 等动态语言中，只需在构造函数中接收接口实现即可：def __init__(self, handler: Handler)。类型系统（如 TypeScript、Rust、Go）通过接口 / 特质（trait）进一步强化了这种契约，编译期即可检查组件兼容性。

组合带来的关键优势包括：

• 局部性：每个功能模块代码集中，调试时无需在继承链中跳转
• 可删除性：移除 Socket 支持只需删除 SocketHandler 类及其测试，无需修改其他代码
• 测试隔离：测试 SocketHandler 时无需实例化整个 Logger，只需验证emit()行为
• 运行时灵活性：可在运行期替换组件，如根据配置切换输出目标

可落地的实现模式

Adapter 模式：接口适配

当现有组件接口与需求不匹配时，Adapter 通过包装将其适配为目标接口。Python 的socket.makefile()即内置示例，将 Socket 适配为类文件对象，使 Logger 无需感知底层差异。

class FileLikeSocket:
    def __init__(self, sock):
        self.sock = sock
    def write(self, msg):
        self.sock.sendall(msg.encode())
    def flush(self):
        pass

Bridge 模式：抽象与实现分离

Bridge 将类的行为拆分为 "抽象层"（调用方可见）和 "实现层"（内部包装）。以日志为例，过滤逻辑属于抽象层，输出处理属于实现层。两者通过emit()方法解耦，可自由组合。

class FilteredLogger:
    def __init__(self, pattern, handler):
        self.pattern = pattern
        self.handler = handler
    def log(self, msg):
        if self.pattern in msg:
            self.handler.emit(msg)

class FileHandler:
    def emit(self, msg):
        # 输出到文件

Decorator 模式：对称包装

Decorator 要求包装类与被包装类实现相同接口，从而支持多层嵌套。日志过滤器可包装任意 Logger，且多个过滤器可堆叠使用。

class LogFilter:
    def __init__(self, pattern, logger):
        self.pattern = pattern
        self.logger = logger
    def log(self, msg):
        if self.pattern in msg:
            self.logger.log(msg)

独立组合：超越 GoF 模式

Python 标准库 logging 模块展示了更灵活的设计：Logger 维护 filters 列表和 handlers 列表，消息通过所有过滤器后才广播给所有处理器。这种模式将组件完全解耦，filters 甚至无需了解 "日志" 概念，仅接收字符串返回布尔值。

工程实践清单

接口设计原则：

1. 接口方法数量控制在 3 个以内，遵循最小知识原则
2. 避免在接口中暴露实现细节（如文件句柄、连接池）
3. 使用协议类（Protocol）或抽象基类（ABC）显式定义契约

依赖注入策略：

1. 构造函数注入：首选方式，依赖关系显式可见
2. 工厂模式注入：当依赖创建逻辑复杂时使用
3. 配置驱动注入：通过配置文件映射组件类型，避免硬编码

避免多重继承陷阱：

• 多重继承依赖实现细节（如super()调用），单元测试无法验证组合正确性
• 属性命名冲突在大型系统中难以预防
• 方法解析顺序（MRO）增加认知负担

可观测性保障： 组合系统可能产生 emergent behavior，需建立完善的链路追踪。为每个组件添加__repr__或结构化日志输出，记录组件组合关系。

权衡与边界

组合并非银弹。过度细粒度的组件拆分会导致调用链难以追踪，调试时需跨越多个对象边界。建议：

• 单一组件代码量控制在 200 行以内
• 组合深度不超过 3 层
• 关键路径使用内联文档说明组件协作流程

类型系统在此发挥约束作用。静态类型检查可在编译期发现接口不匹配，减少运行时错误。Go 的隐式接口、Rust 的 trait、TypeScript 的接口定义，都为组合提供了编译期安全保障。

资料来源

• Python Patterns Guide: "The Composition Over Inheritance Principle" — 详细阐述 Adapter、Bridge、Decorator 三种实现模式及与多重继承的对比
• Perplexity Research: "cybernetic forests composition over inheritance" — 组合系统设计的隐喻与架构原则

systems