Dart多支付服务设计：规避工厂模式下的类型转换问题

问题背景 #

我正在编写一个Dart支付服务类，用于封装多个支付提供商，期望调用者能够无缝切换不同提供商。现有类结构如下：

enum PaymentProvider { providerA, providerB }

abstract class PaymentService {
   void processPayment(Order oder);
}

class PaymentServiceA implements PaymentService {
    final String appKey;
    final String merchantId;
    
    PaymentServiceA(this.appKey, this.merchantId);


    @override
    void processPayment(Order oder) {
      // concrete implementation to process payment
    }

    String getVoucher() {
       // return voucher code
    }
}

class PaymentServiceB implements PaymentService {
    final PaymentBOptions options;
    
    PaymentServiceB(this.options);


    @override
    void processPayment(Order oder) {
      // concrete implementation to process payment
    }

    List<PaymentBHistory> getPaymentHistory() {
      // return payment history
    }

}

class PaymentBOptions {
   final bool sendEmailReceipt;
   final Function()? successCallback;

   PaymentBOptions(this.sendEmailReceipt, this.successCallback);
}

PaymentServiceA与PaymentServiceB拥有统一的processPayment方法，因此可通过抽象类PaymentService实现统一接口，但二者的构造参数及专属方法存在差异。

我尝试使用工厂模式实现，代码如下：

abstract class PaymentService {
   factory PaymentService(PaymentProvider provider) {
      switch(provider) {
        case PaymentProvider.providerA:
          String appKey = "xxxx";
          String merchantId = "123";
          return PaymentServiceA(appKey, merchantId);
        case PaymentProvider.providerB:
          PaymentBOptions options = PaymentBOptions(true, () {});
          return PaymentServiceB(options);        
      }
   }

 
   void processPayment(Order order);
}

但该实现存在两点问题：

• 通过工厂方法创建的实例以PaymentService类型返回，需强制转换才能访问专属方法；
• 无法在抽象类外部为PaymentServiceA或PaymentServiceB传入专属构造参数。

最佳实践与设计模式建议 #

1. 抽象工厂模式+依赖注入解决构造参数问题 #

抽象工厂模式适配这种需要创建差异化实例的场景，我们可以定义一个抽象工厂类，再为每个支付提供商实现具体工厂，让外部能灵活传入专属构造参数：

abstract class PaymentServiceFactory {
  PaymentService createService();
}

class PaymentServiceAFactory implements PaymentServiceFactory {
  final String appKey;
  final String merchantId;

  PaymentServiceAFactory(this.appKey, this.merchantId);

  @override
  PaymentService createService() {
    return PaymentServiceA(appKey, merchantId);
  }
}

class PaymentServiceBFactory implements PaymentServiceFactory {
  final PaymentBOptions options;

  PaymentServiceBFactory(this.options);

  @override
  PaymentService createService() {
    return PaymentServiceB(options);
  }
}

调用方式示例：

// 创建ProviderA的服务实例
final aFactory = PaymentServiceAFactory("your_app_key", "your_merchant_id");
final paymentServiceA = aFactory.createService();

// 创建ProviderB的服务实例
final bOptions = PaymentBOptions(true, () => print("Payment success!"));
final bFactory = PaymentServiceBFactory(bOptions);
final paymentServiceB = bFactory.createService();

2. 处理专属方法：避免强制类型转换的两种方案 #

方案一：利用Dart类型判断+类型提升

如果专属方法仅在特定场景调用，可直接通过类型判断触发Dart的自动类型提升，无需强制转换：

void handlePayment(PaymentService service, Order order) {
  service.processPayment(order);
  
  if (service is PaymentServiceA) {
    // 直接调用专属方法，无需强制转换
    String voucher = service.getVoucher();
    print("Voucher: $voucher");
  } else if (service is PaymentServiceB) {
    List<PaymentBHistory> history = service.getPaymentHistory();
    print("Payment history count: ${history.length}");
  }
}

方案二：定义扩展接口实现能力解耦

如果希望更优雅地抽象差异化能力，可以新增专属接口，让具体服务类按需实现：

// 新增优惠券能力接口
abstract class VoucherProvider {
  String getVoucher();
}

// 新增支付历史能力接口
abstract class PaymentHistoryProvider {
  List<PaymentBHistory> getPaymentHistory();
}

// 修改PaymentServiceA实现优惠券接口
class PaymentServiceA implements PaymentService, VoucherProvider {
  // ... 原有代码
  
  @override
  String getVoucher() {
    // 具体实现逻辑
    return "VOUCHER_2024";
  }
}

// 修改PaymentServiceB实现支付历史接口
class PaymentServiceB implements PaymentService, PaymentHistoryProvider {
  // ... 原有代码
  
  @override
  List<PaymentBHistory> getPaymentHistory() {
    // 具体实现逻辑
    return [];
  }
}

调用时通过接口判断：

void handleExtraFeatures(PaymentService service) {
  if (service is VoucherProvider) {
    print("Got voucher: ${service.getVoucher()}");
  }
  if (service is PaymentHistoryProvider) {
    print("History count: ${service.getPaymentHistory().length}");
  }
}

3. 结合策略模式优化切换逻辑 #

如果需要频繁切换支付提供商，可结合策略模式封装支付处理逻辑，让调用端更简洁：

class PaymentProcessor {
  PaymentService _currentService;

  PaymentProcessor(this._currentService);

  void processOrder(Order order) {
    _currentService.processPayment(order);
  }

  // 动态切换支付服务
  void switchPaymentService(PaymentService newService) {
    _currentService = newService;
  }
}

使用示例：

final processor = PaymentProcessor(paymentServiceA);
processor.processOrder(order);

// 切换到ProviderB
processor.switchPaymentService(paymentServiceB);
processor.processOrder(order);

总结 #

• 用抽象工厂模式解决不同支付服务的构造参数差异化问题，支持外部灵活传入专属配置；
• 用类型判断+类型提升或扩展接口的方式处理专属方法，避免强制类型转换；
• 结合策略模式优化支付服务的切换与调用逻辑，降低调用端复杂度。

内容的提问来源于stack exchange，提问作者ikhsanudinhakim