策略模式可能是很多同学学习到的第一种模式。这个模式确实适合作为开篇模式来讲,主要原因在于该模式简单、纯粹、没有太多技巧,但是很好的表达出了设计模式的理念,让读者能够直观的感受到设计模式带来的好处。
策略模式核心在于利用多态性,这是目前主流的面向对象语言都支持的功能。
UML类图位置:https://www.processon.com/view/link/60d29bf3e401fd49502afd25
本文代码链接为:https://github.com/shidawuhen/asap/blob/master/controller/design/20strategy.go
策略模式:它定义了算法家族,分别封装起来,让它们之间可以互相替换,此模式让算法的变化,不会影响到使用算法的客户。
UML:
单看策略模式,主要利用多态性。但策略模式往往不单独使用,它会和Go设计模式(7)-工厂模式配合使用。此时策略模式便可解耦策略的定义、创建、使用。
策略模式加工厂模式,能够达到去除if-else和switch的效果,主要靠工厂模式加持,借助于“查表法”找到指定策略进行使用。
策略模式的应用场景还是蛮广泛的,处理同一类问题如果有多种算法,就可以使用策略模式。如根据不同活动计算优惠价格、根据商品不同类型计算税率等。
最近有一个实际业务场景可以使用策略模式,计算跨境商品税费。
跨境商品的税费和两方面有关,一是商品是否含税,二是商品类型,不同类型对应税率不一样,如常规商品和酒类商品税率不一样、税的计算方式也不一样。
所以只要知道商品是否含税、商品类型就能找到对应的计算方案。如果我们使用if-else来写,会不优雅,因为商品类型比较多,而且计算逻辑也相对复杂,所以我们可以利用查表法进行优化。
税费计算接口被交易侧调用,交易调用的时候会传商品是否含税,商品类型由项目组自行维护。那我们来看一下具体实现。
package main
import "fmt"
const (
Common = "COMMON"
Win = "WIN"
)
/**
* @Author: Jason Pang
* @Description: 根据hscode获取商品类型
* @param hscode
* @return string
*/
func getProductType(hscode string) string {
if hscode == "11" {
return Common
} else {
return Win
}
}
/**
* @Author: Jason Pang
* @Description: 税费计算函数,金额都为分
* @param price
* @param qty
* @return taxPrice
*/
type TaxComputeFunc func(price int64, qty int64) (taxPrice int64)
/**
* @Author: Jason Pang
* @Description: 税费计算策略存储处
0为不含税 1为含税
*/
var TaxComputeFuncMap = map[int]map[string]TaxComputeFunc{
0: map[string]TaxComputeFunc{
Common: common,
Win: win,
},
1: map[string]TaxComputeFunc{
Common: common,
Win: win,
},
}
/**
* @Author: Jason Pang
* @Description: 计算普通商品税费
* @param price
* @param qty
* @return taxPrice
*/
func common(price int64, qty int64) (taxPrice int64) {
radio := 0.1
fmt.Println("计算普通商品税费")
return int64(float64(price*qty) * radio)
}
/**
* @Author: Jason Pang
* @Description: 计算酒类税费
* @param price
* @param qty
* @return taxPrice
*/
func win(price int64, qty int64) (taxPrice int64) {
radio := 0.2
fmt.Println("计算普酒类税费")
return int64(float64(price*qty) * radio)
}
/**
* @Author: Jason Pang
* @Description: 计算税费
* @param withTax
* @param productType
* @param price
* @param qty
*/
func ComputeTaxPrice(withTax int, productType string, price int64, qty int64) {
if taxFunc, ok := TaxComputeFuncMap[withTax][productType]; ok {
taxPrice := taxFunc(price, qty)
fmt.Println("税费为", taxPrice)
} else {
fmt.Println("输入有误,无法计算")
}
}
func main() {
//获取商品是否含税、商品价格、商品数量、商品类型
withTax := 0
var price, qty int64 = 10000, 3
productType := getProductType("11")
//计算税费
ComputeTaxPrice(withTax, productType, price, qty)
}
输出:
➜ myproject go run main.go
计算普通商品税费
税费为 3000
这么写有哪些好处呢?首先代码很精简,没有一堆判断;其次无论是增加策略还是修改策略,都不会影响主框架,即main\ComputeTaxPrice,只需在TaxComputeFuncMap添加新的策略即可,很好的做到了对扩展开放,虽然对TaxComputeFuncMap有一定更改,但变动不大,能够接受。
如果大家看过我以前写的Go设计模式(18)-观察者模式,会感觉两个实现比较像。两者确实比较像,但是有一个核心地方不同,观察者模式是调用所有策略,策略模式准确找到合适的策略进行调用。
策略模式很好的体现了开闭原则,也说明即使是很小的优化设计,也能给项目开发带来巨大的便利。当然,这种便利会在维护的时候得到充分体现,毕竟谁维护谁知道。
大家如果喜欢我的文章,可以关注我的公众号(程序员麻辣烫)
我的个人博客为:https://shidawuhen.github.io/
往期文章回顾:
设计模式
招聘
思考
存储
算法系列
读书笔记
小工具
架构
网络
Go语言