Design pattern: Talk about strategic pattern from the design of aggregated payment services

1. preface

Mobile payment is now very popular in China. Even the seventies-year-old lady at the breakfast stall downstairs uses Alipay and Weixin Pay to sell egg cakes. If you are asked to make an App, you must definitely consider multiple payment channels to ensure that you can get customers. What would you design if you were given access to multiple payment channels?

2. common writing

Generally, the following writing is easy to create:

      (){

        =;
         (){
            
        }  (){
            
        }  (){
           
        }
        ;
    }

If four or five payments are integrated, the code will not be able to read at least a few thousand lines, and changing the logic of one payment can easily change the logic of other payments. Therefore, reasonable design is needed to avoid this risk.

3. strategy pattern

Most payments can be simplified to this process:

the middlePre-payment logicandPost-payment processing logicIt is the customized business logic of the client. Requests sent to the payment server will only carry parameters corresponding to the specific requirements of the payment server to invoke different payments.SDK。So we establish policies corresponding to payment methods to isolate and distinguish them and reduce their coupling. When preparing to pay, we only need to choose the corresponding strategy.

This uses the strategy pattern in the design pattern:

Combined with the above class diagram, let's talk about the main roles in the strategy model based on requirements.

• StrategyInterface. This interface is used to declare independent execution strategies for each method and to encapsulate the unique algorithm logic of specific policies.
• ConcreteStrategyisStrategyimplementation class. Algorithm logic for different strategies is implemented. Such as the call details of each payment, etc.
• ContextContext. It references specific policies through the policy interface and uses specific policies to execute logic. At the same time, the commonalities of all policies can also be handled uniformly in this class. In aggregating payment requirements, we pass in a strategy, first implement the pre-payment logic, then use the strategy, and after the strategy is executed, we implement the post-common logic.
• ClientClient. Create a policy object and pass it to the contextContext, and then the specific policy is run by the context.

The combined business logic looks like this:The request reaches the client, and the client builds a corresponding policy object based on the payment channel contained in the request and hands it over to the context object to perform the payment process.

Then we can construct three policy objects for Alipay, Weixin Pay, and UnionPay Payment respectively AliPayStrategy、WechatPayStrategy、UnionPayStrategy Let's simulate the execution strategy:

   {

       ([]) {
        
        = ;
        = ;
        = ;

         (..().()) {
            =  ();
            =  ();
        }
         (..().()) {
            =  ();
            =  ();
        }

         (..().()) {
            =  ();
            =  ();
        }

         (.()) {
            =  ();.();.();
        }
    }
}

We get the payment ID in the request, then initialize the corresponding payment policy, encapsulate the specified request parameters, and hand them to the context objectPayContext to execute the request. If you add anything moreApplePayor something like that to achieve.ApplePayStrategyJust do it.

4. advantages and disadvantages

Not all strategic models have positive effects.

4.1 advantages

• We isolate the implementation of the algorithm from the use of the algorithm. The implementation of the algorithm only cares about the logic of the algorithm, and the use of the algorithm only cares about what algorithm to use under what conditions.
• The open-close principle requires no modification of the context object. If you want to expand, you only need to introduce new strategies.
• Dynamic de-switching algorithm based on conditions at runtime.
• While adapting to individuality, you can also accommodate commonalities.

4.2 disadvantages

• The client must clearly know the conditions of the activation policy.
• Introduce too many policy classes.
• Can be replaced by some functional interfaces. pseudocodePay.request(data).strategy(data->{ })。

5. summary

Policy patterns are also common and widely used design patterns. Today, we learned the strategy model from aggregated payments and also conducted an analysis of its advantages and disadvantages. withfunctional programmingWith the popularity of the strategic model, the strategic model has begun to be gradually replaced, but it is still worth learning.