策略模式在javascript中通过封装可互换的算法来实现行为的动态切换，1. 将算法独立封装为函数或类；2. 创建上下文对象持有并调用当前策略；3. 通过setstrategy等方法在运行时切换策略；4. 使算法变化与客户端解耦，提升扩展性与可维护性，适用于多算法动态切换、避免复杂条件判断、提高测试性等场景，且符合开闭原则，但会增加对象数量，要求客户端了解策略选择，简单场景可能造成过度设计，常用于表单验证、促销计算等业务，与工厂模式（关注对象创建）和模板方法模式（基于继承固定流程骨架）相比，策略模式侧重于算法的灵活替换，通过组合实现运行时动态注入，是一种高内聚低耦合的设计实践。
JS中实现策略模式，本质上就是把一堆可替换的算法封装起来，让它们能在运行时根据需要灵活切换。它把“怎么做”的细节和“谁来做”的逻辑分离开，这样你的代码就不会因为算法变动而跟着大动干戈，这对于构建可维护、可扩展的应用来说，简直是太实用了。
解决方案
策略模式的核心思想是定义一系列算法，将每一个算法封装起来，并使它们可以相互替换。它让算法的变化独立于使用算法的客户端。在JavaScript中，我们通常可以通过函数或者类的形式来定义这些策略。
一个典型的实现会包含：
策略（Strategy）： 定义了一组算法的接口，或者说是一系列函数或类，它们都完成类似但具体实现不同的任务。具体策略（Concrete Strategy）： 实现了策略接口的各个具体算法。上下文（Context）： 持有一个对策略对象的引用，并委托策略对象执行算法。
我们来看一个实际的例子，比如一个订单价格计算器，它可能需要根据不同的促销规则来计算最终价格：
// 1. 定义具体策略：各种价格计算算法const pricingStrategies = { // 无折扣策略 noDiscount: (originalPrice) => { return originalPrice; }, // 百分比折扣策略 percentageDiscount: (originalPrice, discountPercentage) => { if (discountPercentage 100) { console.warn("折扣百分比不合法，将按无折扣处理。"); return originalPrice; } return originalPrice * (1 - discountPercentage / 100); }, // 固定金额减免策略 fixedAmountDiscount: (originalPrice, fixedAmount) => { if (fixedAmount { 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)); // 150let 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如何实现策略模式？策略的应用的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1514625.html
微信扫一扫 
支付宝扫一扫 
