概念介绍：

首先看一下策略模式的一个uml图演示：

其实在我看来策略模式实际上就是针对一个方法中，会根据传进来的策略有不同的业务逻辑，这就导致了如果没有策略模式，那么就会有非常多的if…else，导致代码极差的可读性与线性的高复杂度。

而在策略模式中就会把哪些不同业务给抽离出来封装为一个策略接口，在原本类中将该接口嵌入，因此在调用接口中的那个方法前就需将实现该接口的策略方法传入进去，在调用方法时就仅仅需要去调用策略接口中的方法而不需要再去if else判断是哪一种业务逻辑。

图示举例：

这是普通的设计，在上班的方法中我们就需要写很多的条件判断去看究竟使用何种上班策略

如果使用策略模式则是这样的。

想用哪种策略就只需更换里面的策略接口就可以了

策略模式的优缺点

优点：

策略模式提供了对“开闭原则”的完美支持，用户可以在不修改原有系统的基础上选择算法或行为，也可以灵活地增加新的算法或行为。

使用策略模式可以避免多重条件选择语句。多重条件选择语句不易维护，它把采取哪一种算法或行为的逻辑与算法或行为本身的实现逻辑混合在一起，将它们全部硬编码(Hard Coding)在一个庞大的多重条件选择语句中，比直接继承环境类的办法还要原始和落后。

策略模式提供了一种算法的复用机制。由于将算法单独提取出来封装在策略类中，因此不同的环境类可以方便地复用这些策略类。

缺点：

(1) 客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法。换言之，策略模式只适用于客户端知道所有的算法或行为的情况。

(2) 策略模式将造成系统产生很多具体策略类，任何细小的变化都将导致系统要增加一个新的具体策略类。

但实际上go语言func类型是一等公民，因此我们完全可以使用map[byte]func()去平替那样繁琐的策略模式

如图所示，在go语言中我们在上班方法中直接在map中找到对应上班策略去执行即可~~~

想必这种策略其实大家也一直在使用，却不知道这就是策略模式~