桥接模式通过组合替代继承解耦抽象与实现：抽象层定义“做什么”并持有实现接口引用，实现层专注“怎么做”；双方各自独立扩展，新增类型无需修改现有代码，符合开闭原则。
桥接模式在 Java 中解耦抽象与实现，核心不是“连起来”，而是“断开继承、改用组合”，让两套逻辑各自生长、互不绑架。
抽象层只管“做什么”，不问“怎么做”
抽象类（如 Notification 或 Shape）不自己画图、不自己发短信，它只定义高层行为（send()、draw()），并持有一个实现接口的引用（比如 MessageSender 或 DrawingAPI）。这个引用通常通过构造函数注入，而不是 new 出具体实现。
- 抽象类不依赖任何具体实现类，只依赖接口
- 新增抽象子类（如
UrgentNotification）无需改动实现部分 - 抽象层可以按业务维度扩展：按消息类型、设备类型、用户等级等
实现层只管“怎么干”，不管“谁来调”
实现接口（如 MessageSender）定义能力契约（send(String content)），具体实现类（SmsSender、EmailSender、PushSender）只专注把这件事做对——用什么协议、走哪条通道、如何重试，都封装在自己内部。
- 实现类之间完全独立，互不影响
- 新增一种发送方式（比如加个
WebhookSender），只需实现接口，不改任何抽象类 - 实现层可以按技术维度扩展：渠道、协议、平台、性能策略等
桥本身是一条“弱关联”，不是父类子类关系
传统继承是“强绑定”：WindowsButton 继承自 Button，一旦要支持 macOS + 深色主题，就得写 WindowsDarkButton、macOSLightButton……类爆炸。桥接模式用组合替代继承：Button 持有 Theme 和 Platform 两个接口引用，运行时动态组装。
立即学习“Java免费学习笔记（深入）”；
- 抽象类构造时传入实现对象，形成“has-a”而非“is-a”
- 同一抽象实例可切换不同实现（例如测试时换 Stub 实现，生产换真实 API）
- 抽象和实现的编译期依赖被降到最低：抽象模块只依赖接口，实现模块只依赖自身
解耦后，新增组合不用改老代码
假设已有 3 种支付渠道（微信、支付宝、银联）和 4 种验证方式（密码、指纹、刷脸、短信）。不用桥接，组合数是 12，可能需要 12 个类或一堆 if-else；用桥接后：
- 抽象层：定义
PayChannel（含pay()），子类为WechatPay、Alipay等 - 实现层：定义
PayMode接口，实现类为PasswordMode、FingerprintMode等 - 新增 Apple Pay？加一个
ApplePay类即可；新增声纹验证？加一个VoiceMode即可 - 所有已有类都不动，符合开闭原则
