likes
comments
collection
share

TypeScript 类型系统的缺陷：结构化类型之殇，从鸭式辨型到鹅鸭之辨

作者站长头像
站长
· 阅读数 65

如果有帮助到你，不妨点赞支持 ❤️

TLDR

结构化类型系统让编程语言更灵活，但是会给 bug 留有余地，具名类型选择了程序的正确性，即使结构相同的类型，只要类型名不一样就不能互相赋值，因为二者具备不同的语义。

Structural Type VS Nominal Type 从鸭式辨型到鹅鸭之辨

TypeScript 的类型系统是结构化的，在类型之间做比较的时候只会将其成员做比较。即如果一个类型具备『鸭子』的所有属性，那它就是一只鸭子。如果一只『鹅』有鸭子的所有属性，那么它也是一只『鸭子』，即著名的『鸭式辨型 Duck Typing』。这种『不严谨性』带来灵活的的同时也会滋生一类 bug。

例如下面这两个类型在结构化类型系统中是可互相赋值和等价的：

interface Ball {
  diameter: number;
}

interface Sphere {
  diameter: number;
}

而具名类型系统（nominal type system）是指每一个不同名的类型都是唯一的，即使含有相同结构也无法在这些类型间相互赋值，因为有时候我们要严格的控制『鹅就是鹅🐧，不能是鸭子🦆』。

如果你想了解更多有关『结构化类型』知识，请看 example/structural-typing。

结构化类型的缺陷

结构化类型有其缺陷，例如在某些场景下字符串和数字具备特殊的上下文，相互之间不能转换。

示例 1：

  • User Input Strings (unsafe)
  • Translation Strings 和
  • User Identification Numbers
  • Access Tokens

示例 2：来自 ts-brand

declare function getPost(postId: number): Promise<Post>;
declare function getUser(userId: number): Promise<User>;

interface User {
  id: number;
  name: string;
}

interface Post {
  id: number;
  authorId: number;
  title: string;
  body: string;
}

有以下函数，通过 postId 获取其作者信息：

function authorOfPost(postId: number): Promise<User> {
  return getPost(postId).then(post => getUser(post.id)); // ❌ post.id
}

你是否发现了其中的bug？我们错误地将 post id 传给了 getUser，正确应该是 post.authorId

function authorOfPost(postId: number): Promise<User> {
  return getPost(postId).then(post => getUser(post.authorId)); // ✅ post.authorId
}

因为 post.id 和 post.authorId 都是 number 类型，TS 没法帮我们检测出类型异常。

具名类型能帮助我们避免此种『有相同的类型或字段但具备不同语义的类型不能视之等价』的问题，即使他们都是字符串或数字。即『具名类型使得程序的正确性能通过类型检测器来保证』

如何实现具名类型

共有四种方式：

  • #1: 具备私有属性的类 - Class with a private property
  • #2: 带 Brand 的 interface - Brands
  • #3: 交叉类型 - Intersection types
  • #4: 交叉类型 + Brand - Intersection types and brands

每一种都可以但建议在你的代码库中始终使用一种实现。

Use Case

举一个简单的例子，美元和欧元之间的计算，我们实现的目标是不允许货币相加如果二者都不是美元。也就是只有同种货币方可相加。

Approach #1: 具备私有属性的类

class USD {
  private __nominal: void;
  constructor(public value: number) {};
}

class EUR {
  private __nominal: void;
  constructor(public value: number) {};
}

const usd = new USD(10);
const eur = new EUR(10);

function gross(net: USD, tax: USD) {
  return { value: net.value + tax.value } as USD;
}

// 测试下
gross(usd, usd); // ok
gross(eur, usd); // Error: Types have separate declarations of a private property '__nominal'.

编译后：

"use strict";
class USD {
    constructor(value) {
        this.value = value;
    }
    ;
}
class EUR {
    constructor(value) {
        this.value = value;
    }
    ;
}
const usd = new USD(10);
const eur = new EUR(10);
function gross(net, tax) {
    return { value: net.value + tax.value };
}
gross(usd, usd); // ok
gross(eur, usd); // Error: Types have separate declarations of a private property '__nominal'.

此方式利用的是只要 class 具备私有属性则不能视作等同类型，即二者不能互换是因为具有一个相同的私有属性。

和其他方式不同的是无需强制类型转换。缺点是 class 会被保留下来，存在运行时的侵入，因为要构造特定类的实例。不够优雅 😀。其次类型不匹配的错误信息很隐晦难以理解。

Approach #2: 带 Brand 的 interface

interface USD {
  _usdBrand: void;
  value: number;
}

interface EUR {
  _eurBrand: void;
  value: number;
}

let usd: USD = { value: 10 } as USD;
let eur: EUR = { value: 10 } as EUR;

function gross(net: USD, tax: USD) {
  return { value: net.value + tax.value } as USD;
}

gross(usd, usd); // ok
gross(eur, usd); // Error: Property '_usdBrand' is missing in type 'EUR'.

此方式利用的是只要两个 interface 有不同字段则二者不可等同。

编译后：

"use strict";
let usd = { value: 10 };
let eur = { value: 10 };
function gross(net, tax) {
    return { value: net.value + tax.value };
}
gross(usd, usd); // ok
gross(eur, usd); // Error: Property '_usdBrand' is missing in type 'EUR'.

TS team 也是使用的这个方式。 注释很重要，此处特意贴出来：

