阅读 301

TS 设计模式之策略模式

故事的主人公叫小 M ,他一直想在工作之外再赚点钱,某一天,他突发奇想,想去开一家网店,卖什么呢?最近新发布的 13 香 iPhone、iPad,肯定很多人买,那我去卖保护壳?肯定大卖,说干就干,第二天他就把自己的网店支愣起来了。

虽然网店申请好了,但是他的产品还没设计好,于是乎,他开始当「架构师」,设计他的产品。

一口吃不成个胖子,他想先让他家的保护壳可以自定义颜色和材质,为了方便所有的保护壳使用,他做了一个父类,实现了设置颜色、设置材质这两个功能。

image.png

type Color = 'black' | 'red' | 'green';
type Material = '橡胶' | '皮质' | '硬质塑料'

class 保护壳 {
  private color: Color = 'black'
  private material: Material = '橡胶'

  constructor() {
    // ...
  }

  设置颜色(color: Color) {
    this.color = color
  }

  设置材质(material: Material) {
    this.material = material;
  }

  whoIAm() {
    console.log('我是保护壳')
  }
}
复制代码

设置好了这个保护壳父类后,继承这个父类的 iPhone 保护壳和 iPad 保护壳的代码就特别少,小 M 洋洋得意说:看我的设计水平多高,以后我的店做大了,想做小米手机的、华为手机的,根本不需要写代码,只需要继承一下就好!

class IPhone extends 保护壳 {
  whoIAm() {
    console.log('我是 iPhone 保护壳')
  }
}

class IPad extends 保护壳 {
  whoIAm() {
    console.log('我是 iPad 保护壳')
  }
}
复制代码

刚好,有用户下单说,我想要一个红色、皮质的 iPad 保护壳,小 M 直接就用刚才建的 Ipad 类运行下面两行代码,嗖的一下就做好了:

const a = new IPad()
a.设置材质('皮质')
a.设置颜色('red')
复制代码

随着时间的推移,他家的网店慢慢做大了,又支持了小米手机、小米平板、华为手机、华为平板等数十种产品。

做好了这一步,小 M 并不满足,我那只是一个开始,为了能占领某某平台的榜首,我需要我的保护壳与众不同!

先让保护壳支持用户 DIY 吧?

怎么实现呢,小 M 想,这简单呀,就在父类加一个 DIY 方法就好了,这样我们店里卖的全部保护壳就都能一下支持 DIY 了:

class 保护壳 {
  ...

  DIY() {
     console.log('我是父类的 DIY')
    // 用户自己 DIY
  }
  ...
}
复制代码

确实,这样以来,所有保护壳的子类都能进行 DIY 了。但是这只是短暂的黎明。

就在此时,小 M 遇到了开网店的第一个打击,虽然它设计好了方案,但是工厂那里由于原材料不够,暂时不能让 iPad 支持 DIY,而我们的 DIY 方法加到了所有的保护壳中,要赶紧的下线掉。

怎么办呢?小 M 想,这可难不倒我,我直接让 iPad 保护壳的类里,写一个空的 DIY 方法,覆盖一下父类的的 DIY 方法就好。

class IPad extends 保护壳 {
  DIY() {
      // 什么也不做,只用了覆盖
  }

  whoIAm() {
    console.log('我是 iPad 保护壳')
  }
}
复制代码

这次问题算是解决了,但是又有问题了。

有一位顾客要求华为平板保护壳的 DIY 功能更丰富一点。没办法,顾客是爹呀,这时候 小 M 不得不找这个保护壳,按照他的要求修改 DIY 函数。

后来那位顾客的一个朋友发现,你的保护壳不错哎,但是他使用的是 iPad ,所以,也想在 iPad 里面有一样的 DIY 功能,小 M 又得去 iPad 的子类里面去修改。

这种情况经常发生,他按照上面的方法在每个子类里面改来改去,发现重复代码越来越多,但是又很难复用。

终于有一天,他忍受不了每次都要去子类里面修改的痛苦了,决心要修改一下代码的架构。

他发现 DIY 这个行为经常因为各种原因被修改,所以第一步,他打算先把这个行为抽象出来:

type DeviceType = 'mi-11' | 'mid-pad-5' | 'iphone' | 'ipad'

interface DIYBehavior {
  DIY: () => void
}
复制代码

接下来他根据可不可以 DIY,做了两个实现了这个接口的类。

如果当前可以 DIY,就是这个类:

class CanDIY implements DIYBehavior {
  private deviceType: DeviceType

