I Love ReactJS

JavaScript common design patterns (2) Strategic patterns

Today we are going to learn the common design pattern of JavaScript-- the strategy pattern

definition

defines a series of algorithms, encapsulating them individually, and making them interchangeable.

extract and encapsulate seemingly unrelated code to make it easier to understand and expand. Let's understand it through an example:

Application scenario

there are different strategies to accomplish several things. For example, performance calculation, form validation rules

calculate the year-end bonus after performance appraisal. S performance is four months' salary, A performance is three months' salary, B performance is two months' salary

before use

define a function to calculate bonus calculateBonus . The input parameters of the function are performance level and monthly salary

function calculateBonus(level, salary) {
  switch (level) {
    case "s": {
      return salary * 4;
    }
    case "a": {
      return salary * 3;
    }
    case "b": {
      return salary * 2;
    }
    default: {
      return 0;
    }
  }
};

calculate bonus

calculateBonus('s', 10000); // 40000
calculateBonus('a', 5000); // 15000

if we want to modify the performance rules, we need to change the logic in the calculateBonus function, which violates the open and closed principle, so we can consider using the policy mode at this time.

improve

decouple all the logic

function getS(salary){
  return salary * 4
}
function getA(salary){
  return salary * 3
}
function getB(salary){
  return salary * 2
}

function calculateBonus(level, salary) {
  switch (level) {
    case "s": {
      return getS(salary);
    }
    case "a": {
      return getA(salary);
    }
    case "b": {
      return getB(salary);;
    }
    default: {
      return 0;
    }
  }
};

this is still a lot of logical judgment, we can need to build a mapping relationship, build a strategy table of performance rules

use policy mode

construct a policy table using object mapping in JavaScript

const strategies = {
  s: (salary) => {
    return salary * 4;
  },
  a: (salary) => {
    return salary * 3;
  },
  b: (salary) => {
    return salary * 2;
  },
};

define the function to calculate the bonus, the function input is the performance level and monthly salary, and then go to the strategy table to find the rules of the performance bonus.

function calculateBonus(level, salary) {
  return strategies[level](salary);
};

you can finally use this policy mode. When using one of the performance calculation algorithms, it can be located directly through the label signature.

calculateBonus('s', 10000); // 40000
calculateBonus('a', 5000); // 15000

Let's look at the definition of the policy pattern: defines a series of algorithms, encapsulates them one by one, and makes them interchangeable.

PS: here the replaces each other is actually for statically typed languages. There is a type checking mechanism in statically typed languages, so each policy class needs to implement the same interface. Only when real types are hidden behind interfaces can they be replaced with each other. In a weakly typed language like JavaScript , any object can be used interchangeably. Therefore, "substitution" in JavaScript can be understood as having the same goal and intention.

Exit mobile version