桥接模式通过分离抽象与实现并组合，解决多维度独立变化导致的类爆炸问题。它用n+m个类替代n×m继承组合，核心是抽象类持实现接口引用，实现解耦与动态切换。
继承导致的类膨胀，本质是把多个独立变化的维度强行耦合在继承树里。桥接模式不靠“多层继承”，而是用“抽象 + 实现”的分离 + 组合，让每个维度各自演进，类数量从 n × m 降到 n + m。
识别膨胀根源：是不是多维度独立变化？
先确认问题是否真适合桥接——不是所有继承都该改，只有满足以下情况才值得重构：
- 系统存在两个或以上彼此无关、可独立增减的变化方向（比如：消息类型 × 发送渠道 × 加密方式）
- 当前类结构呈“矩阵式爆炸”：每加一个维度取值，就得补全另一维度所有组合
- 你发现修改某个品牌/渠道/优先级时，大量子类被迫跟着动，违背单一职责
- 运行时需要动态切换实现（比如同一消息对象，临时改用邮件发送而非短信）
四步拆解：从继承树到桥接结构
以经典“图形（形状 × 颜色）”为例，原继承结构是：
RedCircle、BlueCircle、RedRectangle、BlueRectangle……
重构步骤如下：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
抽离实现维度接口：定义
Color接口（含fill()），再写Red、Blue具体实现类 -
抽象主类不再继承具体实现：
Shape变成抽象类，内部持有一个Color类型成员变量（聚合关系） -
子类只专注自身维度逻辑：
Circle和Rectangle只管怎么画轮廓，绘色动作委托给持有的Color对象 - 客户端组合使用：new Circle(new Red())、new Rectangle(new Blue()) —— 组合发生在运行时，不是编译期继承
关键细节：桥在哪？谁桥谁？
桥接模式里的“桥”，就是抽象类中那个指向实现接口的引用字段。它不负责实现，只负责转发调用。
立即学习“Java免费学习笔记（深入）”；
- 抽象部分（
Shape及其子类）可以自由扩展新形状，无需碰颜色代码 - 实现部分（
Color及其子类）可以自由新增颜色，无需修改任何图形类 - 两者通过接口契约通信，完全解耦；哪怕未来加
GradientColor或Circle3D，彼此零感知
避坑提醒：桥接不是万能胶
别为了用而用。以下情况桥接反而增加复杂度：
- 只有一个稳定维度在变（比如永远只有短信发送，只是消息内容格式不同 → 策略模式更轻量）
- 维度之间强依赖、无法独立替换（比如某种加密必须绑定特定签名算法，不能随意组合）
- 团队对面向接口编程不熟，强行引入
Implementor层会让新人读不懂调用链 - 项目已上线且改动成本高，而当前类数尚可控（10个以内）→ 优先保障稳定，留待迭代优化
