支付模块重构：命令模式返回值类型检查问题咨询

挺典型的支付模块重构场景——从一堆if-else的“意大利面代码”转向命令模式，这个方向完全没问题，但你遇到的强制类型转换痛点，其实是可以通过优化命令模式的设计来避免的，而非接受它作为“合理副作用”。咱们一步步拆解：

首先，你的核心问题：命令模式返回值的类型安全问题 #

标准命令模式确实通常不关注返回值（侧重封装请求、异步执行等），但在业务场景中（比如支付这种需要同步返回结果的操作），让命令返回值是完全合理的扩展——问题出在你当前的实现没有利用泛型来保证类型安全，导致了强制转换的尴尬。

方案1：泛型化命令接口，从根源消除类型转换 #

这是最直接的解决方案，给命令接口加上泛型参数，明确指定返回值类型，同时让工厂方法也支持泛型类型推断：

// 泛型化的基础命令接口
public interface PaymentCommand<T> {
    T execute(PaymentRequest request);
}

// 具体命令实现（比如EMI校验）
public class EmiSchemeValidationCommand implements PaymentCommand<EmiSchemeValidationResult> {
    @Override
    public EmiSchemeValidationResult execute(PaymentRequest request) {
        // 这里写具体的校验逻辑，直接返回对应类型的结果
        return new EmiSchemeValidationResult(...);
    }
}

// 调整工厂方法，支持泛型
public class PaymentCommandFactory {
    // 假设你有一个映射表，存储提供商+操作与命令类的对应关系
    private Map<CommandKey, Class<? extends PaymentCommand>> commandMap;

    @SuppressWarnings("unchecked") // 可通过提前注册的类型映射消除该警告
    public <T> PaymentCommand<T> create(String providerCode, String actionType, Class<T> resultClass) {
        CommandKey key = new CommandKey(providerCode, actionType);
        Class<? extends PaymentCommand> commandClass = commandMap.get(key);
        return (PaymentCommand<T>) commandClass.getDeclaredConstructor().newInstance();
    }

    // 辅助类：用于组合提供商编码和操作类型作为映射键
    private static class CommandKey {
        private String providerCode;
        private String actionType;
        // 构造方法、equals、hashCode省略
    }
}

// 调用的时候，完全不需要强制转换
EmiSchemeValidationResult result = commandsManager.getFactory(emiScheme.getPaymentProvider().getCode())
    .create(emiScheme.getPaymentProvider().getCode(), 
            PaymentActionEnum.EMI_SCHEME_VALIDATION.name(), 
            EmiSchemeValidationResult.class)
    .execute(schemeValidationRequest);

这样一来，编译期就能保证类型安全，再也不会出现ClassCastException的潜在风险。如果担心映射表的硬编码，可以结合注解+启动扫描来自动注册命令类（比如用自定义注解标记命令的提供商和操作类型，项目启动时扫描并加入映射）。

方案2：如果泛型不适合你的场景，试试“结果持有者”模式 #

如果因为项目约束不想用泛型，或者需要支持多类型返回，可以让命令执行时把结果存入一个预定义的“结果容器”，调用方从容器中获取对应类型的结果：

// 结果持有者类
public class PaymentResultHolder {
    private Map<Class<?>, Object> results = new HashMap<>();

    public <T> void setResult(Class<T> type, T result) {
        results.put(type, result);
    }

    @SuppressWarnings("unchecked")
    public <T> T getResult(Class<T> type) {
        return (T) results.get(type);
    }
}

// 调整命令接口
public interface PaymentCommand {
    void execute(PaymentRequest request, PaymentResultHolder resultHolder);
}

// 具体命令实现
public class EmiSchemeValidationCommand implements PaymentCommand {
    @Override
    public void execute(PaymentRequest request, PaymentResultHolder resultHolder) {
        EmiSchemeValidationResult result = new EmiSchemeValidationResult(...);
        resultHolder.setResult(EmiSchemeValidationResult.class, result);
    }
}

// 调用的时候
PaymentResultHolder holder = new PaymentResultHolder();
commandsManager.getFactory(emiScheme.getPaymentProvider().getCode())
    .create(PaymentActionEnum.EMI_SCHEME_VALIDATION.name())
    .execute(schemeValidationRequest, holder);
EmiSchemeValidationResult result = holder.getResult(EmiSchemeValidationResult.class);

这种方式虽然还是有隐式的类型转换，但把转换逻辑封装在了持有者类里，比直接在业务代码里转换更可控。

有没有其他架构方案？ #

除了命令模式，你也可以考虑策略模式+泛型——本质上和命令模式很像，只是策略模式更侧重“算法选择”，而命令模式侧重“请求封装”。对于支付模块的场景，两者都适用，核心都是把不同提供商/操作的逻辑拆成独立类。

另外，抽象工厂模式也是不错的选择：给每个支付提供商创建一个专属的工厂类，工厂类里提供该提供商所有操作的命令创建方法（比如createEmiValidationCommand()、createCreditCardAuthCommand()），这样调用方可以更明确地获取对应命令，进一步减少类型相关的问题。

总结 #

修改命令模式让它返回值完全合理——这是业务场景对设计模式的合理扩展，不是“副作用”。你当前遇到的类型转换问题，最优雅的解决方式是泛型化命令接口和工厂方法，从编译期保证类型安全。如果有特殊约束，再考虑结果持有者或其他模式替代。

不管用哪种方案，你从复制粘贴if-else转向面向对象的封装思路，已经是很大的进步了，继续坚持就好！

内容的提问来源于stack exchange，提问作者ashish.g