第 9 章：TypeScript 类型设计哲学

在前面的章节中，我们学习了 interface 和 type 的技术细节、使用场景和决策方法。现在，让我们上升到更高的层次，探讨 TypeScript 类型设计的哲学。

类型是文档，也是约束

优秀的类型设计不仅仅是让编译器满意，更重要的是能够准确地表达代码的意图和约束。类型本身就是一种活文档，它比注释更可靠，因为它是可验证的。

// 不好的类型设计 - 信息不足
type User = {
  id: any;
  name: string;
  email: string;
}

// 好的类型设计 - 表达更多信息
type UserID = number & { readonly brand: unique symbol };
type Email = string & { readonly brand: unique symbol };

type User = {
  id: UserID;
  name: string;
  email: Email;
  createdAt: Date;
}

// 甚至更好的设计 - 使用精确的类型
type User = {
  id: number;
  name: string;
  email: `${string}@${string}.${string}`; // 更精确的邮箱类型
  createdAt: Date;
  role: 'admin' | 'user' | 'guest';
}

好的类型设计能够让代码自解释，减少对外部文档的依赖。

类型应反映业务意图，而非技术细节

类型设计应该从业务角度出发，而不是仅仅描述技术实现。一个好的类型定义应该让人一眼就能明白它的业务含义。

// 技术导向的类型设计
type PaymentData = {
  str1: string;
  num1: number;
  bool1: boolean;
}

// 业务导向的类型设计
type Payment = {
  transactionId: string;
  amount: number;
  isSuccessful: boolean;
  timestamp: Date;
  paymentMethod: 'credit_card' | 'paypal' | 'bank_transfer';
}

业务导向的类型设计更容易理解和维护，也能更好地适应业务的变化。

"可维护性" > "可扩展性"（除非真需要）

很多开发者在设计类型时过分追求可扩展性，却忽略了可维护性。事实上，大多数情况下，可维护性比可扩展性更重要。

// 过分追求可扩展性
interface Config {
  [key: string]: any; // 什么都能放，但失去了类型安全
}

// 更注重可维护性
type AppConfig = {
  apiUrl: string;
  timeout: number;
  retries: number;
  logLevel: 'debug' | 'info' | 'warn' | 'error';
}

除非你真的需要在运行时动态扩展类型（如插件系统），否则应该优先考虑可维护性。

明确的边界和职责

好的类型设计应该有明确的边界和职责，每个类型都应该有单一的职责。

// 职责不清的类型设计
interface User {
  id: number;
  name: string;
  email: string;
  password: string; // 不应该在所有地方都暴露密码
  createdAt: Date;
  updatedAt: Date; // 数据库相关字段不应该在所有场景都需要
  isValidPassword(pwd: string): boolean; // 方法和数据混在一起
}

// 职责清晰的类型设计
type UserPublicProfile = {
  id: number;
  name: string;
  email: string;
}

type UserCredentials = {
  userId: number;
  hashedPassword: string;
}

type UserMetadata = {
  createdAt: Date;
  updatedAt: Date;
}

interface UserRepository {
  findById(id: number): Promise<UserPublicProfile>;
  findByEmail(email: string): Promise<UserPublicProfile | null>;
  saveCredentials(credentials: UserCredentials): Promise<void>;
  updateMetadata(userId: number, metadata: UserMetadata): Promise<void>;
}

通过拆分类型，每个类型都有明确的职责，提高了代码的可维护性和安全性。

渐进式类型设计

类型设计应该是渐进式的，从简单开始，随着需求的复杂化而逐步完善，而不是一开始就试图设计完美的类型系统。

// 第一版：简单直接
type Todo = {
  text: string;
  completed: boolean;
}

// 第二版：增加 ID
type Todo = {
  id: number;
  text: string;
  completed: boolean;
}

// 第三版：增加时间戳和用户信息
type Todo = {
  id: number;
  text: string;
  completed: boolean;
  createdAt: Date;
  updatedAt: Date;
  userId: number;
}

// 第四版：使用更精确的类型
type TodoID = number & { readonly brand: unique symbol };
type UserID = number & { readonly brand: unique symbol };

type Todo = {
  id: TodoID;
  text: string;
  completed: boolean;
  createdAt: Date;
  updatedAt: Date;
  userId: UserID;
}

这种渐进式的改进方式比一开始就试图设计完美方案更加实用。

类型设计是一门艺术

最后，我们要认识到类型设计是一门艺术，而不是科学。它需要平衡多个因素：

1. 表达力 vs 复杂性 - 类型应该足够表达意图，但不能过于复杂
2. 灵活性 vs 约束性 - 类型应该提供足够的约束，但也要保持必要的灵活性
3. 一致性 vs 特殊性 - 类型系统应该保持一致，但对于特殊情况也要有所考虑

// 平衡的艺术示例
// 一方面提供强类型约束
type CurrencyCode = 'USD' | 'EUR' | 'GBP' | 'JPY' | 'CNY'; // 限制货币种类

type Money = {
  amount: number;
  currency: CurrencyCode;
}

// 另一方面也为特殊情况留有余地
type FlexibleMoney = Money | {
  amount: number;
  currency: string; // 允许其他货币代码
  isCustomCurrency: true;
}

小结

在本章中，我们探讨了 TypeScript 类型设计的哲学：

1. 类型既是文档也是约束
2. 类型应反映业务意图而非技术细节
3. 可维护性比可扩展性更重要（除非真需要）
4. 明确的边界和职责划分
5. 渐进式的类型设计方法
6. 类型设计是一门需要平衡的艺术

掌握了这些哲学原则，你就能够在面对具体的类型设计问题时做出更好的决策。

下一章，我们将总结整个专栏的内容，并探讨如何在面试中展现你的类型设计能力。

---

思考题： 回顾你在项目中的类型设计，有哪些地方体现了这些设计哲学？有哪些可以改进的地方？