11.在项目中适配模式的使用

使用背景

项目最近在用Taro重构，
在书写代码方面要求比较严格，
正好在跟老大调侃，
他偶尔看到我一筐switch…case…
给我指了指，
让我改用适配模式做一做。
本来项目任务都已经很紧了，
突然代码实现业务方式的改变，
让我有点猝不及防。
说实话本来是有点抗拒的，毕竟已经写了很多了，
不过后来琢磨了一下，产品的逻辑着实是乱的一批，
现在多写点代码，为了以后增改逻辑的时候，能少点坑，
看样子用上适配模式，也不失为一个好办法。

试用场景

“适配模式”是比较常用的设计模式之一，
核心的概念是，
将若干个互不兼容的类，使他们能放到一起去工作。
目前的业务场景是这样的：
在设置权限模块中，根据设置不同权限类型，
对页面有不同的渲染，同时请求不同的数据。

按照我平时的做法，都是会把几个权限，
每种权限分别抽象成一个标志字符，
另外将处理方式封成一个函数，
通过传入这个标志字符，来得出渲染结果以及所需的数据。

如果是比较规规矩矩的交互，我的方法还是比较快捷的。
可是这次实在是每种权限的渲染差异很大，
有的是点一项勾选一个，
有的是点一项勾选两个，
有的是点一项收起/展示另外两项，
很难用一个通用的逻辑去解析这种交互。

所以干脆写的透彻些，
用一个适配器，大大方方的去解决这个问题。
把每种权限，用一个类去清清爽爽的处理，
这样可以通过类实现物理隔离，不会有牵一发动全身的情况。
而且在以后维护的时候，只针对对应的类去修改就好。
代码量虽然会多，不过减少了维护成本。

代码实现

// 抽象出来的父类
interface IPermissionAdaptor {
  support: (result) => Boolean;     // 判断是否用该适配器
  resolve: (result) => Array<any>;  // 使用该适配器的逻辑处理方法
}
export {
  IPermissionAdaptor
};

// AAAAA 类型权限
class NoticeAAAAAdaptor implements IPermissionAdaptor{
  support = (objModuleItem) => {
    return objModuleItem.type === 'AAAA'
  }
  resolve = (objModuleItem) => {
    const arrResult = []
    // ...
    // do something
    // ...
    return arrResult
  }
}
// BBBBB 类型权限
class NoticeBBBBBdaptor implements IPermissionAdaptor{
  support = (objModuleItem) => {
    return objModuleItem.type === 'BBBBBB'
  }
  resolve = (objModuleItem) => {
    const arrResult = []
    // ...
    // do something
    // ...
    return arrResult
  }
}
// 待遍历类的数组，如果以后权限多了，可以再次拓展
const ModulePermissionAdaptors = [
  new NoticeAAAAAdaptor(),
  new NoticeBBBBBdaptor(),
  // ...
]

const AdaptorInvoker = {
  apply: (objModuleItem: PermissionResult) => {
    let arrResult = [];
    // 循环遍历，符合条件的适配器
    // 找到合适的就调用该适配器的逻辑实现方法，得到结果后，终止循环
    ModulePermissionAdaptors.every((adaptor) => {
      if (adaptor.support(objModuleItem)) {
        arrResult = adaptor.resolve(objModuleItem)
        return false
      }
      return true
    })
    return arrResult
  }
}

export default AdaptorInvoker;

1 2	// 调用方法 const arrResult = PermissionViewAdaptor.apply(objModuleItem)

后记

草草看来，
如果使用适配器模式的话，
代码量绝对是暴增，
但是这种写法很适合复杂的逻辑。

面向过程的写法确实很快，
而且代码量也不会看起来这么多。
可是，思路无法做到这么清晰，

以维护的角度来说，
如果两个月后找人再来维护这段代码。
面向过程那个面条式的逻辑，绝对会让你捋上半天。
说不定增加个功能，还得波及到其他的东西。
而这个适配器模式，让人很清除要在哪里修改，
也不会有该一处，波及其他逻辑的风险。

另外，我想说的是，有时候设计模式该用就得大胆去用，
多用才能对这个模式能有更深的理解。
多多利用公司重构代码的机会，
锻炼一下自身的架构思想。