JS策略模式详解与实战应用

golang学习网今天将给大家带来《JS策略模式实现与应用详解》，感兴趣的朋友请继续看下去吧！以下内容将会涉及到等等知识点，如果你是正在学习文章或者已经是大佬级别了，都非常欢迎也希望大家都能给我建议评论哈~希望能帮助到大家！

策略模式在JavaScript中通过封装可互换的算法来实现行为的动态切换，1. 将算法独立封装为函数或类；2. 创建上下文对象持有并调用当前策略；3. 通过setStrategy等方法在运行时切换策略；4. 使算法变化与客户端解耦，提升扩展性与可维护性，适用于多算法动态切换、避免复杂条件判断、提高测试性等场景，且符合开闭原则，但会增加对象数量，要求客户端了解策略选择，简单场景可能造成过度设计，常用于表单验证、促销计算等业务，与工厂模式（关注对象创建）和模板方法模式（基于继承固定流程骨架）相比，策略模式侧重于算法的灵活替换，通过组合实现运行时动态注入，是一种高内聚低耦合的设计实践。

JS中实现策略模式，本质上就是把一堆可替换的算法封装起来，让它们能在运行时根据需要灵活切换。它把“怎么做”的细节和“谁来做”的逻辑分离开，这样你的代码就不会因为算法变动而跟着大动干戈，这对于构建可维护、可扩展的应用来说，简直是太实用了。

解决方案

策略模式的核心思想是定义一系列算法，将每一个算法封装起来，并使它们可以相互替换。它让算法的变化独立于使用算法的客户端。在JavaScript中，我们通常可以通过函数或者类的形式来定义这些策略。

一个典型的实现会包含：

1. 策略（Strategy）： 定义了一组算法的接口，或者说是一系列函数或类，它们都完成类似但具体实现不同的任务。
2. 具体策略（Concrete Strategy）： 实现了策略接口的各个具体算法。
3. 上下文（Context）： 持有一个对策略对象的引用，并委托策略对象执行算法。

我们来看一个实际的例子，比如一个订单价格计算器，它可能需要根据不同的促销规则来计算最终价格：

// 1. 定义具体策略：各种价格计算算法
const pricingStrategies = {
    // 无折扣策略
    noDiscount: (originalPrice) => {
        return originalPrice;
    },
    // 百分比折扣策略
    percentageDiscount: (originalPrice, discountPercentage) => {
        if (discountPercentage < 0 || discountPercentage > 100) {
            console.warn("折扣百分比不合法，将按无折扣处理。");
            return originalPrice;
        }
        return originalPrice * (1 - discountPercentage / 100);
    },
    // 固定金额减免策略
    fixedAmountDiscount: (originalPrice, fixedAmount) => {
        if (fixedAmount < 0) {
            console.warn("减免金额不能为负，将按无折扣处理。");
            return originalPrice;
        }
        return Math.max(0, originalPrice - fixedAmount); // 确保价格不为负
    },
    // 满减策略 (例如：满200减50)
    thresholdDiscount: (originalPrice, threshold, deduction) => {
        if (originalPrice >= threshold) {
            return Math.max(0, originalPrice - deduction);
        }
        return originalPrice;
    }
};

// 2. 定义上下文：价格计算器，它会使用具体的策略
class PriceCalculator {
    constructor(strategy) {
        // 构造时可以传入一个默认策略
        this.currentStrategy = strategy || pricingStrategies.noDiscount;
    }

    // 动态设置策略的方法
    setStrategy(newStrategy) {
        if (typeof newStrategy !== 'function') {
            throw new Error("传入的策略必须是一个函数。");
        }
        this.currentStrategy = newStrategy;
    }

    // 执行计算
    calculatePrice(originalPrice, ...args) {
        return this.currentStrategy(originalPrice, ...args);
    }
}

// 实际应用
const calculator = new PriceCalculator();

let itemPrice = 200;

// 使用无折扣策略
console.log(`原价 ${itemPrice}，无折扣后：`, calculator.calculatePrice(itemPrice)); // 200

// 切换到百分比折扣策略 (打八折)
calculator.setStrategy(pricingStrategies.percentageDiscount);
console.log(`原价 ${itemPrice}，八折后：`, calculator.calculatePrice(itemPrice, 20)); // 160

// 切换到固定金额减免策略 (减30元)
calculator.setStrategy(pricingStrategies.fixedAmountDiscount);
console.log(`原价 ${itemPrice}，减30元后：`, calculator.calculatePrice(itemPrice, 30)); // 170

// 切换到满减策略 (满200减50)
calculator.setStrategy(pricingStrategies.thresholdDiscount);
console.log(`原价 ${itemPrice}，满200减50后：`, calculator.calculatePrice(itemPrice, 200, 50)); // 150

let lowPriceItem = 50;
console.log(`原价 ${lowPriceItem}，满200减50后：`, calculator.calculatePrice(lowPriceItem, 200, 50)); // 50 (未达到满减条件)

在这个例子中，pricingStrategies 对象就是我们定义的“策略族”，每个属性都是一个具体的策略函数。PriceCalculator 则是上下文，它通过 setStrategy 方法动态地切换不同的价格计算逻辑。这种方式让添加新的促销规则变得异常简单，只需要添加一个新的函数到 pricingStrategies 对象，而无需修改 PriceCalculator 的内部代码。

JavaScript中何时考虑使用策略模式？

我个人觉得，当你发现代码里开始出现那种“如果这样就这么干，如果那样就那么干”的巨型判断块时，策略模式就像个救星。它能帮你把这些复杂的条件逻辑拆解成一个个独立的、可插拔的单元。具体来说，以下几种情况，我觉得策略模式特别适用：

