Review 实战经典：2 种封装风格，你偏爱哪种？

背景交代

一直想做一个调研，到底有多少比例的 web 前端工友工作内容以 开发后台管理系统 为主。

本瓜虽然以前也做过小程序项目、H5项目，但现实仍是以开发后台管理系统为主，是个不折不扣的“后管前端er”。大部分 web 前端工友应该也相似吧，这或许是由市场需求决定的。

所以大家在后台管理系统项目中遇到的很多问题也都是相似的，代码很值得 review，本篇带来一例（真实）~

闲言少叙，开冲！！ヾ(◍°∇°◍)ﾉﾞ

众所周知，在后台管理项目中，这样色的 table 是最常见的：

这个 table 中，主题模板有很多状态，比如：草稿 状态、已发布 状态、待审核 状态等等；

点击这些状态又进入到不同的操作页中，比如：草稿对应 新建 操作页，已发布对应 修改 操作页，待审核对应 审核 操作页等等。

在不同的操作页中意味着要请求不同的 接口、不同的接口意味着有不同的请求 参数。

你会惊讶的发现 新建页、修改页、审核页 其实都长得差不多！ 大概像下图这样色的（因为它们都会列出 table 的大部分字段，不同的字段存在不同的展现，有些只读、有些可写、有些存在关联项等等）：

实际项目中的 form 会比上述截图所示复杂得多。比如本瓜所在项目中，这样的操作页，有几十个字段，包括查看、编辑、状态关联等。此处仅做抽象示意处理。

基于上面的背景，我们可以想象：如果每个操作页面都是独立的，新建页有几十个表格字段、编辑页有几十个表格字段、审核页有几十个表格字段……而这些字段大部分类似，只是在部分字段上有区别或定制化的写法，那肯定不至于：有几个操作页，就复制几个页面吧？！

这样没有任何复用思维，每当需要增删改字段的时候，都要在多个页面中进行操作，这是“大聪明”做法。

于是乎，我们需要复用！！

（复用！又是复用！写业务代码最牛b的地方就是复用。高耦合、低内聚就是说如何复用。设计模式也是为了合理复用；就连写算法的时候，复用也是最牛b的，如何复用题干条件、或者复用空间来换取时间等等）

手段、方法、途径有很多，这里拎出来单讲的一点复用是：对请求参数的封装复用。

代码抽象

我们尝试将上一节的背景做伪代码的抽象（也可稍作修改在控制台调试）：

如果不做任何封装，它将会是类似这样的：

// 设一个页面的全局表格对象
const ruleForm = {
                  type:"fe",
                  time:"20200721",
                  title:"day day up",
                  status:"draft",
                  weight:999,
                  comment:"great",
                  balabala:"我是冗余参数1",
                  bilibilib:"我是冗余参数2"
                  }

• 新建操作页参数

const {type,time,.title,status.weight,comment} = ruleForm // 解构得值
const getCreateParam = function(){
      // ...省略一系列操作
      return {only: "create"}
}
const createParam = getCreateParam() // 得到特殊传参

const param = {
    // 公共传参
    type,
    time,
    title,
    status,
    weight,
    comment,
    // 特殊传参
    createParam
}

createRequest(param).then(res=> ... )

• 修改操作页参数

const {type,time,.title,status.weight,comment} = ruleForm
const getEditParam1= function(){
      // ...
      return {only1: "edit1"}
}
const editParam1 = getEditParam1()
const getEditParam2= function(){
      // ...
      return {only2: "edit2"}
}
const editParam2 = getEditParam2()

const param = {
    // 公共传参
    type,
    time,
    title,
    status,
    weight,
    comment,
    // 特殊传参
    editParam1,
    editParam2
}

editRequest(param).then(res=> ... )

• 审核操作页参数

const {type,time,.title,status.weight,comment} = ruleForm
const getReviewParam1= function(){
      // ...
      return {only1: "review1"}
}
const reviewParam1= getReviewParam1()
const getReviewParam2= function(){
      // ...
      return {only2: "review2"}
}
const reviewParam2= getReviewParam2()
const getReviewParam3= function(){
      // ...
      return {only3: "review3"}
}
const reviewParam3= getReviewParam3()

const param = {
    // 公共传参
    type,
    time,
    title,
    status,
    weight,
    comment,
    // 特殊传参
    reviewParam1,
    reviewParam2,
    reviewParam3
}

reviewRequest(param).then(res => ...)

试想一下这个参数是 10 个或20 个，甚至30 个呢？

实际的业务代码中变量赋值、变形，比这个会复杂的多的多！

1. 面向对象封装

第一种，我们先用面向对象的思路来封装上述过程：

// 获取公共参数

class CommonParam {
  constructor(){
      this.ruleForm = ruleForm
  }
  get(){
    const {type,time,title,status,weight,comment} = this.ruleForm
    return{type,time,title,status,weight,comment}
  }
}

// 获取创建操作的参数

class CreateParam extends CommonParam {
  getCreateParam(){
    // ...省略一系列操作
    return {only: "create"}
  }
  get(){
      const para = super.get()
      return {...para,...this.getCreateParam()}
  }
}

let creatParam = new CreateParam().get()

createRequest(creatParam).then(res=> ... )

// 获取编辑操作的参数

