Java 桥接模式实战：解耦数据库与文件格式转换
在处理复杂业务时，我们常遇到需要同时支持多种维度的场景。比如一个数据转换工具，既要对接不同的数据库（Oracle、SQL Server），又要输出不同的文件格式（PDF、TXT、XML）。如果将所有组合都写在一个类里，代码会迅速膨胀且难以维护。桥接模式（Bridge Pattern）正是解决这类问题的利器，它将抽象部分与实现部分分离，使它们可以独立变化。
核心架构设计
在这个案例中，我们需要定义两个独立的维度：
- 抽象层：负责文件转换的逻辑（如 PDF、TXT、XML）。
- 实现层：负责底层数据的读取（如 Oracle、SQL Server）。
通过让抽象层持有实现层的引用，我们可以动态组合任意一种数据库和任意一种文件格式，而无需修改核心代码结构。
关键代码实现
1. 定义实现接口 (DataHandler)
首先，我们需要明确'数据读取'这一维度的契约。无论底层是哪种数据库，对外提供的读取能力应该是一致的。
package step1;
public abstract class DataHandler {
public abstract void readData();
}
这个抽象类强制所有具体的处理器（例如 OracleHandler、SQLServerHandler）实现各自的读取逻辑。这样上层转换逻辑就不需要关心数据具体来自哪里。
2. 定义抽象层 (FileConvertor)
接下来是文件转换的抽象基类。它不直接处理数据，而是委托给 DataHandler 去获取数据。
package step1;
public abstract class FileConvertor {
// 持有实现部分对象引用
protected DataHandler dataHandler;
public void setDataHandler(DataHandler dataHandler) {
this.dataHandler = dataHandler;
}
// 抽象的转换方法，由具体子类实现
public abstract void translate();
}
注意这里的 dataHandler 成员变量。这是桥接模式的关键，它允许我们在运行时注入具体的数据源。translate() 方法定义了转换行为的接口，具体格式的处理留给子类完成。
3. 具体转换器实现
针对不同的文件格式，我们创建具体的转换器子类。以 PDF 和 TXT 为例，它们的逻辑非常相似：先调用底层的 readData()，再执行特定的格式化输出。
PDFConvertor.java
package step1;
public class PDFConvertor extends FileConvertor {
@Override
public void translate() {
// 调用实现部分的方法读取数据
dataHandler.readData();
System.out.println("转换成 PDF 格式的数据");
}
}
TXTConvertor.java
package step1;
public class TXTConvertor extends FileConvertor {
@Override
public void translate() {
dataHandler.readData();
System.out.println("转换成 TXT 格式的数据");
}
}
XMLConvertor.java
package step1;
public class XMLConvertor extends FileConvertor {
@Override
public void translate() {
dataHandler.readData();
System.out.println("转换成 XML 格式的数据");
}
}
可以看到，这些转换器只关注'如何转换'，而不关心'数据从哪来'。这种职责分离大大简化了代码结构。
运行效果与扩展性
在实际应用中，客户端只需要实例化具体的转换器和对应的处理器，并通过构造函数或 Setter 方法将它们关联起来。
例如，若要实现'从 Oracle 数据库读取数据转换成 PDF 格式'，只需组合 PDFConvertor 和 OracleHandler；若需改为 SQL Server 转 TXT，则替换为 TXTConvertor 和 SQLServerHandler。
这种设计带来的最大好处是开闭原则（Open/Closed Principle）的体现：新增一种数据库格式或一种文件类型时，只需添加新的类，无需修改现有的转换逻辑。系统在面对需求变更时，保持了极高的灵活性和可维护性。
小结
桥接模式不仅仅是代码结构的调整，更是一种思维方式的转变。通过将'做什么'（转换）和'怎么做'（读取）解耦，我们构建了一个能够应对未来变化的健壮系统。在开发涉及多对多关系的业务模块时，不妨优先考虑这种模式。
