作者：Hamm

https://juejin.cn/post/7272372568623710264

写在前面

也许跟大部分的前端开发者不同，我们使用了 Vue3 和 TypeScript，但我们也许是又回到了 老古董 的编程方式中，也许是习惯了 面向对象(OOP) ，又或者是跑了一圈，相比现在的 JavaScript、Python、PHP、Go、C# 等，依然还是钟爱 Java，我们不否认现在的主流在 函数式编程(FP) 上，也越来越少的开发者喜欢在前端也这么抽象的使用 面向对象编程，这篇文章只表达我们自己的喜好，不强加任何观点。

很多人问为什么我们在Vue上这么搞，这里总结几个原因：招聘的成本、重庆这个N线互联网城市的现状、公司的决策 等等。

我们如何使用面向对象

我们在前端也引入了大量的面向对象的影子，包含了一些 数据交互实体、 相似API的封装 等：）

什么 Service / Entity 是不是像极了 Java 写后端时候的样子？

数据实体的封装

数据实体作为前后端交互的主要数据对象，承载着前端和后端的数据交互、组件之间的数据交互等重要步骤。

如后端编程一样，我们将先按照指定的规范对数据结构进行约束，这里我们没有使用目前大家都喜欢的一些方式进行封装：如 interface, type 等，而是使用了 class 来进行封装。这里我们只谈谈这么封装的目的：

固定字段规范的数据实体

所有的数据库交互实体，都会包含ID等字段，所以我们先定义个 BaseEntity 来进行数据约束：

class BaseEntity {
    id!: number
    createTime!: number
}

class UserEntity extends BaseEntity {
    // 无需再编写 基类中 声明的公共字段
    name!: string
}

如上的方式，我们可以少写很多公共的字段，而在一些公共的组件中需要传递数据时候，我们可以限制类型为 BaseEntity 的子类即可，这样组件内就能取出传入数据的公共字段，比如可以直接取出 ID, 也可以自动的对创建时间进行友好的格式化显示等。

当然，这里也可以使用 interface 来定义，同样的实现继承来避免写相同的字段，我们为什么依然使用class, 请继续阅读

不固定规范的数据实体

难免碰到一些后端开发者不太喜欢使用相同的公共字段，就像下面的一些数据交互方式：

{
  "user_id": 123,
  "user_name": "admin"
}
json复制代码{
  "role_id": 122,
  "role_name": "管理员"
}

如上习惯的数据交互方式，就不太适合使用 interface 继承来处理了，但是配合装饰器，我们依然使用 class 的继承来实现这个需求：

我们还是声明了 BaseEntity 和 UserEntity，但是我们加上了一些装饰器，来配置一些关于数据转换方面的信息：）

class BaseEntity {
    id!: number
    createTime!: number
}

// 表示所有的用户字段 都需要用 user_ 开头
@Prefix("user_")
class UserEntity extends BaseEntity {
    name!: string
    idcard!: string
}

// 表示所有的角色字段 都需要用 role_ 开头
@Prefix("role_")
class UserEntity extends BaseEntity {
    name!: string
}

这样，我们就完成了一些配置，但可能这还不够，比如某一些字段 确实没有前缀，或者我们根本不想使用后端不规范的命名，比如后端给电话起了个简写的 pnum 当手机号？

@Prefix("user_")
class UserEntity extends BaseEntity {
    name!: string

    // 身份证号这个字段不需要前缀 就是 idcard
    @IgnorePrefix()
    idcard!: string
 
    @IgnorePrefix() 
    @Alias("pnum") //使用别名将后端的属性名称替代掉
    phone!: string
}

好的，于是我们开心的完成了关于字段的名称问题的一些配置，但我们还需要一些处理的方法。于是我们声明一个 BaseModel 的类作为超类，让 BaseEntity 去继承它，这样所有的实体都拥有了这些转换方法，如果你是个不带 ID 的普通数据模型也可以直接继承 BaseModel 。

// 读取装饰器的一些配置，提供一些转换的方法
class BaseModel {
    // 具体的转换方法实现可以查看文末提供的开源项目代码
    toJson() {
        // 当前对象转为普通的JSON对象的方法
    }

    fromJson(json: Record<string, any>) {
        // 将后端给过来的JSON转为我们需要的类对象
    }
}

class BaseEntity extends BaseModel {
    // 不再重复写了
}

那么接下来我们就可以完成一些数据转换，然后实现不管后端的字段名如何，都能轻松的应对：

