桥接模式中接口是实现维度的契约层，抽象类通过组合持有其引用，具体实现类专注“做什么”而不暴露细节，支持松耦合、运行时切换与多维度扩展。

Java 中接口是桥接模式落地的关键载体，它天然适合作为“实现维度”的契约层，把抽象逻辑和底层细节隔开。核心不在于接口本身多复杂，而在于它如何被抽象类持有、如何被具体实现类填充，以及两者之间如何保持松耦合、可替换、可扩展。

用接口定义实现维度的统一契约

实现维度接口（Implementor）要聚焦“做什么”，不关心“怎么做”。比如绘图系统中，定义 DrawAPI 接口：

• 只声明 drawCircle(double x, double y, double radius) 这类基础操作
• 不暴露 OpenGL 或 Vulkan 的内部类型或配置细节
• 方法签名稳定，便于后续新增 VulkanDrawAPI、Canvas2DDrawAPI 等实现而不影响上层

抽象类通过组合持有接口引用，而非继承实现

抽象类（Abstraction）如 Shape 不继承任何具体绘图类，而是声明一个 protected DrawAPI drawingAPI 字段：

• 构造时传入具体实现，例如 new Circle(100, 100, 50, new OpenGLDrawingAPI())
• 所有业务方法（如 draw()）内部调用 drawingAPI.drawCircle(...)
• 客户端完全不知道也不需要知道背后是哪种图形 API

接口粒度要合理，避免过粗或过细

接口设计直接影响桥接是否灵活：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

立即学习“Java免费学习笔记（深入）”；

• 太粗（如一个 render(Object config)）会让具体实现难以复用，也失去类型安全
• 太细（如为每种图形+每种颜色+每种抗锯齿模式拆出独立方法）会增加维护成本
• 推荐按“能力维度”划分：颜色、渲染目标、坐标系、线型等可各自定义接口，再由抽象层组合使用

运行时动态切换实现，靠的就是接口多态

因为抽象类依赖的是接口类型，所以可以在不改代码的前提下换实现：

• shape.setDrawingAPI(new VulkanDrawingAPI());
• 日志框架中，Logger 抽象持有一个 Appender 接口，随时从 FileAppender 切到 KafkaAppender
• 关键前提是：所有具体实现类都遵守同一接口契约，且抽象层不强依赖实现类的额外方法

接口在这里不是装饰，而是桥梁的桥墩——稳住实现侧的多样性，托起抽象侧的稳定性。