为什么在 TypeScript 中应优先使用范例而非接口

范例和接口是每个 TypeScript 步伐中常用的强大功能。然而，由于范例和接口在功能上非常相似，这就引出了一个题目：哪一个更好？
  今天，我们将评估范例和接口，并得出结论，为什么在大多数情况下你应该使用范例而不是接口。
  它们的区别是什么？

  我们分析一下这个 Person 范例和接口定义：

1. type Person = {
2.   name: string
3.   age: number
4. }
6. interface Person {
7.   name: string
8.   age: number
9. }

复制代码

显然，范例和接口的语法相似，关键区别在于范例使用 = 定义对象的形状，而接口则没有。不过，事变远不止这些。
  可扩展性

  在可扩展性方面，许多人认为接口显然是赢家，因为接口可以使用 extends 关键字扩展其他接口。

1. // 可扩展性示例
3. interface Person extends Job {
4.   name: string
5.   age: number
6. }
8. interface Job {
9.   job: string
10. }
12. // 使用 Person 和 Job 的属性。
13. const person: Person = {
14.   name: "John",
15.   age: 25,
16.   job: "全栈 Web 开发者",
17. }

复制代码

在这里，Person 接口扩展了 Job，因此 Job 接口的属性合并到 Person 中。
  另一方面，范例也可以通过使用连合（|）或交叉（&）操作符来扩展现有范例。

1. // ✅ 可以正常工作 
2. type Person = {
3.   name: string
4.   age: number
5. } & { job: string }
7. // ❌ 不可以正常工作 
8. interface Person {
9.   name: string
10.   age: number
11. } & { job: string }

复制代码

实现

  TypeScript 中的接口兼容面向对象编程（OOP），类似于其他语言（如 Java 或 C#）。这意味着接口可以通过 implements 在类中实现。
  如今让我们将 Person 定义为一个类，并实现一个新接口 Work，并满意它们之间的契约。

1. // 实现示例
3. interface Work {
4.   doWork: () => void
5. }
7. class Person implements Work {
8.   name: string
9.   age: number
11.   constructor(name: string, age: number) {
12.     this.name = name
13.     this.age = age
14.   }
16.   // 实现 doWork 方法以满足 Work 接口。
17.   doWork() {
18.     console.log("Working...")
19.   }
20. }
22. const person = new Person("John", 25)
23. person.doWork()

复制代码

因此，假如你常常使用 OOP，接口将比范例更适用，因为范例不能直接由类实现。
  性能

  在谈到性能时，我们指的是 TypeScript 编译器进行的“范例查抄”的性能，这随着代码库的增长而呈指数下降。
  这就是为什么我们要基准测试范例和接口在范例查抄性能方面的优劣。
  为什么接口可能有害

  TypeScript 中的接口有一个独特的特性，称为声明合并。
  声明合并是指 TypeScript 编译器将两个或多个具有相同名称的接口合并为一个。

1. // 初始 Person 接口
2. interface Person {
3.   name: string
4.   age: number
5. }
7. // 使用“声明合并”精炼 Person 接口
8. interface Person {
9.   gender: string
10. }
12. // 使用“合并”的接口定义一个新“person”
13. const person: Person = { name: "John", age: 25, gender: "Male" }

复制代码

一方面，这个特性允许方便地精炼和扩展现有接口，而不需要更改其他依赖项。
  以下是我重新声明 @auth/core/types 模块并精炼 Session 接口的示例。
  

  这就是一个声明合并的示例，因为我用新的 id: string 属性精炼了原始接口。
  这是接口的合理使用场景，因为它允许开发职员轻松扩展库接口。
  范例不允许如许做，因为它们在创建后是不可变的。
  另一方面，声明合并可能对代码库产生有害且意想不到的影响，主要有以下两个原因：
  

• 优先级次序：后面的声明总是优先于前面的声明。假如不小心，当声明合并在步伐的许多部门发生时，可能会导致意外的题目。
  
• 与类的不安全合并：由于 TypeScript 编译器不查抄属性初始化，这可能会导致意外的运行时错误。范例没有这个题目，因此更简单、更安全。
  

  结论

  除非特定的接口举动是须要的，比方可扩展的精炼或使用 OOP 实现，否则最好坚持使用范例。范例机动、简单，并且避免了与声明合并相干的陷阱。
  范例在性能方面与接口相同，这为你选择范例而不是接口提供了另一个理由。
  

  末了：
  vue2与vue3技偶合集
  VueUse源码解读

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。