本文目录导读：
- 核心思想：依赖倒置 + 策略模式 + 适配器模式
- 方案一：接口抽象 + 适配器模式 —— 最基础、最常用
- 方案二：模板方法模式 —— 适用于流程固定但步骤实现不同
- 方案三：责任链模式 + 策略模式 —— 适用于复杂、可动态编排的流程
- 方案四：领域驱动设计 + 策略注册表 —— 高级企业级方案
- 实战中的统一流程骨架（参考）
- 选型建议
在Java中实现“兼容调用流程的统一”，核心目标是屏蔽底层实现的差异（如不同数据库、不同消息队列、不同第三方API、不同版本协议），让上层业务代码以统一的方法签名和调用方式进行交互。
下面是实现这一目标的几种主流设计模式与实战方案,从接口设计到流程编排，逐层深入。
核心思想：依赖倒置 + 策略模式 + 适配器模式
- 接口（抽象）：定义统一的调用契约。
- 适配器：将各种具体的、不兼容的实现转换为统一的接口。
- 策略/工厂：根据运行时条件（如配置、版本号、环境）选择具体的适配器实例。
- 模板方法：定义调用流程的骨架，将具体步骤延迟到子类实现。
接口抽象 + 适配器模式 —— 最基础、最常用
适用场景：统一调用外部服务（如支付、短信、存储），或统一调用不同版本的内部模块。
步骤：
- 定义统一接口：定义业务层面的调用方法。
- 实现不同适配器：针对不同兼容需求，实现接口。
- 使用工厂/策略获取实例：根据标识（如版本号、类型）返回对应实例。
代码示例：统一支付调用
// 1. 统一接口
public interface UnifiedPaymentService {
PaymentResult pay(Order order);
PaymentResult refund(RefundRequest request);
}
// 2. 适配器1: 支付宝
public class AlipayAdapter implements UnifiedPaymentService {
@Override
public PaymentResult pay(Order order) {
// 调用支付宝 SDK
AlipayClient client = new DefaultAlipayClient(...);
AlipayTradePayRequest request = new AlipayTradePayRequest();
// ... 转换参数 ...
return convertToStandardResult(client.execute(request));
}
// ...
}
// 适配器2: 微信支付
public class WechatPayAdapter implements UnifiedPaymentService {
@Override
public PaymentResult pay(Order order) {
// 调用微信支付 SDK
WxPayApi.pay(...);
return convertToStandardResult(...);
}
}
// 3. 工厂类
public class PaymentFactory {
public static UnifiedPaymentService getInstance(String channel) {
// 根据 channel 返回 AlipayAdapter 或 WechatPayAdapter
}
}
// 调用方
public class PaymentService {
public void processPayment(Order order) {
// 统一调用，无需关心底层是支付宝还是微信
UnifiedPaymentService service = PaymentFactory.getInstance(order.getChannel());
service.pay(order);
}
}
优点：实现简单，耦合度低。
缺点：如果流程复杂（如多重条件判断），适配器内部可能膨胀。
模板方法模式 —— 适用于流程固定但步骤实现不同
适用场景：统一一个“标准流程”（如文件导入、数据同步），流程步骤相同，但每一步的实现不同（如从CSV导入 vs 从JSON导入）。
步骤：
- 定义抽象类，包含模板方法（
process()）和抽象步骤（read()、validate()、transform()）。 - 子类实现具体步骤。
代码示例：统一数据导入流程
// 抽象流程类
public abstract class DataImporter {
// 模板方法：定义统一流程
public final Result doImport(ImportParams params) {
Data data = read(params); // 步骤1: 读取
boolean valid = validate(data); // 步骤2: 校验
if (!valid) { return new Result(false, "validate failed"); }
TransformResult transformResult = transform(data); // 步骤3: 转换
boolean saved = save(transformResult); // 步骤4: 存储
audit(saved); // 步骤5: 审计（通用实现）
return new Result(saved);
}
// 子类必须实现这些步骤
protected abstract Data read(ImportParams params);
protected abstract boolean validate(Data data);
protected abstract TransformResult transform(Data data);
protected abstract boolean save(TransformResult result);
// 公共实现：审计日志
private void audit(boolean success) {
System.out.println("Audit: " + success);
}
}
// 具体子类：CSV导入
public class CsvImporter extends DataImporter {
protected Data read(ImportParams params) { /* 读CSV */ }
protected boolean validate(Data data) { /* CSV校验规则 */ }
// ...
}
// 具体子类：API导入
public class ApiImporter extends DataImporter {
protected Data read(ImportParams params) { /* 调API */ }
protected boolean validate(Data data) { /* API校验规则 */ }
// ...
}
// 调用方：统一调用
String type = "csv"; // 或 "api"
DataImporter importer = type.equalsIgnoreCase("csv") ? new CsvImporter() : new ApiImporter();
importer.doImport(params); // 内部流程完全统一
优点：流程复用性好，修改流程入口（如增加校验步骤）只需改抽象类。
缺点：类型固定，子类数量可能增多。
责任链模式 + 策略模式 —— 适用于复杂、可动态编排的流程
适用场景：统一调用一个由多个处理单元组成的“处理链”，且链的顺序或组合可能是动态的（如支付风控、消息过滤、审批流）。
步骤：
- 定义处理节点接口。
- 实现具体处理节点。
- 构建调用链：可配置化或程式化。
- 发起统一调用：请求依次经过各个节点。
代码示例：统一消息处理流程
// 1. 处理节点接口
public interface MessageProcessor {
boolean process(Message msg);
}
// 2. 具体节点
public class RateLimitProcessor implements MessageProcessor {
public boolean process(Message msg) {
if (isLimited()) { return false; } // 被限流
return true; // 继续链式传递
}
}
public class AuthenticateProcessor implements MessageProcessor {
public boolean process(Message msg) {
if (!validToken(msg)) { return false; }
return true;
}
}
public class DispatchProcessor implements MessageProcessor {
public boolean process(Message msg) {
// 最后一步：分发到实际业务
return true;
}
}
// 3. 调用统一化（建造者模式或配置）
public class UnifiedProcessService {
private List<MessageProcessor> chain;
public UnifiedProcessService(List<MessageProcessor> chain) {
this.chain = chain;
}
public boolean execute(Message msg) {
for (MessageProcessor processor : chain) {
if (!processor.process(msg)) {
return false; // 链式中断（责任链模式的关键）
}
}
return true;
}
}
// 调用方
List<MessageProcessor> chain = Arrays.asList(
new RateLimitProcessor(),
new AuthenticateProcessor(),
new DispatchProcessor()
);
UnifiedProcessService service = new UnifiedProcessService(chain);
service.execute(message); // 统一入口
优点：高度灵活，可编排。
缺点：对于简单场景，可能过度设计。
领域驱动设计 + 策略注册表 —— 高级企业级方案
当兼容调用场景极其复杂,且需要动态管理多种“调用策略”时。
核心：
- 定义策略接口：如上文的
UnifiedPaymentService。 - 使用 Spring Bean 注册：利用
@Component+Map<String, Service>注入。 - 包装成统一门面 (Facade)：
// 利用 Spring 管理策略
@Service
public class PaymentFacade {
@Autowired
private Map<String, UnifiedPaymentService> serviceMap; // key是bean名字或自定义标记
public PaymentResult pay(String channel, Order order) {
UnifiedPaymentService service = serviceMap.get(channel + "PaymentAdapter");
if (service == null) { throw new UnsupportedOperationException(); }
return service.pay(order); // 绝对统一
}
}
优势：无需硬编码工厂，新增一个实现只需增加一个 @Component 类，完全符合开闭原则。
实战中的统一流程骨架（参考）
无论采用哪种模式,一个成熟的Java项目在处理统一调用时，通常具备如下骨架：
统一入口 (Facade 或 Controller)
|
1. 参数预处理 & 校验 (统一校验框架, 如Hibernate Validator)
|
2. 获取策略/适配器 (策略工厂 / Spring Bean Map)
|
3. 执行核心调用 (调用统一接口)
|
4. 统一异常处理 (全局异常拦截器)
|- 将不同类型异常（如微信异常、数据库异常）统一转换为业务异常
|
5. 统一结果封装 (Response<T> AOP)
|- 保证所有返回类型一致 (code, message, data)
|
6. 异步/同步日志审计 (AOP 或 Event)选型建议
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 调用外部不同服务 (支付/短信/OSS) | 接口 + 适配器 + 工厂 | 简单清晰，接口稳定 |
| 内部流程固定但步骤不同 (导入/导出/同步) | 模板方法模式 | 流程复用，避免重复代码 |
| 动态编排处理链 (风控/审批/管道处理) | 责任链模式 | 灵活可配置，易扩展 |
| 大量策略需要动态管理 (企业级多实现) | Spring Bean Map + 门面 | 零侵入，自动注入，强扩展 |
| 需要兼容遗留系统或老版本 | 适配器模式 + 版本路由 | 新老代码共存，平滑迁移 |
核心原则：编程到接口，而非实现，无论选择哪种模式，最终的目标都是让业务代码只依赖于稳定的抽象接口，而将具体兼容逻辑隐藏在接口的实现层和管理层中。