const json = {} // 从后端拿回来的JSON
const user = new UserEntity().fromJson(json) // 当然，还可以直接提供一些静态方法：
// 如  const user = UserEntity.fromJson(json) 、 const userList = UserEntity.fromJsonArray(jsonArray)
console.log(user.id) // 直接取我们自己声明的 id 而不是跟着后端走的 user_id

怎么样，是不是很开心，我管你怎么改，我字段名可以不被你牵着鼻子走，即使后端接口把 user_id 改成了 userid ，我也不需要在我的代码中一个个的搜索跟着改：我只需要将 UserEntity 配置的装饰器改为 @Prefix("user")，如果对方需要改成 userId，我还可以再写个装饰器， @Hump()，然后在 BaseModel 中转换的时候判断是否标记这个驼峰装饰器，来选择是否需要将字段名自动驼峰处理。

：）是不是很有意思？

更变态的数据转换需求

如上所说，我们可以自动来处理一些字段名称的处理，我们也能来做一些字段属性类型的处理：

布尔、数字、字符串的转换
如果没有值，需要给默认值
如果是数组或者挂载的其他对象，如用户身上带了角色
是枚举值，需要枚举字典等
等等等等...
相似API的封装

在日常开发中，我们通常会遇到相同结构和请求方式的接口，有相同的接口命名方式，相同的参数和返回值等：）

一般来说，接口的请求地址可能不太一样，我们可以声明一个抽象类，要求子类中自行传入这个地址：

于是我们尝试使用一个 AbstractBaseService 类来进行一些基于面向对象继承的处理：）

abstract class AbstractBaseService {
    abstract apiUrl: string

    add() {
        request(this.apiUrl + "/add")
    }

    delete() {
    } // 删除

    // 等等等等
}

那么我们其他的子类就可以直接继承这个 Service 同时实现一下 apiUrl 这个属性（Java: 直接抽象属性???）

class UserService extends AbstractBaseService {
    apiUrl = "user"
}

UserService 就拥有了所有父类中的增删改查方法，是不是很爽？当然，这里再加上泛型，把数据类型也约束上：

abstract class AbstractBaseService<E extends BaseEntity> {
    abstract apiUrl: string

    add(entity: E) {
        request(this.apiUrl + "/add", entity.toJson())
    }

    delete(entity: E) {
        request(this.apiUrl + "/delete", entity.toJson())
    }
}

// 子类传入对应的泛型约束
class UserService extends AbstractBaseService<UserEntity> {
    apiUrl = "user"
}

那么，这里的封装不仅实现了父类方法的复用，连接口请求把类型都卡死了：

const user = new UserEntity()
user.id = 1
new UserService().add(user) // 正常不报错

const role = new RoleEntity()
role.id = 1
new UserService().add(role) // 滚犊子 类型不匹配

这样就完成了公共部分的封装，而且还加上了一些类型约束，如果再把这些通用的操作以及动态绑定的数据统一抽到一个 hook 中，那岂不是美滋滋？像这样：）

// ClassConstructor是我们封装的包装类
export function useAdd<E extends BaseEntity>(ServiceClass: ClassConstructor<E>, EntityClass: ClassConstructor<E>) {
    const formData = ref(new EntityClass())
    const service = ref(new ServiceClass())
    const isLoading = ref(false)

    const onAdd = () => {
        isLoading.value = true
        try{
            service.add(formData.value);
        }catch (e){
            alert("添加失败")
        }finally {
            isLoading.value = false
        }
    }

    return {
        formData, onAdd
    }
}

调用的视图可就更简单了：）

<template>
    <form>
        <input type="text" v-model="formData.name"/>
        <button @click="onAdd"></button>
    </form>
</template>
<script setup lang="ts">
    const {formData,onAdd} = useAdd(UserService,UserEntity)
</script>

这么写起来，是不是爽了很多呢？

本文总结

本文代码可能没有经过验证，都是写文章的时候顺带在 markdown 中直接手撸的，如有错误请评论区指出。

这里又回到了之前文章说的话题上了，我们也不仅仅是只使用了面向对象，我们也使用了函数式的一些hook。

没有必要在二者之间做出选择，成年人，为什么不能都要呢？

前端大学公众号祝您:2023 年暴富！万事如意！

分享前端干货，点赞就是最大的支持,比心❤️

用代码聊聊我们跟目前主流前端编程不一样的地方

写在前面

我们如何使用面向对象

数据实体的封装

固定字段规范的数据实体

不固定规范的数据实体

更变态的数据转换需求

相似API的封装

本文总结