preface

The strategy pattern is a behavior design pattern that allows you to define a series of algorithms and place each algorithm in a separate class so that the objects of the algorithm are interchangeable.

Usage scenarios

Strategy mode is used in work is relatively more, such as payment scenario, billing scenario, preferential scenario, activity reward, user level and so on.

And of course there are a lot of straightforward ways of saying, just replace a whole bunch of if else.

if (x == aaa) {
    // 200 lines of code
} else if (x == bbb) {
    // 200 lines of code
} else if (x == ccc) {
    // 200 lines of code
}
Copy the code

According to the if else logic above, aaa, BBB, and CCC are different strategies. The purpose of using the policy pattern is to make it easier to extend when DDD, EEE, and so on are added.

Here are some examples of the scenarios encountered in work:

Here is an example of the charging strategy in the financial saving scenario: In the financial saving scenario, interest is paid to users every day, and users are divided into ordinary users and card holders, who have different interest rates and interest methods.

Obviously, to use the policy pattern when billing, follow the following pattern for development.

use

Defining the computing Interface

public interface RevenueCalculator {

    RevenueDTO calculate(BigDecimal asset);
}
Copy the code

Define different computing implementations

What is exposed is an interface, and the concrete implementation needs to be extended by itself. Three implementations are shown below.

@Component
public class DefaultRevenueCalculator implements RevenueCalculator {

    @Override
    public RevenueDTO calculate(BigDecimal asset) {

        return null; }}Copy the code
@Component
public class StepRateGeneralRevenueCalculator implements RevenueCalculator {

    @Override
    public RevenueDTO calculate(BigDecimal asset) {

        return null; }}Copy the code
@Component
public class StepRateHoldCardRevenueCalculator implements RevenueCalculator {

    @Override
    public RevenueDTO calculate(BigDecimal asset) {

        return null; }}Copy the code

Of course here StepRateHoldCardRevenueCalculator and StepRateGeneralRevenueCalculator have the same business logic abstraction, also can draw out a factory method.

None of that is the point here.

By implementing the interface, you can write a new implementation class later when there is a new billing policy.

Now the question is, how do I determine which users will follow that strategy?

Strategy class

public enum UserTypeEnum implements BaseEnum {

    /** * OWealth original interest method */
    DEFAULT_USER(-1."Original method of interest"."defaultRevenueCalculator"),
    /** * Common user */
    GENERAL_USER(0."Default user"."stepRateGeneralRevenueCalculator"),
    /** * Card holder */
    HOLD_CARD_USER(1."Cardholder"."stepRateHoldCardRevenueCalculator"),;// omit the code
}
Copy the code
public class RevenueCalculatorFactory {

    public static RevenueCalculator getCalculator(UserTypeEnum userType) {

        returnSpringContextHolder.getBean(userType.getServiceName()); }}Copy the code

This is just an introduction to using enumerations to maintain the relationship between the user type and the policy implementation. You can also write if else to determine the policy, or maintain it in the database.

conclusion

This article introduces the use of policy patterns at work and summarizes the scenarios that are often used:

  1. Choice of payment method: wechat, Alipay, UnionPay, etc
  2. Different charging policies: Different charging methods for different users (charges/freight, etc.)
  3. Activity rule selection: Different activities follow different computational logic
  4. Different ways of calculating interest: Different users (products) calculate interest differently

.

More need small partners to find and summarize.

Fishing, right here, can hit the fish, that depends on patience. Come on

The relevant data

  1. The in-depth design patterns: refactoringguru. Cn/design – patt…
  2. Cover: refactoringguru. Cn/design – patt…

Related to recommend

  • Design Patterns at work — Prototyping patterns
  • How does Spring address loop dependencies?
  • How did you resolve the Spring self-invocation transaction failure?