Go语言设计模式之策略模式

我们现在有一个需求，做一个模拟鸭子的游戏。游戏中的鸭子一边游泳一边呱呱叫。
我们来设计一些这个鸭子。

package main

import "fmt"

type Duck interface {
    Quack() // 叫
    Swin() // 游泳
    Display() //外观
}

type MallardDuck struct{}

func (MallardDuck) Quack() {
    fmt.Println("呱呱叫")
}

func (MallardDuck) Swin() {
    fmt.Println("游泳~~~~")
}

func (MallardDuck) Display() {
    fmt.Println("我是绿头鸭")
}

type RedHeadDuck struct{}

func (RedHeadDuck) Quack() {
    fmt.Println("呱呱叫")
}

func (RedHeadDuck) Swin() {
    fmt.Println("游泳~~~~")
}

func (RedHeadDuck) Display() {
    fmt.Println("我是红头鸭")
}

以上是我们最初的代码设计，看起来很OK，设计的也算不错

接下来就是我们非常熟悉的业务迭代了，突然产品经理想着是不是可以给鸭子加上飞行的动作呢？

按照我们的经验加一个飞行的工作能有多难呢？不过是在interface中再加一个动作而已。子类继续实现以下这个接口就好。

type Duck interface {
    Quack() // 叫
    Swin() // 游泳
    Display() //外观
    Fly() //飞行
}
//非常简单有完美的实现了这个功能。简直是轻而易举呢！

如果写过JAVA的伙伴一定会说，JAVA实现起来就很简单，只需要定义一个父类，子类基础其中的函数就可以了（当然Go中也有解决办法，这里就不展开了），Go 还要一一实现接口中的函数。相对麻烦很多。

现实生活是残忍的，需求是千奇百怪的，还记得我们是一个鸭子游戏吗？现在PM有加入了新的鸭子种类，橡皮鸭和木头鸭子。 橡皮鸭不会飞，叫声不是呱呱而是吱吱，木头鸭不会叫也不会飞。这个改怎么办呢？

JAVA中我们可以通过需求来覆盖代码，GO里呢就是每个特别的鸭子都要有自己的实现。（这也是两种语言的不同思路）。刚开始感觉还不错。不停复制代码，修改子类的类型感觉也很爽。

但是现实总是痛苦的吗？现在老板决定每周跟新6只鸭子。意味着我们每周都要写6个新的子类。

一些有想法的伙伴说我们是够可以面向接口编程呢？把代码改成下面的样子。

type Duck interface {
    Swin() // 游泳
    Display() //外观
}

type Fly interface {
    Fly()
}
type Quack interface {
    Quack()
}

type MallardDuck struct{}

func (MallardDuck) Quack() {
    fmt.Println("呱呱叫")
}
func (MallardDuck) Fly() {
    fmt.Println("飞的很慢")
}
func (MallardDuck) Swin() {
    fmt.Println("游泳~~~~")
}

func (MallardDuck) Display() {
    fmt.Println("我是绿头鸭")
}

将Fly和Quack都做成了接口。 我们可以先停下来思考一下，这种拆分，是否能提升我们的开发速度？是否带入了新的问题呢？是否能解决我们项目中隐藏的问题呢？

每次调用鸭子fly或者quack时是不是都需要断言了呢？

可怕的事情继续发生了，PM要将所有飞的很慢的鸭子调整一下速度！！！！
我们项目中用n只鸭子，到底哪个能飞，哪个飞的慢呢！！！！！熬夜看代码吧！！！！一不小还容易改错，我的天，真是人在家中坐，锅从天上来呀！！！！

---

推出第一个设计原则

找出应用中可能需要变化之初，把他们独立出来，不要和那些不需要变化的代码混在一起。

我们知道Duck中Fly和Quack是根据鸭子的变化而改变的。

image.png

第二个设计原则 ：针对接口编程，而不是实现编程

不卖关子了，直接上代码 show me the code

这里fly有一组动作, 用翅膀飞，不能飞、还可以加上有火箭飞等动作

type Fly interface {
    Fly()
}

type NotFly struct{}

func (NotFly) Fly() {
    fmt.Println("我不能飞——")
}

type FlyWithWings struct{}

func (FlyWithWings) Fly() {
    fmt.Println("我用翅膀飞行哦")
}

同样Quack有一组动作, 呱呱叫，不能叫，也可以随便叫

type Quack interface {
    Quack()
}

type NotQuack struct{}

func (NotQuack) Quack() {
    fmt.Println("我不能叫——")
}

type GagaQuack struct{}

func (GagaQuack) Quack() {
    fmt.Println("呱呱叫")
}

Duck也做相应的调整

package main

type Duck interface {
    Swin()                // 游泳
    Display()             //外观
    LetFly()       //飞行动作
    LetQuack() //叫声动作
}
type RedHeadDuck struct {
    f Fly
    q Quack
}

func (RedHeadDuck) Swin() {
    fmt.Println("游泳~~~~")
}

func (RedHeadDuck) Display() {
    fmt.Println("我是红头鸭")
}

func (r RedHeadDuck) LetFly() {
    r.f.Fly()
}

func (r RedHeadDuck) LetQuack() {
    r.q.Quack()
}

继续写代码

func main() {
    duck := RedHeadDuck{
        f: FlyWithWings{},
        q: GagaQuack{},
    }
    duck.LetQuack()
    duck.LetFly()
}

每个鸭子都有一个Fly和Quack，好将飞行和呱呱叫委托给他们处理，当你将两个类结合起来使用，如同上面的Duck一样，这就是组合。这种做法和继续不同的地方在于，鸭子的行为不是继承来的，而是和适合的对象组合来的。
！！！这是一个很重要的技巧！！！

第三个：多用组合，少用继承

总结一下

策略模式--定义算法族，分别封住起来，让他之间可以相互替换，此模式让算法独立于使用算法的客户。