设计模式的策略模式怎样在前端中使用

php中世界最好的语言

发布时间：2018-05-24 09:50:30

1457人浏览过

来源于php中文网

原创

这次给大家带来设计模式的策略模式怎样在前端中使用，设计模式的策略模式在前端中使用注意事项有哪些，下面就是实战案例，一起来看一下。

什么是策略模式？

GoF四兄弟的经典《设计模式》中，对策略模式的定义如下：

定义一系列的算法，把它们一个个封装起来，并且使它们可互相替换。

上边这句话，从字面来看很简单。但是如何在开发过程中去应用，仅凭一个定义依然是一头雾水。以笔者曾经做过的商户进销存系统为例：

某超市准备举行促销活动，市场人员经过调查分析制定了一些促销策略：

购物满100减10
购物满200减30
购物满300减50
。。。

收银软件的界面是这样的（简单示意）：

图片描述

我们应该如何计算实际消费金额？

最初的实现是这样的：

//方便起见，我们把各个促销策略定义为枚举值：0,1,2...
var getActualTotal = function(onSaleType,originTotal){
    if(onSaleType===0){
        return originTotal-Math.floor(originTotal/100)*10
    }
    if(onSaleType===1){
        return originTotal-Math.floor(originTotal/200)*30
    }
    if(onSaleType===0){
        return originTotal-Math.floor(originTotal/300)*50
    }
}
getActualTotal(1,2680); //2208

上面这段代码很简单，而且缺点也很明显。随着我的满减策略逐渐增多，getActualTotal函数会越变越大，而且充满了if判断，稍一疏忽就容易弄错。

OK，有人说我很懒，虽然这样不够优雅但并不影响我的使用，毕竟满减策略再多也多不到哪去。
我只能说，需求永远不是程序员定的。。这时，市场人员说我们新版程序添加了会员功能，我们需要支持以下的促销策略：

会员促销策略：

会员充300返60，且首单打9折
会员充500返100，且首单打8折
会员充1000返300，且首单打7折
...

这个时候，如果你还在原先的getActualTotal函数中继续添加if判断，我想如果你的领导review你这段代码，可能会怀疑自己当初怎么把你招进来。。

OK，我们终于下定决心要重构促销策略的代码，我们可以这么做：

var vipPolicy_0=function(originTotal){
    return originTotal-Math.floor(originTotal/100)*10
}
var vipPolicy_1=function(originTotal){
    return originTotal-Math.floor(originTotal/200)*30
}
...
//会员充1000返300
var vipPolicy_10=function(account,originTotal){
    if(account===0){
        account+=1300;
        return originTotal*0.9
    }else{
        account+=1300;
        return originTotal;
    }
    return originTotal-Math.floor(originTotal/200)*30
}
...
var vipPolicy_n=function(){
    ...
}
var getActualTotal=function(onSaleType,originTotal,account){
    switch(onSaleType){
        case 0:
            return vipPolicy_0(originTotal);
        case 1:
            return vipPolicy_0(originTotal);
        ...
        case n:
            return ...
        default:
            return originTotal;
    }
}

好了，现在我们每种策略都有自己独立的空间了，看起来井井有条。但是还有两个问题没有解决：

随着促销策略的增加，getActualTotal的代码量依然会越来越大
系统缺乏弹性，如果需要增加一种策略，那么除了添加一个策略函数，还需要修改switch...case..语句

让我们再来回顾一下策略模式的定义：

定义一系列的算法，把它们一个个封装起来，并且使它们可互相替换

在我们的例子中，每种促销策略的实现方式是不一样的，但我们最终的目的都是为了求得实际金额。策略模式可以把我们对促销策略的算法一个个封装起来，并且使它们可互相替换而不影响我们对实际金额的求值，这正好是我们所需要的。

下面我们用策略模式来重构上面的代码：

var policies={
    "Type_0":function(originTotal){
        return originTotal-Math.floor(originTotal/100)*10 
    },
    "Type_1":function(originTotal){
        return originTotal-Math.floor(originTotal/200)*30 
    },
    ...
    "Type_n":function(originTotal){
        ... 
    }
}
var getActualTotal=function(onSaleType,originTotal,account){
    return policies["Type_"+onSaleType](originTotal,account)
}
//执行
getActualTotal(0,2680.00);//2208

分析上面的代码我们发现，不管促销策略如何增加，getActualTotal函数完全不需要再变化了。我们要做的，就是增加新策略的函数而已。

