【设计模式】策略模式

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 

                    菜鸟教程