// Note: 'brands' in our syntax nodes serve to give us a small amount of nominal typing.
// Consider 'Expression'.  Without the brand, 'Expression' is actually no different
// (structurally) than 'Node'.  Because of this you can pass any Node to a function that
// takes an Expression without any error.  By using the 'brands' we ensure that the type
// checker actually thinks you have something of the right type.  Note: the brands are
// never actually given values.  At runtime they have zero cost.

export interface Expression extends Node {
    _expressionBrand: any;
    contextualType?: Type;  // Used to temporarily assign a contextual type during overload resolution
}

翻译重点：

_expressionBrand 字段让 Expression 类型变成了具名类型。如果不理解的话你这样想，如果没有这个字段，Expression 将和 Node 没有任何区别（在结构上），这样的话你可以将 Node 传入原本只接受 Expression 入参的函数，而不会导致任何类型错误。注意：该字段不会赋值，故运行时损耗为 0。

  • 优点：因为不会赋值给 brand 字段，运行时损耗为 0；类型会在运行时被抹除；报错信息有待改善。
  • 缺点：仍然需要将原始类型包装 { value: foobar }，即会有运行时代码侵入。

仍然不够优雅 😀

Approach #3: 交叉类型

class Currency<T extends string> {
  private as: T;
}

type USD = number & Currency<"USD">
type EUR = number & Currency<"EUR">

const usd = 10 as USD;
const eur = 10 as EUR;

function gross(net: USD, tax: USD) {
  return (net + tax) as USD;
}

gross(usd, usd); // ok
gross(eur, usd); // Error: Type '"EUR"' is not assignable to type '"USD"'.

编译后：

"use strict";
class Currency {
}
const usd = 10;
const eur = 10;
function gross(net, tax) {
    return (net + tax);
}
gross(usd, usd); // ok
gross(eur, usd); // Error: Type '"EUR"' is not assignable to type '"USD"'.

优点：因为不会赋值给 as 字段，运行时损耗为 0；类型会在运行时被抹除；仍然是原始类型，无代码侵入；报错信息清晰具体。 缺点：需要显示类型转换。

针对缺点显示类型转换可以通过函数来解决，如此优雅不少：

function ofUSD(value: number) {
  return value as USD;
}

function ofEUR(value: number) {
  return value as EUR;
}

const usd = ofUSD(10);
const eur = ofEUR(10);

function gross(net: USD, tax: USD) {
  return ofUSD(net + tax);
}

Approach #4: 交叉类型 + Brand

type Brand<K, T> = K & { __brand: T }

type USD = Brand<number, "USD">
type EUR = Brand<number, "EUR">

const usd = 10 as USD;
const eur = 10 as EUR;

function gross(net: USD, tax: USD): USD {
  return (net + tax) as USD;
}

gross(usd, usd); // ok
gross(eur, usd); // Type '"EUR"' is not assignable to type '"USD"'.

这是前两个方式的组合。

编译后：

"use strict";
const usd = 10;
const eur = 10;
function gross(net, tax) {
    return (net + tax);
}
gross(usd, usd); // ok
gross(eur, usd); // Type '"EUR"' is not assignable to type '"USD"'.

可以看出类型被完全擦除，写法上没有侵入，报错信息很具体和清晰。缺点是强制类型转换。不过已经达到了心目中的『优雅』👍。

下面的例子也很好，特意摘抄出来和大家分享。

同样使用方式四的交叉类型，通过添加 __brand（约定俗成）字段让普通的字符串没法赋值给 ValidatedInputString，因为我们不能信赖用户的输入。

type ValidatedInputString = string & { __brand: "User Input Post Validation" };

下面的函数将用户输入的普通字符串转换已经通过校验的输入字符串，注意有趣的是我们在校验的最后显示告诉TS这是已经通过校验的字符串。

const validateUserInput = (input: string) => {
  const simpleValidatedInput = input.replace(/\</g, "≤");
  return simpleValidatedInput as ValidatedInputString;
};

现在有一个函数仅能够接受通过校验的输入字符串，类型定义为具名类型 ValidatedInputString，而非普通的字符串 string 类型。因为用户的输入应当要被认为是『危险』的。

const printName = (name: ValidatedInputString) => {
  console.log(name);
};

我们看看这样做的好处是什么？

假若用户输入了某些不安全的内容，通过校验函数后方可允许被输出到屏幕上，

const input = "alert('bobby tables')";
const validatedInput = validateUserInput(input);
printName(validatedInput);

一切符合预期。

若我们尝试将未经校验的用户输入内容直接输出。类型检查器或编译器会报错：

printName(input); // Argument of type 'string' is not assignable to parameter of type 'ValidatedInputString'.
//  Type 'string' is not assignable to type '{ __brand: "User Input Post Validation"; }'.(2345)

如果还感兴趣的话可以阅读下这个 issue TypeScript/issues/202，关于具名类型不同的创建方式以及 TS Team 对其的权衡的大讨论，400+评论。以及这篇文章《Nominal typing techniques in TypeScript》对其做了很完善的总结。本文大多翻译也是来自该文。

总结

结构化类型系统让编程语言更灵活，但是会给 bug 留有余地，具名类型选择了程序的正确性，即使结构相同的类型，只要类型名不一样就不能互相赋值，因为二者具备不同的语义。

本文来自两篇文章的结合翻译 Nominal typing techniques in TypeScript 和 typescriptlang example - nominal-typing。

参考

更多阅读资料

头图来自 Unsplash Thao Le Hoang。

转载自:https://juejin.cn/post/7082777320188182536
评论
请登录