桥接模式中Abstraction可用抽象类但非必须，Implementor必须用接口；抽象类适合封装共通逻辑，但会限制子类继承能力，且易破坏解耦原则。
抽象类在桥接模式里该不该用？
桥接模式的核心是把「抽象」和「实现」解耦，让两者能独立变化。Java 里抽象类可以承担抽象部分（Abstraction），但要注意：它不能同时作为实现部分（Implementor）——因为实现部分必须能被多个抽象复用，而抽象类不支持多继承，且容易让子类误以为“继承即绑定实现”。所以，Implementor 必须用接口，Abstraction 可以用抽象类，但不是必须。
- 用抽象类定义
Abstraction适合有共通逻辑（比如统一的日志、校验、缓存封装）需要下放给所有子类 - 如果只是定义行为契约，直接用接口更轻量、更灵活
- 一旦用了抽象类，子类就失去了继承其他父类的机会，后续扩展受限
怎么写一个带抽象类的桥接结构？
关键在于抽象类只持有一个 Implementor 接口引用，不关心具体实现是谁。所有业务逻辑通过委托调用完成，而不是继承或重写实现细节。
示例结构：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
interface Renderer {
void render(String data);
}
abstract class Shape {
protected Renderer renderer; // 持有接口，不是具体类
public Shape(Renderer renderer) {
this.renderer = renderer;
}
public abstract void draw();
}
class Circle extends Shape {
private double radius;
public Circle(Renderer renderer, double radius) {
super(renderer);
this.radius = radius;
}
@Override
public void draw() {
renderer.render("Circle with radius " + radius);
}
}
-
Shape是抽象类，封装了renderer字段和构造逻辑，避免每个子类重复写 -
draw()是抽象方法，强制子类决定“怎么画”，但不干涉“怎么渲染” - 新增
Square或换OpenGLRenderer都不需要改Shape类
为什么 new 实现类时传进去，而不是在抽象类里 new？
这是桥接模式最容易踩的坑：在 Shape 构造器里直接 new OpenGLRenderer()，等于把实现硬编码进抽象层，彻底破坏桥接意义。
立即学习“Java免费学习笔记（深入）”；
- 抽象类里只声明
Renderer renderer，不初始化 - 初始化交给子类或外部工厂（比如
new Circle(new SvgRenderer(), 5.0)） - 否则会导致单元测试无法 mock 渲染行为，也丧失运行时切换实现的能力
- Spring 等框架注入
Renderer时，也是基于这个原则——依赖由外向内传递
抽象类 vs 接口做 Abstraction 的实际影响
性能上没区别，但会影响可维护性。Java 8+ 接口可以有 default 方法，很多原本靠抽象类共享的逻辑现在也能放接口里。
- 如果只需要共享字段（如
renderer）和构造流程，用抽象类更直观 - 如果未来可能让
Shape同时继承另一个基类（比如SerializableEntity），就必须改用接口 - 抽象类一旦加了
protected方法，容易被子类滥用，变成“半实现”，偏离桥接初衷 - 多人协作时，抽象类比接口更容易被无意中添加状态或复杂初始化逻辑
Shape 子类管；而像素绘制、着色管线、输出格式这些，必须彻底交给 Renderer 及其具体实现。一不留神把后者塞进抽象类，桥就塌了。 