  constructor(deviceType: DeviceType) {
    this.deviceType = deviceType;
  }

  DIY() {
    console.log(`我要对这个${this.deviceType}进行 DIY`)
  }
}
复制代码

当不能 DIY 的时候,就用这个:

class CanNotDIY implements DIYBehavior {
  private deviceType: DeviceType

  constructor(deviceType: DeviceType) {
    this.deviceType = deviceType;
  }

  DIY() {
    console.log(`目前对这个${this.deviceType}不能进行 DIY`)
  }
}
复制代码

我们完全把 DIY 这个行为的逻辑抽离了出去,那怎么用呢?

假如,目前我们的 iPad 平板支持 DIY,我们就可以按照如下的方式组织我们的 iPad 类:

class IPad extends 保护壳 {
  private ipadDIY: DIYBehavior

  constructor() {
    super();
    this.ipadDIY = new CanDIY('ipad')
  }

  DIY() {
    this.ipadDIY.DIY()
  }
  ...
}
复制代码

也就是说,我们把 DIYBehavior 作为了我们保护壳的一个属性,只要是进行 DIY,就通过这个属性来做。

改成这样之后,我们设想一下,假如我们的平板的 DIY 的功能又增强了,支持了各种酷炫的功能,以前的设计我们可能要把每个支持 DIY 子类的 DIY 方法都改一下。

但是现在,我们完全不需要改动它们,我们只需要改动 CanDIY 这个类的 DIY 方法就好了!

不仅如此,如果我们某个类突然不支持 DIY 功能了,没关系,我们可以增加一个 setter,运行时修改这个变量:

class IPad extends 保护壳 {
  private _ipadDIY: DIYBehavior

  constructor() {
    super();
    this._ipadDIY = new CanDIY('ipad')
  }

  set ipadDiY(ipadDiY: DIYBehavior) {
    this._ipadDIY = ipadDiY;
  }

  DIY() {
    this._ipadDIY.DIY()
  }

  whoIAm() {
    console.log('我是 iPad 保护壳')
  }
}

const a = new Ipad()

a.ipadDiY = new CanNotDIY('ipad')
a.DIY() // 目前对这个ipad不能进行 DIY
复制代码

有没有感觉这样子组织方便、灵活了好多。我们再也不用担心 DIY 这个行为对我们的各个子类有别的什么影响了。

上面我们使用到的设计模式就是策略模式,下面是比较官方的定义,大家大概明白意思就好,反正感觉有点不像「人话」。

策略模式作为一种软件设计模式,指对象有某个行为,但是在不同的场景中,该行为有不同的实现算法。比如每个人都要“交个人所得税”,但是“在美国交个人所得税”和“在中华民国交个人所得税”就有不同的算税方法。 —— 维基百科

不知道大家看了上面的例子,在看这个定义是不是更理解了一点。

总结来说,我们可以把一些「行为」抽离出来,单独维护,以便我们可以灵活的对这些「行为」进行改动。

举一个比较常见的例子,如果我们想开发一个缓存模块,在这个缓存模块里的缓存有内存级别、session 级别、localStorge 级别,此时对于设置缓存、清除缓存的方法,我们就可以借助策略模式,把他们抽离出来。

另外,我们的 React 中一般会调用 this.setState 来更新视图,这个方法可以在 ReactDOM 下使用,也可以在 ReactNative 下使用,这是因为 React 中的更新器(updater)会根据平台的不同而不同,任你以后多加几个平台,只要实现了更新器规定的接口,就能正常的使用 React。这里的设计也是使用了策略模式。

在上面的示例中,我们实现 DIYBehaviour 这个接口使用的是类,这在其他语言中是很自然的,但这有点不太符合在 JavaScript 中使用习惯,我们在理解了策略模式后,遵循着它的准则,我们也可以使用函数来实现,这可能用起来更舒服、方便一点:

function canDiY(deviceType: DeviceType): DIYBehavior {
  return {
    DIY() {
      console.log(`我要对这个${deviceType}进行 DIY`)
    } 
  }
}

class IPad extends 保护壳 {
  private _ipadDIY: DIYBehavior

  constructor() {
    super();
    this._ipadDIY = canDIY('ipad') // 调用形式稍微改一下
  }
  ...
}
复制代码

到这里,小 M 终于开心的完成了对这段代码的重构,我们的故事就结束了。

谢谢各位的阅读,同时祝各位中秋假期快乐。

文章分类
前端
文章标签