桥接模式的核心是识别并分离系统中两个独立变化的维度（如业务逻辑与技术实现），通过抽象层与实现层的组合替代继承，实现动态绑定与自由扩展。

桥接模式的核心不是“怎么写代码”，而是“怎么想问题”——它帮你识别系统中哪些变化是彼此独立的，然后用组合代替继承，让每个维度自由生长，互不牵制。

识别两个独立变化的维度

这是使用桥接模式的前提。不能凭感觉，要从需求演进中找规律：

• 业务逻辑类在变（比如通知类型：普通、紧急、延迟）
• 技术实现类也在变（比如发送渠道：邮件、短信、App推送）
• 两者组合数呈乘法增长，且新增一个业务类型就要为所有渠道重复实现，新增一个渠道又要为所有业务类型复制逻辑

一旦发现这种“N × M”的扩展趋势，就该考虑桥接了。

定义抽象层（Abstraction）

抽象层封装“做什么”和“按什么规则做”，不关心“怎么做”。它持有对实现层的引用，但只调用约定好的接口方法。

• 例如：Notifier 类定义 send() 方法，内部调用 implementor.sendImpl()
• 子类如 UrgentNotifier 只增强规则（重试3次、记录日志），不碰具体发送动作
• 抽象层可以继续扩展，比如加 DelayedNotifier，只需控制触发时机，无需修改任何渠道代码

定义实现层（Implementor）

实现层专注“怎么把事情干成”，完全不知道上层业务意图。它提供稳定、细粒度的操作接口。

• 例如：MessageSender 接口声明 sendImpl(String content)
• 具体实现如 EmailSender、SmsSender 各自处理协议、连接、格式化等细节
• 新增 PushSender？只要实现接口，立刻能被所有通知类型复用

运行时动态组合，而非编译期绑定

桥接的价值在实例创建和使用阶段才真正释放：

• new UrgentNotifier(new SmsSender()) → 紧急短信
• new DelayedNotifier(new EmailSender()) → 延迟邮件
• 甚至可在配置或参数驱动下切换实现：new NormalNotifier(senderFactory.get("wechat"))
• 抽象与实现之间没有继承关系，只有强类型的组合引用，修改任一端不影响另一端的编译和运行