设计模式 策略模式(Strategy Pattern)

设计模式 策略模式(Strategy Pattern)

策略模式（Strategy Pattern）

定义了算法族，分别分装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

例子：
需求：设计一个简答的模拟鸭子应用
游戏中会出现各种鸭子,一边游戏戏水,一遍呱呱叫.

第一种设计
设计鸭子超类Superclass,让各种鸭子继承此超类.

现在需要鸭子会飞,就在超类上增加一个fly方法

这种情况下,出现的问题是,如果出现一个橡皮鸭子,,由于橡皮鸭的叫声与鸭叫不符合,并且橡皮鸭不会飞,需要在子类中覆盖父类quack方法与fly方法,如果在出现一个木头假鸭,那么也需要父类的quack方法和fly方法,通过父类来提供Duck的行为,会出现如下的问题:
1.代码在多个子类中重复;
2.运行时的行为不容易改变;
3.很难知道所有鸭子的全部行为;
4.改变会牵一发动全身,造成其他鸭子不想要的改变.

第二种设计
设计接口:

这种设计的缺点,没出现一种鸭子种类,都要去检查并可能需要覆盖的fly和quack方法.代码的复用性很差.

第三种设计
找出应用中可能需要变化之处,把它们独立出来,不要和那些不需要变化的代码混在一起.
分析得出:Duck类的fly()和quack()会随着鸭子的不同而变化.
为了把这两个行为从Duck类中分开,我们将把它们从Duck类中取出来.

设计原则:针对接口编程,而不是针对实现编程.
利用接口代表每个行为,FlyBehavior与QuackBehavior
鸭子类不实现这两个接口,而用一组其他类专门实现FlyBehavior与QuackBehavior,这种称为”行为”类.
这种设计的好处在于,鸭子的子类在使用接口所表示的行为时,实际的”实现”不会被绑死在鸭子的子类中.
鸭子类不需要知道行为的实现细节,可以在运行时动态改变鸭子的行为.

这种设计模式将鸭子的飞行行为和呱呱叫的动作”委托”(delegate)别人处理,而不是使用定在在Duck类(或子类)内的呱呱叫和飞行方法.

类之间的关系可以是 IS-A(是一个),HAS-A(有一个)或IMPLEMENTS(实现)
HAS-A可能比IS-A更好,
每一个鸭子,都有一个FlyBehavior和QuackBehavior,好将飞行和呱呱叫行为委托给它们处理.
当你将两个类结合起来使用,就是组合(composition),这种做法和”继承”不同的地方在于,鸭子的行为不是继承来的,而是和适当的行为对象”组合”来的.

设计原则:多用组合,少用继承.
使用组合是的系统具有很大的弹性,不仅可以将算法族封装成类,更可以”在运行时动态的改变行为”,只要组合的行为对象符合正确的接口标准.

OO基础：
抽象
封装
多态
继承
OO原则：
封装变化
多用组合，少用继承
针对接口编程，不针对实现编程

设计原则：
1.找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
2.针对接口编程，而不是针对实现编程。
3.多用组合，少用继承。