如何让孩子爱上设计模式 ——14.策略模式(Strategy Pattern)

标签： 设计模式初涉

---

描述性文字

本节讲解的是行为型设计模式中的第一个模式： 策略模式，
这个模式非常简单，也很好理解。
定义一系列的算法，把每个算法封装起来，并使得他们可以相互替换，
让算法独立于使用它的客户而变化。
一般用来替换if-else，个人感觉是面向过程与面向对象思想的
过渡，这里举个简易计算器的栗子，帮助理解~

---

普通的if-else/switch计算器

普通的面向过程if-else简易计算器代码如下：

运行结果如下：

这里我们也可以改成switch，代码显得简洁一些，但也是换汤不换药

---

策略模式实现简易计算器

其实就是把if-else涉及到的算法，策略行为抽取出来，统一的接口，
然后各自实现，比如这里我们把抽取计算的接口，然后继承分别实现
加减乘除：

编写上下文对象，负责与具体的策略类交互

客户端调用：

输出结果：

好了，这就是最简单的策略模式的栗子了，面向对象的if-else到
面向过程的策略模式，算法可以独立于使用它的用户而变化，比如
这里我们加多一个求余也非常简单。

---

概念相关

定义

定义一系列算法，将每一个算法封装起来，并让它们可以相互替换；
策略模式让算法独立于使用它的客户而变化

三个角色

• Context: 上下文环境类，持有抽象策略角色的引用
• Strategy: 抽象策略类，定义一系列抽象的算法策略
• ConcreteStrategy: 具体策略类，实现具体的算法策略

UML类图

应用场景

• 1.一个系统需要动态地在几种算法中选择一种的情况
• 2.系统里面有许多类，它们之间的区别仅在于它们的行为，使用策略模式可以动态
  地让一个对象在许多行为中选择一种行为
• 3.一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重条件
  选择语句来实现。此时，使用策略模式，把这些行为转移到相应的具体策略类里面，
  就可以避免使用难以维护的多重条件选择语句。
• 4.不希望客户端知道复杂的、与算法相关的数据结构，在具体策略类中封装算法
  与相关的数据结构，可以提高算法的保密性与安全性。

优缺点

优点：

• 定义一系列算法实现，实现让这些算法可相互替换
• 避免多重条件语句
• 更好的扩展性

缺点：

• 调用者必须了解每种策略的不同，自行选择使用哪个策略
• 增加了对象数目，可使用享元模式在一定程度上减少对象数量
• 只适合扁平的算法结构，在一个策略接口下，运行时只有一个算法被使用，
  这样就限制了算法的使用层级，使用时不能嵌套调用

---

本节代码：

https://github.com/coder-pig/DesignPatternsExample/tree/master/13.Strategy%20Pattern

---