class EditParam extends CommonParam {
  getEditParam1(){
    return {only1: "edit1"}
  }
  getEditParam2(){
    return {only2: "edit2"}
  }
  get(){
      const para = super.get()
      return {...para,...this.getEditParam1(),...this.getEditParam2()}
  }
}

let editParam = new EditParam().get()

editRequest(editParam).then(res=> ... )

// 获取审核操作的参数

class ReviewParam extends CommonParam {
  getReviewParam1(){
    return {only1: "review1"}
  }
  getReviewParam2(){
    return {only2: "review2"}
  }
  getReviewParam3(){
    return {only3: "review3"}
  }
  get(){
      const para = super.get()
      return {...para,...this.getReviewParam1(),...this.getReviewParam2(),...this.getReviewParam3()}
  }
}

let reviewParam = new ReviewParam().get()

reviewRequest(reviewParam).then(res=> ... )

有工友问，这里继承也就只继承了公共参数，有必要写 class 类吗？

本瓜觉得，如果你的代码都是面向过程的风格，那这里写成这样，多少有点突兀；但如果大量都是用类做了封装的，这里也有必要做封装。

1. 代码风格保持一致；
2. class 还有一个好处，代码呈现块状，声明和调用是分开的，这一点很重要；
3. 当然也利于后续扩展、改造。自上而下的过程式代码写多了，会很难阅读以及 debugger。

2. 函数式编程封装

第二种，我们用函数式编程的思维去封装上述过程：

要借助我们的老朋友， compose 函数进行函数组合~

• 简易版本 compose 函数代码如下：

export const compose = function(...fns) {
  return function composed(result) {
    // 拷贝一份保存函数的数组
    var list = fns.slice()
    while (list.length > 0) {
      // 将最后一个函数从列表尾部拿出并执行它
      result = list.pop()(result)
      if (result === 'breakCompose') { // * 任一步骤 renturn "breakCompose" 可以提前结束流程；
        break
      }
    }
    return result
  }
}

有一位工友问过 compose 过程中如何 break，以上代码来自本瓜实战项目，就能实现；compose 函数可以做很多改造，可以自己动手试试~

封装本篇实战的请求参数：

/******函数声明部分******/

/*
* 公共参数
*/
const step_getCommonParam = function(ruleForm){
    const {type,time,title,status,weight,comment} = ruleForm
    return{type,time,title,status,weight,comment}
}

/*
* 创建步骤函数
*/
const step_getCreateParam= function(args){
    // ...省略一系列操作
    return {...args,only: "create"}
}
const step_createRequest = function(creatParam){
    return createRequest(creatParam).then(res=> ... )
}

/*
* 编辑步骤函数
*/
const getEditParam1= function(args){
    // ...
    return {...args,only: "edit1"}
}
const getEditParam2= function(args){
    // ...
    return {...args,only: "edit2"}
}
const step_editRequest = function(editParam){
    return editRequest(editParam).then(res=> ... )
}

/*
* 审核步骤函数
*/
const getReviewParam1= function(args){
    return {...args,only1: "review1"}
}
const getReviewParam2= function(args){
    return {...args,only1: "review2"}
}
const getReviewParam3= function(args){
    return {...args,only1: "review3"}
}
const step_reviewRequest = function(reviewParam){
    return reviewRequest(reviewParam).then(res=> ... )
}

/******函数调用部分******/

const handleCreate = (...args) => {// 创建操作
  const steps = [step_createRequest, step_getCreateParam, step_getCommonParam] // 步骤从右自左读
  compose(...steps)(...args)
}

handleCreate(ruleForm)

const handleEdit = (...args) => {// 编辑操作
  const steps = [step_editRequest, step_getEditParam2,step_getEditParam1, step_getCommonParam]
  compose(...steps)(...args)
}

handleEdit(ruleForm)

const handleReview = (...args) => {// 审核操作
  const steps = [step_reviewRequest,step_getReviewParam3,step_getReviewParam2,step_getReviewParam1,step_getCommonParam]
  compose(...steps)(...args)
}

handleReview(ruleForm)

如何？老观众有种熟悉的味道吧？和上面的代码对比，可以明显的感受风格的不一样吧？

Review 小结

本篇带来了后台管理系统常见的接口参数的封装 2 种风格。

最开始的代码，不做任何设计，复制多份，自上而下、过程式的风格；

优化1：借助 es6 class，js 可以简单的写出 面向对象的代码风格；

优化2：用 compose 函数组合的方式，实现 函数式编程风格。

过程式、面向对象、函数式，这种代码风格的学名是什么？

答：编程范式。

编程范式的思路不仅在原生 js 可以用，在 jq 中也可用，在 vue 、react 框架等等都可以用。感受感受，其实有些框架本身的一些设计是偏向不同风格的，js 是多范式语言，jq 偏向操作型过程式、vue 无明显倾向、过程式、面向对象、函数式都行、react 有点偏向函数式……

上述是本瓜项目实战的一点 review 体会。

由于本篇部分代码是伪代码，示意参考，或不尽完善，请各位斧正。

OK，以上便是本篇分享。点赞关注评论，为好文助力

我是掘金安东尼 🤠 100 万人气前端技术博主 INFP 写作人格坚持 1000 日更文 关注我，安东尼陪你一起度过漫长编程岁月