• 存在多种算法，需要运行时动态切换： 比如电商网站的促销活动，可能今天用满减，明天用打折，后天又变成买赠。每种促销都是一种算法，策略模式能让你轻松切换。
• 避免庞大的条件语句： 如果你发现一个函数或方法内部，充斥着大量的 if-else if 或者 switch 语句来根据不同条件执行不同行为，这通常是策略模式的信号。它能把这些分支逻辑外部化。
• 需要隐藏算法的复杂性： 某些算法可能非常复杂，你希望客户端代码只知道如何使用它，而不必关心其内部实现细节。策略模式通过封装实现了这一点。
• 提高代码的可扩展性和可维护性： 当你需要增加新的算法时，只需要添加一个新的具体策略，而不需要修改现有的上下文或其他策略，这符合“开闭原则”（对扩展开放，对修改关闭）。

举个例子，前端表单验证就是策略模式的经典应用场景。一个输入框可能需要验证是否为空、是否是邮箱格式、是否是手机号、是否在某个长度范围内等等。每种验证规则都可以是一个策略，然后根据需要组合或切换这些策略。这比写一大堆嵌套的 if 语句要优雅得多。

JavaScript策略模式的优缺点分析

当然，这也不是万金油，任何设计模式都有其适用场景和权衡。理解它的优缺点，才能更好地决定是否采用。

优点：

• 增强灵活性与扩展性： 这是最显著的优势。你可以轻松地添加、删除或修改策略，而不会影响到使用这些策略的上下文代码。对于不断变化的业务需求，这简直是福音。
• 消除冗余的条件逻辑： 它将算法的实现从使用算法的客户端中分离出来，从而消除了客户端代码中大量的条件判断语句，使代码更加清晰、易读。
• 提高可测试性： 每个策略都是独立的单元，可以单独进行单元测试，这大大简化了测试过程。
• 更好的代码组织： 相关的算法被组织在一起，使得代码结构更清晰，职责分离更明确。

缺点：

• 增加了对象数量： 策略模式会为每一种算法都创建一个独立的策略对象（或函数），这在算法数量非常多的时候，可能会导致系统中对象的数量增加，从而增加一些管理上的复杂性。
• 客户端需要了解所有策略： 客户端在选择使用哪种策略时，通常需要知道所有可用的策略及其用途。这不像工厂模式那样，客户端可能完全不知道具体产品的类型。
• 可能引入不必要的复杂性： 对于只有一两种算法，且未来变化可能性不大的简单场景，引入策略模式可能会显得过度设计，反而增加了代码的复杂性。有时候，一个简单的 if/else 或者 switch 语句可能更直接、更易懂。

我个人在项目中就遇到过，为了一个可能只有两种状态的逻辑，硬生生拆出了两个策略类，结果维护起来感觉比直接判断还麻烦。所以，用不用，什么时候用，还得看具体业务的复杂度和未来的扩展预期。

策略模式与工厂模式、模板方法模式有何不同？

我经常看到有人把策略模式和工厂模式搞混，其实它们解决的问题不太一样，虽然在某些场景下可能会一起出现。理解这些模式之间的区别，能帮助我们更精准地选择和应用。

• 策略模式（Strategy Pattern） vs. 工厂模式（Factory Pattern）：

  • 关注点不同： 策略模式关注的是“行为”或“算法”的切换，它让客户端在运行时选择不同的算法来完成一个任务。工厂模式关注的则是“对象”的创建，它提供一个接口来创建一系列相关或依赖的对象，而无需指定它们具体的类。
  • 解决的问题： 策略模式解决的是“怎么做”的问题（How to do it），即算法的动态选择和替换。工厂模式解决的是“创建什么”的问题（What to create），即对象的实例化。
  • 组合方式： 策略模式通常通过“组合”来实现（Context持有Strategy对象）。工厂模式则通过“继承”或“组合”来隐藏对象的创建细节。
  • 例子：
    • 策略： 你有一个订单处理器，它根据不同的促销规则（策略）计算价格。
    • 工厂： 你有一个图形编辑器，它通过一个工厂方法来创建不同类型的图形对象（圆形、矩形、三角形）。

• 策略模式（Strategy Pattern） vs. 模板方法模式（Template Method Pattern）：

  • 实现机制： 策略模式是基于“对象组合”的，它通过将不同的算法封装在独立的策略对象中，然后由上下文对象引用并调用这些策略。模板方法模式则是基于“继承”的，它在一个抽象基类中定义了一个算法的骨架（模板方法），并将某些步骤延迟到子类中去实现。
  • 灵活性： 策略模式在运行时可以动态地切换整个算法。模板方法模式允许子类重写算法的特定步骤，但算法的整体结构是固定的。
  • 改变的粒度： 策略模式改变的是“整个算法”。模板方法模式改变的是算法的“部分步骤”。
  • 例子：
    • 策略： 你有一个数据导出工具，可以根据用户选择的格式（CSV、JSON、XML）来导出数据，每种格式是一种策略。
    • 模板方法： 你有一个数据处理流程，包括“加载数据”、“转换数据”、“保存数据”三个步骤。其中“转换数据”的具体实现可以在不同的子类中定义，但加载和保存的流程是固定的。

总的来说，策略模式更像是一种“即插即用”的模块化思想，把不同的“做法”打包好，随时可以替换。而工厂模式是关于“造东西”的，模板方法则是关于“流程骨架”的。它们各有侧重，但都能帮助我们构建更健壮、更灵活的软件系统。

今天关于《JS策略模式详解与实战应用》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！