通过策略模式的代码，我们消除了让人反胃的大片条件分支语句，getActualTotal本身并没有计算能力，而是将计算全权委托给了策略函数。

由此我们可以总结出策略模式实现的要点：

将变化的算法封装成独立的策略函数，并负责具体的计算
委托函数，该函数接受客户请求，并将请求委托给某一个具体的策略函数

用一张UML图表示如下：
图片描述

怎么样？现在看到上面这张图是不是有了了然于胸的感觉？那就赶紧去试一试策略模式吧！

参考书籍：

《设计模式：可复用面向对象软件的基础》
《大话设计模式》
《Javascript设计模式与开发实践》

做前端开发已经好几年了，对设计模式一直没有深入学习总结过。随着架构相关的工作越来越多，越来越能感觉到设计模式成为了我前进道路上的一个阻碍。所以从今天开始深入学习和总结经典的设计模式以及面向对象的几大原则。

今天第一天，首先来讲策略模式。

什么是策略模式？

GoF四兄弟的经典《设计模式》中，对策略模式的定义如下：

定义一系列的算法，把它们一个个封装起来，并且使它们可互相替换。

上边这句话，从字面来看很简单。但是如何在开发过程中去应用，仅凭一个定义依然是一头雾水。以笔者曾经做过的商户进销存系统为例：

某超市准备举行促销活动，市场人员经过调查分析制定了一些促销策略：

购物满100减10
购物满200减30
购物满300减50
。。。

收银软件的界面是这样的（简单示意）：

图片描述

我们应该如何计算实际消费金额？

最初的实现是这样的：

//方便起见，我们把各个促销策略定义为枚举值：0,1,2...
var getActualTotal = function(onSaleType,originTotal){
    if(onSaleType===0){
        return originTotal-Math.floor(originTotal/100)*10
    }
    if(onSaleType===1){
        return originTotal-Math.floor(originTotal/200)*30
    }
    if(onSaleType===0){
        return originTotal-Math.floor(originTotal/300)*50
    }
}
getActualTotal(1,2680); //2208

上面这段代码很简单，而且缺点也很明显。随着我的满减策略逐渐增多，getActualTotal函数会越变越大，而且充满了if判断，稍一疏忽就容易弄错。

会员促销策略：

会员充300返60，且首单打9折
会员充500返100，且首单打8折
会员充1000返300，且首单打7折
...

这个时候，如果你还在原先的getActualTotal函数中继续添加if判断，我想如果你的领导review你这段代码，可能会怀疑自己当初怎么把你招进来。。

OK，我们终于下定决心要重构促销策略的代码，我们可以这么做：

var vipPolicy_0=function(originTotal){
    return originTotal-Math.floor(originTotal/100)*10
}
var vipPolicy_1=function(originTotal){
    return originTotal-Math.floor(originTotal/200)*30
}
...
//会员充1000返300
var vipPolicy_10=function(account,originTotal){
    if(account===0){
        account+=1300;
        return originTotal*0.9
    }else{
        account+=1300;
        return originTotal;
    }
    return originTotal-Math.floor(originTotal/200)*30
}
...
var vipPolicy_n=function(){
    ...
}
var getActualTotal=function(onSaleType,originTotal,account){
    switch(onSaleType){
        case 0:
            return vipPolicy_0(originTotal);
        case 1:
            return vipPolicy_0(originTotal);
        ...
        case n:
            return ...
        default:
            return originTotal;
    }
}

好了，现在我们每种策略都有自己独立的空间了，看起来井井有条。但是还有两个问题没有解决：

随着促销策略的增加，getActualTotal的代码量依然会越来越大
系统缺乏弹性，如果需要增加一种策略，那么除了添加一个策略函数，还需要修改switch...case..语句

让我们再来回顾一下策略模式的定义：

定义一系列的算法，把它们一个个封装起来，并且使它们可互相替换

下面我们用策略模式来重构上面的代码：

var policies={
    "Type_0":function(originTotal){
        return originTotal-Math.floor(originTotal/100)*10 
    },
    "Type_1":function(originTotal){
        return originTotal-Math.floor(originTotal/200)*30 
    },
    ...
    "Type_n":function(originTotal){
        ... 
    }
}
var getActualTotal=function(onSaleType,originTotal,account){
    return policies["Type_"+onSaleType](originTotal,account)
}
//执行
getActualTotal(0,2680.00);//2208

分析上面的代码我们发现，不管促销策略如何增加，getActualTotal函数完全不需要再变化了。我们要做的，就是增加新策略的函数而已。

