Recently, while maintaining an old project, a former colleague left me with this business logic code. Does it feel familiar?

if (a == 1) {
  if (b && d = 1 || e = 2 && d = 3) {
    if (c && d = 1 || e = 2) {... }else{... }}}else if (a == 2) {
  if (b) {
    if(c) {... }}}else if (a == 3) {
  if (b) {
    if(c) {... }}}Copy the code

Why change it

Is there a problem with this code? No problem, the function has been running stably, if the next time more cases need to be judged, then it will be difficult to maintain, and this is also a 999 critical hit damage to colleagues, ok? Although not a fight, but will certainly be despised, improve the code readability and maintainability urgently. When you change someone else’s code, you only need to change one method, but it can take half a day to comb through the business logic. That one line of code affects the entire business logic, bugs or bugs everywhere, and you crash… How to maintain a good relationship with your colleagues and impress them?

If you want to keep a close relationship with a coworker you just met, read on

Evolution: the switch

switch (a) {
case 1:
  b(123);
  break;
case 2:
  b(567);
  break;
case 3:
  switch(res){
    case 1:
    b(234);
    break;
  }
  break;
}
Copy the code

Switch relative to if… Else statements improve the readability of the code significantly, although multiple judgments can be a bit of a drag and can affect the readability of the code.

Evolution: State patterns

function resultState(type) {
  let state = {
    state0: function() {
      / / 1
    },
    state1: function() {
      / / 2
    },
    state2: function() {
      / / 3
    },
    state3: function() {
      / / 4
    },
    state4: function() {
      / / 5
    }
  },
  result = 'state' + type;

  state[result] && state[result]()
}

// Execute the first case
resultState(1)
Copy the code

The above code works for multiple if… Else statements are more readable and extensible than switch statements… The case statement is high, adding code will not affect readability if more logical decisions are made later.

Evolution: Encapsulation of state patterns under multiple judgments

In the above state-mode code, the maintainability and readability of the code will also be affected if other state judgments are required for each state.

For multiple state judgment, let’s take an example: 1. Full 10 enjoy full minus activity 1 2. If you are over 20, you can enjoy activity 2 with free shipping and no discount. Over 40 enjoy full minus 4 activities, no free shipping, and 30% off

For some of the above activities, take a look at the status, a total of three states, there are three judgment: full reduction activities, free shipping activities, discounted activities

function getResult(type, money) {
    // Full subtraction activity state control
    let reduceState = {
        state0: function(money) {
            // Full minus activity 1
            return money - 2
        },
        state1: function() {
            // Full minus activity 2
        },
        state2: function() {
            // Full minus activity 3
        },
        state4: function() {
            // Full minus activity 3
        },
        / /... Develop more postage activities
    }

    let expressState = {
        state0: function(money) {
            / / package mail
            return money - 10
        },
        state1: function() {
            / / don't pack mail
        },
        state2: function() {
            // Subtract 2 yuan from postage
        },
        state3: function() {
            // Take 6 yuan off the postage
        },
        / /... Develop more postage activities
    }

    let discountState = {
        state0: function(money) {
            / / 9 discount
            return money * 9 / 10 // js has a problem with decimal calculation
        },
        state1: function() {
            / / 8 discount
        },
        state2: function() {
            / / 7 discount
        },
        / /... Expand more discount activities
    }

    let activityState = {
        state0: function() {
            // The first combination
            let result = reduceState.state0(money) // Full subtraction activity
            return result
        },
        state1: function() {
            // The second combination
            let result = reduceState.state0(money) // Full subtraction activity
            result = expressState.state1(result) // Free shipping
            return result
        },
        state2: function() {
            // The third combination
            let result = reduceState.state0(money) // Full subtraction activity
            result = expressState.state2(result) // Free shipping
            result = discountState.state1(result) // Discounts
            return result
        },
        state3: function() {
            // More activity combinations}}return activityState['state' + type]()
}
getResult(1.100) / / execution
Copy the code

Multiple judgments define multiple statesactivityStaeObject, and if you want to add or modify activities, you only need to maintain themactivityStaeThis one object will do. When a colleague deals with this part of the code, he no longer needs to pay attention to the logic of the activity, just careactivityStaeThe coupling degree between various activities is also reduced. Each type of activity has its own management. Even if one of the activities has changed, only one method needs to be modified, without clarifying the logic of the whole code.

I’ve been improving on the code by refactoring parts of the project if… Else statement, reduces the degree of coupling between businesses, fine granularity of the separation of activities, each activity is not coupled, easy to maintain, code quality and stability can be improved.

The above is pseudo code, some places may report errors, but the general idea and logic should be fairly clear.

Recommend “javascript design Patterns”, read really benefit, some predecessors summed up the code ideas to improve their design ability, code stability, scalability, maintainability are very helpful.