本文深入探讨了策略模式的设计理念，通过鸭子游戏案例详细解析了策略模式的应用，包括算法族的封装、行为的动态替换及模式的优缺点。文章强调了封装变化、针对接口编程和多用组合，少用继承的原则。
记录《Head First 设计模式》
参考 Graphic Design Patterns网站 与 深入设计模式
目的是检查学习情况，同时方便以后复习。
文章目录
一、简述
1-1 意图
策略模式 Strategy Pattern：
Define a family of algorithms,encapsulate each one ,and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
定义算法族（定义一系列的算法），分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用的客户。也称为政策模式(Policy)。
该模式是一种行为模式。
1-2 动机
- 完成一项任务，往往可以有多种不同的方式，每个方式多称为一个策略。我们可以根据环境或条件的不同选择不同的策略。
1-3 结构
策略模式包含以下角色：
- Context:环境类
- Strategy:策略接口
- ConcreteStrategy:具体策略类
1-4 时序
二、举例：
1-1 简单应用
Joe上班的公司做了一个模拟鸭子的游戏：游戏中出现各种鸭子，一边游泳戏水，一边呱呱叫。此系统的内部设计使用了标准的OO技术(OO:面向对象)，设计了一个超类(SuperClass)，并让各种鸭子继承此超类。
UML图：还有各种鸭子，此处画图省略。
1-2 增加需求
由于竞争者蜂拥而至，Joe的主管们增加需求，使用会飞的鸭子领先于其他竞争者。Joe想“只需要在Duck类上增加一个Fly()方法即可，然后所有的鸭子继承Fly()。这是我展示OO才华的时候了”。
你也是认为是这样添加的吗？刚开始我也是以为这样添加
1-3 继承
但是，可怕的问题出现了~ “我在展示中看见 ‘橡皮鸭子’在屏幕上飞来飞去”Joe的经理愤怒的吵着Joe。Joe体会到了一件事：当设计"维护"时，为了"复用(rause)"目的而使用继承，结局并不完美。
Joe想到了继承：可以将橡皮鸭中的Fly()方法覆盖掉，就好像覆盖Quack()一样。
但是利用继承提供Duck的行为，这会导致以下缺点：
- 代码在多个子类中重复
- 运行时的行为不容易改变
- 很难知道所有鸭子的全部行为
- 改变会牵一发动全身，造成其他鸭子不想要的改变
1-4 接口
Joe认识到继承可能不是答案，因为他刚刚拿到主管的备忘录，希望以后六个月更新产品。Joe就想到利用接口。将Fly和Quack方法单独提出来作为接口。
但Joe的主管很快发现这是一个超笨的主意，这样设计重复的代码就会变多。如果Duck的行为进行修改，那么Duck的子类必须进行修改。
2-5 让我们重新整理问题
我们知道继承并不能很好的解决问题，因为鸭子的行为在子类里不断的改变，并且让所有子类都有这样的行为是不恰当的。Flyable与Quackable接口似乎还不错，但仍存在一些问题:接口不具有实现代码，所有继承接口无法达到代码的复用。这就意味着：无论何时需要修改一个行为，你必须得往下追踪并在每一个定义此行为的类中修改它，一不小心，可能会造成新的错误！
幸运的是，有一个设计原则，恰好适用此状况：找到应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。换句话说，如果每次新需求一来，都会使这部分代码发生改变，那么你就可以确认，将这部分代码抽取出来和别的代码区分。
原则的另一种思考方式：把会变化的部分取出来并封装起来，以便以后可以轻易的改变或扩充此部分，而不影响不需要变化的部分。
下面的图：分开变化和不会变化的部分
2-6 设计鸭子的行为
那么我们如何设计那组实现飞行和呱呱叫的类呢？我们应该在鸭子类中包含设定行为的方法，这样就可以在"运行时"动态地"改变"绿头鸭的飞行行为。
有了目标，我们看一下第二个设计原则：针对接口编程，而不是针对实现编程
我们定义两个接口：IFlyBehavior 和 IQuackBehavior。下面是实现具体的行为：
2-7 整合UML与代码
整合UML： 可以根据UML图自己先写出代码。
代码实现：
鸭子基类：
/// <summary>
/// 鸭子父类
/// </summary>
public abstract class Duck
{
#region 子类实现不一样：提取改变动作为接口
/// <summary>
/// 叫声
/// </summary>
public IQuackBehavior quackBehavior;
/// <summary>
/// 飞
/// </summary>
public IFlyBehavior flyBehavior;
/// <summary>
/// 实现叫
/// </summary>
/// <param name="quack"></param>
public void PerFromQuack()
{
quackBehavior.QuackAction();
}
/// <summary>
/// 实现飞
/// </summary>
/// <param name="quack"></param>
public void PerFromFly()
{
flyBehavior.Fly();
}
#endregion
/// <summary>
/// 行为：游泳戏水
/// </summary>
public void Swim()
{
Console.WriteLine("游泳戏水");
}
/// <summary>
/// 外观
/// </summary>
public abstract void Display();
}
鸭子子类：
/// <summary>
/// 绿头鸭
/// </summary>
public class MallardDuck : Duck
{
/// <summary>
/// 构造函数：定义飞动作与叫动作
/// </summary>
public MallardDuck()
{
quackBehavior = new Quack();
flyBehavior = new FlyWithWings();
}
/// <summary>
/// 外观
/// </summary>
public override void Display()
{
Console.WriteLine("外观是绿头");
}
}
/// <summary>
/// 红头鸭
/// </summary>
public class RedheadDuck : Duck
{
public RedheadDuck()
{
quackBehavior = new Quack();
flyBehavior = new FlyWithWings();
}
/// <summary>
/// 外观
/// </summary>
public override void Display()
{
Console.WriteLine("外观是红头");
}
}
/// <summary>
/// 橡皮鸭子
/// </summary>
public class RubberDuck : Duck
{
public RubberDuck()
{
quackBehavior = new Squeak();
flyBehavior = new FlyNoWay();
}
/// <summary>
/// 外观
/// </summary>
public override void Display()
{
Console.WriteLine("黄色");
}
}
定义一系列算法：飞动作：
/// <summary>
/// 动作飞 接口
/// </summary>
public interface IFlyBehavior
{
void Fly();
}
/// <summary>
/// 不会飞
/// </summary>
public class FlyNoWay : IFlyBehavior
{
public void Fly()
{
Console.WriteLine("不会飞行");
}
}
/// <summary>
/// 动作飞
/// </summary>
public class FlyWithWings : IFlyBehavior
{
public void Fly()
{
Console.WriteLine("动作飞行");
}
}
定义一系列算法：叫声：
/// <summary>
/// 叫声接口
/// </summary>
public interface IQuackBehavior
{
void QuackAction();
}
/// <summary>
/// 实现呱呱叫类
/// </summary>
public class Quack : IQuackBehavior
{
public void QuackAction()
{
Console.WriteLine("呱呱叫");
}
}
/// <summary>
/// 实现吱吱叫类
/// </summary>
public class Squeak : IQuackBehavior
{
public void QuackAction()
{
Console.WriteLine("吱吱叫");
}
}
/// <summary>
/// 实现不会叫类
/// </summary>
public class MuteQuack : IQuackBehavior
{
public void QuackAction()
{
Console.WriteLine("不会叫");
}
}
测试程序：
class Program
{
static void Main(string[] args)
{
//绿头鸭
Duck mallardDuck = new MallardDuck();
Console.WriteLine("绿头鸭");
mallardDuck.Display();
mallardDuck.Swim();
mallardDuck.PerFromQuack();
mallardDuck.PerFromFly();
Console.WriteLine();
//红头鸭子
Duck redheadDuck = new RedheadDuck();
Console.WriteLine("红头鸭子");
redheadDuck.Display();
redheadDuck.Swim();
redheadDuck.PerFromQuack();
redheadDuck.PerFromFly();
Console.WriteLine();
//橡皮鸭子
Duck rubberDuck = new RubberDuck();
Console.WriteLine("橡皮鸭子");
rubberDuck.Display();
rubberDuck.Swim();
rubberDuck.PerFromQuack();
rubberDuck.PerFromFly();
Console.WriteLine();
Console.ReadKey();
}
}
执行结果：
添加动态功能：
在鸭子里建立一堆动态的功能没有用到就太可惜了！假设我们想在鸭子子类中通过"设定方法(setter method)"来设定鸭子的行为，而不是在鸭子的构造器内实例化。
我们需要在Duck类中，加入两个新方法
在鸭子基类中添加两个方法：实现动态功能
public void setQuackBehavior(IQuackBehavior quack)
{
this.quackBehavior = quack;
}
public void setFlyBehavior(IFlyBehavior fly)
{
this.flyBehavior = fly;
}
添加模型鸭继承Duck：不会叫也不会飞。
/// <summary>
/// 模型鸭
/// </summary>
public class ModelDuck : Duck
{
public ModelDuck()
{
quackBehavior = new MuteQuack();
flyBehavior = new FlyNoWay();
}
public override void Display()
{
Console.WriteLine("模型鸭");
}
}
测试项目
//模型鸭：开始不会飞不会叫
Duck modelDuck = new ModelDuck();
modelDuck.PerFromQuack();
modelDuck.PerFromFly();
modelDuck.setFlyBehavior(new FlyWithWings());
modelDuck.setQuackBehavior(new Quack());
modelDuck.PerFromQuack();
modelDuck.PerFromFly();
modelDuck.Display();
modelDuck.Swim();
以上就是“我们使用策略模式实现鸭子的各种行为”。
“有一个”
“有一个”关系比较有趣：每个鸭子都有一个IFlyBehavior 和 IQuackBehavior。好将飞行和呱呱叫委托给他们作为代理。
当你将两个类结合起来使用，如本文例子，这就是组合(composition)。这种做法与“继承”的不同之处是鸭子的行为不是继承来的，而是适当的行为为对象“组合”来的。
这是一个很重要的技巧，这是第三个设计原则:多用组合，少用继承
三、总结
1-1 模式优缺点
优点：
- 策略模式完美提供对了“开-闭原则”的支持。用户可以在不修改原有系统的基础上选择算法或行为，也可以灵活地增加新的算法或行为。
- 提供了管理相关算法族的办法
- 提供了可以替换继承关系的办法。
- 避免了使用多重条件转移语句。
- 提供了一种算法的复用机制，不同的环境类可以方便地使用策略类。
缺点：
- 用户必须知道所有策略类，并自行决定使用哪个策略类
- 策略模式造成很多的具体策略类，可以通过亨元模式在一定程度多行减少对象的数量。
无法同时在客户端使用多个策略类。
1-2 使用场景
使用场景：
-
如果一个系统中有许多类，他们之间的区别在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。
-
如果一个对象有很多的行为，如果这些行为不用适当的模式，这些行为会用 if…else 多重的条件选择语句来实现。
-
不希望客户端知道复杂的、与算法相关的数据结构，在具体策略类中封装算法和相关的数据接口，提高算法的保密性与安全性
1-3 总结
恭喜你，看到这里你应该学会策略模式了吧！！！
你还记的本文都学到了什么吗？让我们总结一下吧！
OO基础：抽象、封装、继承、多态
OO原则：
- “封装变化”—？、
- “针对接口编程，不针对实现编程”—>依赖倒转原则，
- “多用组合，少用继承”—>合成/聚合复用原则
OO模式：策略模式----封装算法族，分别封装它们，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
扫一扫
1262
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