通过策略模式的代码，我们消除了让人反胃的大片条件分支语句，getActualTotal本身并没有计算能力，而是将计算全权委托给了策略函数。

由此我们可以总结出策略模式实现的要点：

将变化的算法封装成独立的策略函数，并负责具体的计算
委托函数，该函数接受客户请求，并将请求委托给某一个具体的策略函数

用一张UML图表示如下：
图片描述

怎么样？现在看到上面这张图是不是有了了然于胸的感觉？那就赶紧去试一试策略模式吧！

相信看了本文案例你已经掌握了方法，更多精彩请关注php中文网其它相关文章！

相关专题

TypeScript类型系统进阶与大型前端项目实践

本专题围绕 TypeScript 在大型前端项目中的应用展开，深入讲解类型系统设计与工程化开发方法。内容包括泛型与高级类型、类型推断机制、声明文件编写、模块化结构设计以及代码规范管理。通过真实项目案例分析，帮助开发者构建类型安全、结构清晰、易维护的前端工程体系，提高团队协作效率与代码质量。

2026.03.13

Python异步编程与Asyncio高并发应用实践

本专题围绕 Python 异步编程模型展开，深入讲解 Asyncio 框架的核心原理与应用实践。内容包括事件循环机制、协程任务调度、异步 IO 处理以及并发任务管理策略。通过构建高并发网络请求与异步数据处理案例，帮助开发者掌握 Python 在高并发场景中的高效开发方法，并提升系统资源利用率与整体运行性能。

2026.03.12

C# ASP.NET Core微服务架构与API网关实践

本专题围绕 C# 在现代后端架构中的微服务实践展开，系统讲解基于 ASP.NET Core 构建可扩展服务体系的核心方法。内容涵盖服务拆分策略、RESTful API 设计、服务间通信、API 网关统一入口管理以及服务治理机制。通过真实项目案例，帮助开发者掌握构建高可用微服务系统的关键技术，提高系统的可扩展性与维护效率。

276

2026.03.11

Go高并发任务调度与Goroutine池化实践

本专题围绕 Go 语言在高并发任务处理场景中的实践展开，系统讲解 Goroutine 调度模型、Channel 通信机制以及并发控制策略。内容包括任务队列设计、Goroutine 池化管理、资源限制控制以及并发任务的性能优化方法。通过实际案例演示，帮助开发者构建稳定高效的 Go 并发任务处理系统，提高系统在高负载环境下的处理能力与稳定性。

2026.03.10

Kotlin Android模块化架构与组件化开发实践

本专题围绕 Kotlin 在 Android 应用开发中的架构实践展开，重点讲解模块化设计与组件化开发的实现思路。内容包括项目模块拆分策略、公共组件封装、依赖管理优化、路由通信机制以及大型项目的工程化管理方法。通过真实项目案例分析，帮助开发者构建结构清晰、易扩展且维护成本低的 Android 应用架构体系，提升团队协作效率与项目迭代速度。

2026.03.09

JavaScript浏览器渲染机制与前端性能优化实践

本专题围绕 JavaScript 在浏览器中的执行与渲染机制展开，系统讲解 DOM 构建、CSSOM 解析、重排与重绘原理，以及关键渲染路径优化方法。内容涵盖事件循环机制、异步任务调度、资源加载优化、代码拆分与懒加载等性能优化策略。通过真实前端项目案例，帮助开发者理解浏览器底层工作原理，并掌握提升网页加载速度与交互体验的实用技巧。

105

2026.03.06

Rust内存安全机制与所有权模型深度实践

本专题围绕 Rust 语言核心特性展开，深入讲解所有权机制、借用规则、生命周期管理以及智能指针等关键概念。通过系统级开发案例，分析内存安全保障原理与零成本抽象优势，并结合并发场景讲解 Send 与 Sync 特性实现机制。帮助开发者真正理解 Rust 的设计哲学，掌握在高性能与安全性并重场景中的工程实践能力。

230

2026.03.05

PHP高性能API设计与Laravel服务架构实践

本专题围绕 PHP 在现代 Web 后端开发中的高性能实践展开，重点讲解基于 Laravel 框架构建可扩展 API 服务的核心方法。内容涵盖路由与中间件机制、服务容器与依赖注入、接口版本管理、缓存策略设计以及队列异步处理方案。同时结合高并发场景，深入分析性能瓶颈定位与优化思路，帮助开发者构建稳定、高效、易维护的 PHP 后端服务体系。

619

2026.03.04