Android 策略设计模式的使用：使用设计模式，减少烂代码，让项目更好维护

news2024/11/24 5:37:30

前言：为什么要使用设计模式

在项目开发过程中，我们会对接很多种支付：国内（微信、支付宝），海外（日本的TakeMe、UnivaPay）等等，如果我们使用的是MVVM、或者MVP架构，那么这些逻辑都会在VM层或者P层。比如：

class QrCodeFragmentVM  {

    /**
     * 微信支付宝 获取二维码
     */
    fun twoPayCode() {}

    /**
     * takeMe Pay 获取二维码
     */
    fun takeMePay(){}

    /**
     * univa Pay 获取二维码
     */
    fun univaPay(){}


    /**
     * univa Pay 查询支付结果
     */
    fun univaPayStateQuery(){}

    /**
     * takeMe Pay 查询支付结果
     */
    fun takeMePayStateQuery(){}


}

可以看到，有很多的方法，如果后面再持续增加，那么就会很混乱，各种支付方式的方法都融合在一个类里面，久了以后，你甚至都不知道univa pay的请求方法有几个，可能有两个或者三个，会导致后面代码难以维护和新增。增加越多，越棘手。

所以接下来，我们介绍一种策略设计模式，来解决这个问题，为什么要使用设计模式呢，设计模式的作用，其实就是减少烂代码，让项目可以更好维护，不过也要视情况而使用。

一、策略和工厂设计模式来解决

1.1 定义一个接口：抽取共同项

我们来直接看代码，将支付的共同项进行一个抽取，每个策略都会有发起支付和查询交易结果的方法。

/**
 * 支付 接口 策略模式
 */
interface PaymentStrategy {

    /**
     * 发起支付
     * @param price 金额   -- 使用map，因为参数有可能很多~
     */
    suspend fun pay(params: Map<String, String>):Flow<String>


    /**
     * 查询交易结果
     */
    suspend fun queryPayState(params: Map<String, String>):Flow<String>

}

这里的参数使用Map，非常的重要，因为每种支付方式，他的参数是不一样的，如果你使用String，那么就得重载很多方法，很多参数，不利于复用。

1.2 创建一个类做默认实现

下面我们要创建一个类来做默认的实现，就像前面说的，有可能有些支付，他不只是两个方法，可能他还有上传交易结果的方法，如果直接实现接口，那么就得实现一个多余方法，所以我们这里就增加一个类做默认的实现。

/**
 * 支付 接口 策略模式 提供默认实现
 */
abstract class DefultPayMentStrategy : PaymentStrategy {

    override suspend fun pay(params: Map<String, String>):Flow<String> {
        return request {  }
    }

    override suspend fun queryPayState(params: Map<String, String>): Flow<String> {
        return request {  }
    }

1.3 具体的实现类：比如微信支付宝类、日本TakeMepay

接下来，就是我们的重头戏，将支付服装成一个类，各自提供自己的实现。


/**
 * 微信支付宝 类
 */
class WeChatAlipayPayMent @Inject constructor() : DefultPayMentStrategy() {
    private val TAG = "WeChatAlipayPayMent"

    /**
     * 发起支付
     */
    override suspend fun pay(params: Map<String, String>)= request<String> {
       // 请求微信支付宝的二维码。
    }

	....
}


/**
 * 日本支付 类
 */
class TakeMepayPayMent @Inject constructor() : DefultPayMentStrategy() {
    private val TAG = "TakeMepayPayMent "

    /**
     * 发起支付
     */
    override suspend fun pay(params: Map<String, String>)= request<String> {
       //请求日本支付的二维码
    }

	....
}

其实，到这里就已经发现，已经解决了我们的问题，各类的支付放到自己的类里面，这样方法就不会混乱，区分开来，这样就好维护很多。

1.4 创建支付策略工厂

由于我们需要在运行时决定使用哪个策略，我们可以创建一个工厂类来管理策略的创建。

@Singleton
class PaymentService @Inject constructor(
    private val weChatAlipayPayMent: WeChatAlipayPayMent，
     private val takeMepayPayMent: TakeMepayPayMent
) {
    fun getPaymentStrategy(type: String): PaymentStrategy {  
        return when (type) {  
            "weChatAlipayPayMent" -> weChatAlipayPayMent//微信支付
             "TakeMepayPayMent " -> takeMepayPayMent//日本支付
            else -> throw IllegalArgumentException("Unknown payment type: $type")
        }  
    }  
}

1.5 具体的使用

可以看到有了工厂以后，我们直接提供一个字符串就会生成对应的支付，也不需要我们创建对象了。

 @Inject
    lateinit var paymentService: PaymentService

    /**
     * 微信支付宝 获取二维码
     */
    fun twoPayCode() {
        viewModelScope.launch(Dispatchers.IO) {
            val paymentStrategy = paymentService.getPaymentStrategy("weChatAlipayPayMent")
        }
    }