JavaScript中的设计模式-策略模式

前言

设计模式在我们编程中是十分重要的！

设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

最近在学习设计模式，铁铁们一起来卷嘛？

什么是设计模式？

在软件设计过程中，针对特定问题的简洁而优雅的解决方案。

把之前的经验总结并且合理运用到某处场景上，能够解决实际的问题。

设计模式五大设计原则（SOLID）

• S-单一职责原则

  即一个程序只做好一件事

• O-开放封闭原则

  可扩展开放，对修改封闭

• L-里氏置换原则

  子类能覆盖父类，并能出现在父类出现的地方

• I-接口独立原则

  保持接口的单一独立

• D-依赖导致原则

  使用方法只关注接口而不关注具体类的实现

为什么需要设计模式？

• 易读性

  使用设计模式能够提升我们的代码可读性，提升后续开发效率

• 可拓展性

  使用设计模式对代码解耦，能很好的增强代码的yi修改性和拓展性

• 复用性

  使用设计模式可以复用已有的解决方案，无需重复相同工作

• 可靠性

  使用设计模式能够增加系统的健壮性，使代码编写真正工程化

策略模式

定义：定义一系列的算法，把它们一个个的封装起来，并且使它们可以相互转换。把看似毫无联系的代码提取封装、复用，使之更容易被理解和拓展

它就像我们解决问题的思路，有很多种，那我们就应该选择最适合解决当前业务的那一种。

应用场景：要完成一件事情，有不同的策略。例如绩效计算、表单验证规则。

来看这段代码：

const calculateBonus = (level, salary) => {
    switch (level) {
        case 's': {
            return salary * 4;
        }
        case 'a': {
            return salary * 3;
        }
        case 'b': {
            return salary * 2;
        }
        default: {
            return 0
        }
    }
    return strategies[level][salary];
};
calculateBonus['s',20000];

函数calculateBonus接收level跟salary两个参数，运用switch case来计算绩效。但是在以后我们又要增加新绩效的时候，例如我们想加一个p绩效，我们要深入到代码中，去在switch case中去增加一个 case p的逻辑，这样子我们相当于每次业务变更都要去改造这个函数，就是不太好的情况。

使用switch还好，代码看起来很清晰，如果是if else呢 不敢想象了~

再看策略模式：

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

const caculateBonus = (level, salary) => {
    return strategies[level][salary];
};
caculateBonus('s',20000)

也是有着一个caculateBonus函数，接收level跟salary两个参数，但是我们构建了一个策略表，在策略表中维护这个计算规则。这时候如果要加入一个新绩效等级，就去表中加入一个新等级，再加入它的计算规则即可，并且可以将表提取出来放到另一个文件中，甚至是放到公网上下发，因为这个表是可以不用程序员们来维护的，可以做成页面交给公司其他人员去维护，就有了前面说的那个下发的功能，可以去给别人展示。计算绩效的时候去读取策略表，完后根据表中规则来进行计算就行。