我们现在有一个需求，做一个模拟鸭子的游戏。游戏中的鸭子一边游泳一边呱呱叫。
我们来设计一些这个鸭子。
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是根据鸭子的变化而改变的。
第二个设计原则 ：针对接口编程，而不是实现编程
不卖关子了，直接上代码 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一样，这就是组合。这种做法和继续不同的地方在于，鸭子的行为不是继承来的，而是和适合的对象组合来的。
！！！这是一个很重要的技巧！！！
第三个：多用组合，少用继承
总结一下
策略模式--定义算法族，分别封住起来，让他之间可以相互替换，此模式让算法独立于使用算法的客户。
