【设计模式】策略模式
1，意图：
定义一系列的算法/或者行为，把他们一个个封装起来，并且使得他们可以相互替换。使得算法和行为的变化可以独立于他们的客户而变化。
例子： 实例化一个Person，我们吃意大利面可以用叉子，但是不习惯的人可以用筷子，这种吃面的行为或者说不同的算法可以独立的切换或者使用。
2，别名
Policy
3，动机
对象直接包含某种算法会复杂化问题，使得客户程序庞大且难以维护，当我们需要支持多种算法或者行为（通常这些行为或者算法是互斥的，客户同一时刻只会选择其中某一种算法或者行为 ）
4，适用性：
许多相关的类，仅仅是行为有差异。“策略”提供了一种用多个行为的一个行为来配置一个类的方法。
一个类定义了多种行为，并且这些行为在这个类的操作种以多个条件语句的行为出现。应该将相关的条件分之移入它们格子的Strategy类中代替这些条件语句。 【简易计算器，2个number的4种基础运算】
需要使用一个算法的不同变体。【我们有一个文本流，要对其进行分析决定换行，需要不同的情况采用不同的算法】
以这个换行算法为例：我们定义不同的类来封装不同的换行算法，从而避免上面提到的问题。
实现：
composition长这样：
import Compositor from "./Compositor";
export default class Composition {
private _compositor
constructor(compositor: Compositor) {
this._compositor = compositor
}
repair() {
this._compositor.compose()
}
}接口【也可以定义成抽象类】Compositor长这样：
export default interface Compositor {
compose(param: any)
}一共有三种算法，我们只展示其中一种，其余两种根据需求不同是不同的逻辑，但是结构是一样的，我们看SimpleCompositor的代码：
import Compositor from "./Compositor";
export default class implements Compositor {
constructor(){}
compose(param: any){
console.log('策略1')
}
}测试入口文件长这样：
import Composition from "./Composition";
import SimpleCompositor from "./SimpleCompositor";
import TeXcompositor from "./TeXcompositor";
import ArrayCompositor from "./ArrayCompositor";
const quick = new Composition(new SimpleCompositor()),
slick = new Composition(new TeXcompositor()),
iconic = new Composition(new ArrayCompositor())
quick.repair()
slick.repair()
iconic.repair()5，参与者：
Strategy（策略，对应上面Compositor）
ConcreteStrategy（具体策略，对应上面SimpleCompositor 等具体实现类）
Context（上下文，对应上面Composition）
缺点：
客户必须知道所有的策略类，并自行决定。
策略类过多的解决方案： 工厂方法
上面的所有代码看这里： https://github.com/aeolusheath/design-pattern/tree/master/Strategy
参考资料：基本都来自于书籍 《设计模式：可复用面向对象软件的基础》 5.9
