这篇文章最初来自微信里朋友提的一个很小的面向对象设计问题:如何在不损失灵活性的前提下避免 instanceof?我保留这个起点,是因为它很自然地会走向接口、泛型、sealed hierarchy、structural typing 和代数数据类型——而结尾更个人的那部分,也正是我至今还愿意保留这篇长文的原因。

当时的情境很具体。朋友在写 FIT2099 的面向对象设计 assignment,需要一个根据对象类型采取不同行为的函数。但 tutor 给的反馈是:按这门课的标准,不允许使用 instanceof 和类型转换,依赖它们说明没有用好多态、组合和类型系统,会被狠狠扣分。朋友的困惑也合理——他要判断的本来就是一个接口,已经是一层抽象,而不是具体实现类。

我的回答是,这更像一个值得拆开的设计问题,而不是一条要服从的规则。在日常工程里,如果功能很小、团队也清楚后面会重构,临时写一个 instanceof 分支未必不能接受;但当变体变多,这个分支很容易在不知不觉中变得不完备——新增一种类型时,没有任何东西提醒你更新它。更稳妥的方向是把这种区分移进编译器能检查的结构里:多态、类型参数、sealed hierarchy。具体可以有几种做法:用泛型让编译器通过类型参数分发行为;用 Java 17 的 sealed class 声明一个封闭层级,让编译器帮你检查完备性;或者更保守一点,和组员约定一个共享的枚举,通过对象的某个方法暴露出来,让部分逻辑绕开 instanceof;在合适的场景,也可以用策略、观察者、访问者等设计模式,用面向对象的抽象替代硬编码的类型检查。

这个对话揭示了一个深层次的编程语言设计问题:我们如何在保持代码灵活性的同时,让编译器帮助我们发现错误?

instanceof的问题本质上是运行时类型检查编译时类型安全之间的权衡。当我们写下这样的代码:

if (obj instanceof String) {
// 处理字符串
} else if (obj instanceof Integer) {
// 处理整数
} else if (obj instanceof Double) {
// 处理浮点数
}

我们实际上是在告诉编译器:“相信我,我会处理所有可能的情况”。但如果新增了一种类型,编译器无法提醒我们更新这个逻辑。这就是不完备性+完备性带来的风险。

这个问题可以更精确地放在表达式问题(Expression Problem)的框架中来理解。表达式问题描述的是在编程语言中,如何既容易地扩展新的数据类型,又容易地扩展新的操作:

  • 面向对象的名义子类型(nominal subtyping):易于为”新增类型”扩展开放,却对”新增操作”扩展不友好
  • 代数数据类型(sum type):恰好相反,易于扩展新操作,但对新增类型不够友好

当我们使用instanceof链式分支时,实际上是在操作维度上进行扩展,但这种扩展无法在新增类型变体时触发编译器提示,这正是表达式问题中”新增类型”困难的典型体现。

我想把问题先压回到一个很具体的形式:什么时候应该把运行时类型判断,改成一种编译器能够检查的类型结构?

这个问题会以很多形式出现。Java 的接口把行为交给对象。C++ 的模板和 concepts 把约束推到编译期。Kotlin 的 sealed hierarchy 和 TypeScript 的 discriminated union 让变体对类型检查器可见。Haskell 的 algebraic data type 则直接把数据形状写进类型里。语法不同,但背后的压力相同:如何描述数据的形状和行为,让工具能够帮助人类构建可靠系统?

抽象的本质动机:从具体到一般

起点其实很直接:为什么我们需要抽象?

现实原因是复杂性。同一个问题往往有多种实现方式,而抽象可以把契约和实现拆开:

  1. 隐藏实现细节 - 使用者只需要关心”能做什么”,而不是”怎么做”
  2. 统一操作接口 - 不同的实现可以通过相同的接口被访问
  3. 便于替换和扩展 - 可以在不影响使用者的情况下更换实现

回到开头的instanceof问题,目标是将运行时的类型判断转换为编译时的类型保证。一个小的 shape 例子可以把这个取舍讲清楚。

形状处理的抽象

假设我们要处理不同形状的面积计算,没有抽象的情况下可能会这样写:

def calculate_area(shape):
if isinstance(shape, Circle):
return 3.14159 * shape.radius ** 2
elif isinstance(shape, Rectangle):
return shape.width * shape.height
elif isinstance(shape, Triangle):
return 0.5 * shape.base * shape.height
# 如果新增了Square类型,这里很容易遗漏!

这种代码的问题很明显:

  • 每新增一种形状,都要修改这个函数
  • 编译器无法检查是否处理了所有情况
  • 违反了”开闭原则(OCP)“(对扩展开放,对修改封闭)

抽象的解决方案

通过抽象,我们可以将这个运行时判断转换为编译时保证:

from abc import ABC, abstractmethod
class Shape(ABC):
@abstractmethod
def area(self) -> float:
pass
class Circle(Shape):
def __init__(self, radius: float):
self.radius = radius
def area(self) -> float:
return 3.14159 * self.radius ** 2
class Rectangle(Shape):
def __init__(self, width: float, height: float):
self.width = width
self.height = height
def area(self) -> float:
return self.width * self.height
# 现在可以统一处理所有形状,不需要instanceof
def calculate_total_area(shapes: list[Shape]) -> float:
return sum(shape.area() for shape in shapes)

抽象的价值

这个小例子说明了为什么这一步有用:

  1. 编译时保证 - 每个形状都必须实现area()方法,编译器会检查
  2. 扩展友好 - 新增形状只需要添加新类,不需要修改现有代码
  3. 运行时安全 - 不再担心遗漏某种情况的处理
  4. 代码清晰 - 每个类的职责明确,符合单一职责原则

这里的转变是:从“如果它是 X,就做 Y”的运行时判断,转向“X 知道如何做 Y”的编译期契约。它减少了一类容易遗漏的分支,也让职责更清楚。

后面的内容会比较几种语言如何完成这一步:Java interface、C++ template 和 concept、Kotlin sealed class、TypeScript discriminated union,以及 Haskell ADT。

为什么要关心类型抽象

讨论具体语言之前,可以先把数据抽象的两个目标写清楚:

  1. 封装不变量 —— 让编译器帮助我们阻止无效状态的出现
  2. 可组合性 —— 让不同模块和团队能够在不绑定具体实现的情况下交换数据

虽然语法会因语言流派而不同,但背后的动机始终相近。下面对比这些目标在 Java、C++、Kotlin、TypeScript 和 Haskell 中的具体体现。

Java 的接口与泛型:以行为为核心

Java 提供了一个很适合入门的版本:interface 和 generic 把一部分 instanceof 问题移动到了行为契约和参数化类型里。

由于Java的类继承和抽象类的使用和之前的Python例子比较类似,这里我们不具体举例了。我们直接从Java的接口和泛型说起。

Java 早期主要采用 接口 来实现抽象。接口描述了一组行为契约,让类可以承诺自己实现了某些方法。这对依赖反转和模块化设计很有帮助,但对数据具体实现的关注相对较少。

接口的本质:行为的多态

接口在 Java 中不只是方法列表,它表达的是一组可替换的行为。下面是一个更完整的例子:

// 定义一个支付处理器的接口
interface PaymentProcessor {
boolean processPayment(Payment payment);
void refundPayment(String transactionId);
PaymentStatus getPaymentStatus(String transactionId);
}
// 不同的实现方式
class CreditCardProcessor implements PaymentProcessor {
public boolean processPayment(Payment payment) {
// 信用卡支付逻辑
return validateCard(payment) && chargeCard(payment);
}
public void refundPayment(String transactionId) {
// 信用卡退款逻辑
refundToCard(transactionId);
}
public PaymentStatus getPaymentStatus(String transactionId) {
// 查询信用卡支付状态
return queryCardStatus(transactionId);
}
}
class PayPalProcessor implements PaymentProcessor {
public boolean processPayment(Payment payment) {
// PayPal支付逻辑
return authenticateWithPayPal(payment) && executePayment(payment);
}
public void refundPayment(String transactionId) {
// PayPal退款逻辑
refundViaPayPal(transactionId);
}
public PaymentStatus getPaymentStatus(String transactionId) {
// 查询PayPal支付状态
return queryPayPalStatus(transactionId);
}
}
// 使用接口的代码,不关心具体实现
class PaymentService {
private PaymentProcessor processor;
public PaymentService(PaymentProcessor processor) {
this.processor = processor; // 依赖注入
}
public boolean handlePayment(Payment payment) {
return processor.processPayment(payment);
}
}

这个例子展示了接口的几个重要特点:

  1. 行为统一:所有支付处理器都有相同的方法签名
  2. 实现多样性:不同的支付方式有不同的内部实现
  3. 解耦合:PaymentService只依赖接口,不依赖具体实现
  4. 易于测试:可以mock PaymentProcessor来测试PaymentService
interface Renderer {
void render(Document doc);
}
class HtmlRenderer implements Renderer {
public void render(Document doc) { /* ... */ }
}

接口方便我们替换不同的实现,但并没有直接说明 Document 到底包含什么。随着系统规模不断扩大,Java 5 引入了 泛型 来提供编译期的类型参数:

泛型可以简单描述为类型的类型,它让我们可以把不同的类型参数化到同一个接口上:

interface Repository<T> {
void save(T entity);
Optional<T> findById(UUID id);
}

在这个代码中,Repository<T> 抽象了对某种实体类型 T,并且直接告诉编译器,在检查时,save 方法只能接受 T 类型的参数,而 findById 方法返回的 Optional 也只能包含 T 类型的值。这让我们可以编写更通用的代码,而不需要为每种实体类型都写一个新的接口。

泛型带来了更强的静态类型保证,编译器能够确认仓库只处理一致的实体类型。但 Java 泛型具有 名义类型类型擦除的特点:

  • 类型擦除是 Java 泛型的本质,这影响了运行期具体化(reification)与某些专门化优化
  • 引用类型参数通常并不”自动”带来开销
  • 原生类型(primitive)参数,由于不能作为类型实参,才会引入装箱/拆箱与潜在的逃逸、分配成本
  • 同时 JIT 内联有时能抹平虚调用开销

尽管如此,接口与泛型的组合仍然是行为与具体类解耦的重要一步,同时也保留了单继承的对象模型。

C++ 模板:以代码生成作为抽象

如果说Java选择了在运行时通过接口实现多态,那么C++则选择了一条完全不同的道路 —— 将类型检查的工作提前到编译期。这种思路直接挑战了我们对”抽象”的传统理解,提供了解决instanceof问题的全新视角。

C++ 模板是一种编译期元编程机制,它把类型当作编译期的值来处理,并为每次实例化生成新的代码。

函数模板:编译期多态

先从一个简单的函数模板开始:

template <typename T>
T clamp(T value, T min, T max) {
if (value < min) return min;
if (value > max) return max;
return value;
}
// 使用示例
int x = clamp(42, 0, 100); // T = int
double y = clamp(3.14, 0.0, 1.0); // T = double

这个例子展示了模板的基本用法,但 C++ 模板更有意思的部分在于编译期计算类型特化

// 编译期计算:模板元编程
template <int N>
struct Factorial {
static constexpr int value = N * Factorial<N - 1>::value;
};
template <>
struct Factorial<0> {
static constexpr int value = 1;
};
// 使用:Factorial<5>::value 在编译时计算为 120

类模板:类型生成器

C++的类模板可以作为类型生成器,这与Java的泛型类有很大不同:

template <typename T>
class Vector {
private:
T* data;
size_t size;
size_t capacity;
public:
Vector() : data(nullptr), size(0), capacity(0) {}
void push_back(const T& value) {
if (size >= capacity) {
resize(capacity == 0 ? 1 : capacity * 2);
}
data[size++] = value;
}
T& operator[](size_t index) { return data[index]; }
const T& operator[](size_t index) const { return data[index]; }
size_t getSize() const { return size; }
private:
void resize(size_t new_capacity) {
T* new_data = new T[new_capacity];
for (size_t i = 0; i < size; ++i) {
new_data[i] = data[i];
}
delete[] data;
data = new_data;
capacity = new_capacity;
}
};
// 不同的T生成完全不同的类
Vector<int> intVector; // 生成 Vector<int>
Vector<std::string> strVector; // 生成 Vector<std::string>

模板特化:条件行为

C++ 模板支持特化,可以为特定类型提供特殊实现:

template <typename T>
class StringConverter {
public:
static std::string toString(const T& value) {
return std::to_string(value);
}
};
// 为std::string特化
template <>
class StringConverter<std::string> {
public:
static std::string toString(const std::string& value) {
return value;
}
};
// 为指针特化
template <typename T>
class StringConverter<T*> {
public:
static std::string toString(T* ptr) {
return ptr ? "0x" + std::to_string(reinterpret_cast<uintptr_t>(ptr)) : "nullptr";
}
};

现代C++:Concepts

C++20引入了Concepts,让模板约束更加清晰和简洁:

template <typename T>
concept Numeric = std::is_integral_v<T> || std::is_floating_point_v<T>;
template <Numeric T>
T add(T a, T b) {
return a + b;
}
// 使用
add(3, 4); // 正确:int是Numeric
add(3.5, 2.1); // 正确:double是Numeric
add("hello", "world"); // 错误:string不是Numeric

与Java泛型的根本区别

C++模板和Java泛型有本质区别:

  1. 编译期vs运行期:C++模板在编译期生成代码,Java泛型在运行期擦除
  2. 类型保留:C++保留完整的类型信息,Java会擦除类型参数
  3. 性能:C++模板追求”零成本抽象(zero-overhead abstraction)“,但需要注意代码膨胀(code bloat)与编译时间、错误信息复杂度的代价。这与更长的编译时间和更复杂的错误信息是一致的,需要在”目标与代价”之间找到平衡。
  4. 表现力:C++模板支持编译期计算和元编程,Java泛型主要用于类型安全

C++ 模板把抽象和优化都推到编译期,代价是更长的编译时间和更复杂的错误信息。这不是 Java 泛型能够直接复制的模型。

模板强调的主题在后文中会反复出现:抽象不仅关乎对象接口,更关乎操作一族相互关联的类型。

Java接口 vs C++概念:两种不同的抽象哲学

Java 的接口和 C++ 的抽象机制代表两种不同的设计取向。可以通过一个具体例子看出差异。

Java接口:显式的行为契约

Java的接口是一种显式的行为契约,所有实现都必须明确声明:

// Java的Comparator接口
public interface Comparator<T> {
int compare(T o1, T o2);
boolean equals(Object obj);
// 默认方法(Java 8+)
default Comparator<T> reversed() {
return Collections.reverseOrder(this);
}
default Comparator<T> thenComparing(Comparator<? super T> other) {
return (c1, c2) -> {
int res = compare(c1, c2);
return (res != 0) ? res : other.compare(c1, c2);
};
}
}
// 具体实现
class StudentComparator implements Comparator<Student> {
@Override
public int compare(Student s1, Student s2) {
return Integer.compare(s1.getGrade(), s2.getGrade());
}
}
// 使用
List<Student> students = ...;
students.sort(new StudentComparator());

C++概念:基于编译期约束的抽象

C++没有真正的接口概念,但可以通过抽象基类Concepts来实现类似的功能:

// C++传统方式:抽象基类
template <typename T>
class Comparator {
public:
virtual ~Comparator() = default;
virtual int compare(const T& a, const T& b) const = 0;
};
class StudentComparator : public Comparator<Student> {
public:
int compare(const Student& a, const Student& b) const override {
return a.getGrade() < b.getGrade() ? -1 :
a.getGrade() > b.getGrade() ? 1 : 0;
}
};
// 现代C++:Concepts(C++20)
template <typename T>
concept Comparable = requires(const T& a, const T& b) {
{ a < b } -> std::convertible_to<bool>;
{ a > b } -> std::convertible_to<bool>;
{ a == b } -> std::convertible_to<bool>;
};
// 基于Concepts的排序函数
template <typename T, typename Comp>
requires requires(const Comp& comp, const T& a, const T& b) {
{ comp(a, b) } -> std::convertible_to<int>;
}
void sort(T begin, T end, Comp comparator) {
// 实现排序逻辑
}

实际对比:Equality概念

下面用稍微复杂一点的 Equality 概念来对比两种语言:

Java的Equality抽象

// Java函数式接口
@FunctionalInterface
public interface EqualityChecker<T> {
boolean areEqual(T a, T b);
// 组合操作
default EqualityChecker<T> and(EqualityChecker<? super T> other) {
return (a, b) -> areEqual(a, b) && other.areEqual(a, b);
}
default EqualityChecker<T> or(EqualityChecker<? super T> other) {
return (a, b) -> areEqual(a, b) || other.areEqual(a, b);
}
default EqualityChecker<T> negate() {
return (a, b) -> !areEqual(a, b);
}
}
// 使用示例
class Person {
private String name;
private int age;
// 静态工厂方法
public static EqualityChecker<Person> byName() {
return (p1, p2) -> p1.name.equals(p2.name);
}
public static EqualityChecker<Person> byAge() {
return (p1, p2) -> p1.age == p2.age;
}
public static EqualityChecker<Person> byNameAndAge() {
return byName().and(byAge());
}
}

C++的Equality抽象

// C++传统方式:函数对象
template <typename T>
struct EqualityChecker {
virtual bool operator()(const T& a, const T& b) const = 0;
virtual ~EqualityChecker() = default;
};
// 具体实现
struct PersonNameEquality : EqualityChecker<Person> {
bool operator()(const Person& a, const Person& b) const override {
return a.getName() == b.getName();
}
};
// 现代C++:lambda和Concepts
template <typename T>
concept EqualityCheckable = requires(const T& a, const T& b) {
{ a == b } -> std::convertible_to<bool>;
};
// 组合操作的实现
template <typename T, typename F1, typename F2>
class AndEquality : public EqualityChecker<T> {
F1 f1;
F2 f2;
public:
AndEquality(F1 f1, F2 f2) : f1(f1), f2(f2) {}
bool operator()(const T& a, const T& b) const override {
return f1(a, b) && f2(a, b);
}
};
// 工厂函数
template <typename T, typename F1, typename F2>
auto make_and_equality(F1 f1, F2 f2) {
return AndEquality<T, F1, F2>(f1, f2);
}
// 使用lambda的现代化方式
auto personByNameEquality = [](const Person& a, const Person& b) {
return a.getName() == b.getName();
};
auto personByAgeEquality = [](const Person& a, const Person& b) {
return a.getAge() == b.getAge();
};
auto personByNameAndAge = make_and_equality<Person>(
personByNameEquality, personByAgeEquality
);

核心差异对比

  1. 类型系统差异

    • Java:运行时类型擦除,基于继承的多态
    • C++:编译期类型保留,基于模板的多态
  2. 内存和性能

    • Java:虚函数调用,有运行时开销
    • C++:模板实例化,编译期优化,零运行时开销
  3. 灵活性

    • Java:接口单一继承,但支持default方法
    • C++:多重继承,模板特化,Concepts约束
  4. 错误处理

    • Java:编译时检查+运行时异常
    • C++:主要是编译时错误(模板错误信息复杂)
  5. 学习曲线

    • Java:简单直观,容易上手
    • C++:概念复杂,需要深入理解模板元编程

实际应用建议

选择Java接口的情况

  • 需要运行时多态
  • 团队技能水平参差不齐
  • 需要简单明确的契约
  • 依赖注入和框架集成

选择C++抽象的情况

  • 性能要求极高
  • 需要编译期优化
  • 复杂的类型操作和元编程
  • 需要零开销抽象

这两种不同的抽象哲学各有优劣,选择哪种取决于具体的应用场景和团队需求。

Kotlin 与现代 Java 的密封层级:限制扩展

当面向对象语言逐渐成熟,开发者希望编译器能理解某个类型层级是否”完备”。这便引出了 Kotlin 的 密封类 与 Java 17 之后的 密封接口。密封层级声明只有固定子类可以实现该契约,且通常必须位于同一编译单元内:

为了使”完备性检查(exhaustiveness)“的论证更扎实,需要提到 Java 21 已将 switch 的模式匹配(pattern matching for switch)定稿(JEP 441),与 JEP 409(sealed classes)联用即可在 switch 处获得编译期的穷尽性校验。这能把”避免 instanceof”从理念落到语言机制:

Kotlin

import java.math.BigDecimal
sealed interface PaymentCommand {
val amount: BigDecimal
}
data class Charge(
override val amount: BigDecimal,
val cardToken: String
) : PaymentCommand
object RefundAll : PaymentCommand {
override val amount = BigDecimal.ZERO
}
fun PaymentCommand.describe(): String = when (this) {
is Charge -> "Charge ${amount} to card ${cardToken}"
RefundAll -> "Refund all remaining balance"
}
// 使用示例
fun processCommands(commands: List<PaymentCommand>) {
commands.forEach { command ->
println(command.describe())
}
}

Java

import java.math.BigDecimal;
public sealed interface PaymentCommand {
BigDecimal amount();
// 处理方法
default String describe() {
return switch (this) {
case Charge charge ->
"Charge " + charge.amount() + " to card " + charge.cardToken();
case RefundAll refundAll ->
"Refund all remaining balance";
};
}
}
// 实现类必须在同一个文件中嵌套声明
public record Charge(BigDecimal amount, String cardToken)
implements PaymentCommand {}
public final class RefundAll implements PaymentCommand {
private static final RefundAll INSTANCE = new RefundAll();
private RefundAll() {}
public static RefundAll getInstance() {
return INSTANCE;
}
@Override
public BigDecimal amount() {
return BigDecimal.ZERO;
}
}
// 使用示例
public class PaymentProcessor {
public void processCommands(List<PaymentCommand> commands) {
commands.forEach(command -> {
System.out.println(command.describe());
});
}
}

通过密封,Kotlin(以及现代 Java)可以提供穷尽性的 when/switch 检查。由于编译器了解所有子类型,不再需要 else 分支。密封机制因此在开放接口设计与我们稍后在代数数据类型中看到的封闭世界保证之间取得平衡。

TypeScript:自给自足的结构化类型系统

TypeScript 生于 JavaScript 的动态生态,它拥抱 结构类型:兼容性取决于对象的形状,而非声明的名称。我们可以通过几个例子看清它的抽象能力。

结构类型与接口

TypeScript的结构类型系统让”鸭子类型”[+鸭子类型]变得类型安全: [+鸭子类型]: 鸭子类型(Duck Typing)是一种动态类型系统的概念,指的是一个对象的适用性取决于它是否具有某些方法和属性,而不是它的具体类型。在TypeScript中,结构类型系统允许我们根据对象的形状来进行类型检查,而不是依赖于显式的类型声明。这使得代码更加灵活和可组合。

// 定义形状,不关心具体类型
interface Point2D {
x: number;
y: number;
}
interface Point3D {
x: number;
y: number;
z: number;
}
// 任何具有x和y属性的对象都可以
function distance(p1: Point2D, p2: Point2D): number {
return Math.sqrt((p1.x - p2.x) ** 2 + (p1.y - p2.y) ** 2);
}
// 结构类型让Point3D自动兼容Point2D
const point3d: Point3D = { x: 1, y: 2, z: 3 };
const point2d: Point2D = { x: 4, y: 5 };
console.log(distance(point3d, point2d)); // 完全合法!

判别联合类型:TypeScript的ADT

TypeScript的判别联合类型提供了类似代数数据类型的能力:

// 支付命令的判别联合
type PaymentCommand =
| { kind: "charge"; amount: number; cardToken: string }
| { kind: "refund"; transactionId: string; amount: number }
| { kind: "query"; transactionId: string };
// 穷尽性检查的类型安全处理
function processPayment(command: PaymentCommand): string {
switch (command.kind) {
case "charge":
return `Charging $${command.amount} to card ${command.cardToken}`;
case "refund":
return `Refunding $${command.amount} for transaction ${command.transactionId}`;
case "query":
return `Querying status for transaction ${command.transactionId}`;
default:
// TypeScript会确保这里永远执行不到
const _exhaustiveCheck: never = command;
return _exhaustiveCheck;
}
}

映射类型与条件类型

TypeScript的类型操作能力让它成为真正的”类型计算器”:

// 映射类型:基于现有类型创建新类型
type Optional<T> = {
[P in keyof T]?: T[P];
};
type ReadOnly<T> = {
readonly [P in keyof T]: T[P];
};
interface User {
id: number;
name: string;
email: string;
}
type OptionalUser = Optional<User]; // 所有属性都变为可选
type ReadOnlyUser = ReadOnly<User>; // 所有属性都变为只读

控制流分析与类型收窄

TypeScript的智能类型收窄让运行时检查更安全:

// 类型保护函数
function isString(value: unknown): value is string {
return typeof value === "string";
}
function processValue(value: unknown) {
if (isString(value)) {
// TypeScript知道这里是string类型
console.log(value.toUpperCase());
}
// typeof收窄
if (typeof value === "number") {
console.log(value.toFixed(2));
}
// 实例收窄
if (value instanceof Date) {
console.log(value.toISOString());
}
}
// 字面量类型收窄
type Status = "pending" | "processing" | "completed" | "failed";
function updateStatus(status: Status) {
if (status === "completed") {
// 只有"completed"能进入这个分支
console.log("任务已完成!");
}
}

泛型与约束

TypeScript 的泛型系统也能表达相当多的约束:

// 带约束的泛型
interface Identifiable {
id: string;
}
function findById<T extends Identifiable>(
items: T[],
id: string
): T | undefined {
return items.find(item => item.id === id);
}
// 泛型默认值
interface Repository<T = any> {
findById(id: string): Promise<T>;
save(entity: T): Promise<void>;
delete(id: string): Promise<boolean>;
}
// 键of泛型
function getProperty<T, K extends keyof T>(obj: T, key: K): T[K] {
return obj[key];
}
const user = { id: "1", name: "张三", age: 25 };
const userName = getProperty(user, "name"); // 类型为string
const userAge = getProperty(user, "age"); // 类型为number

得益于语言服务器一体化的类型系统,TypeScript 构建出 自给自足的开发体验:编译器、工具链与生态约定在混合 JavaScript、服务端框架、UI 库的代码库中也能强化一致的数据建模。

穷尽性检查模式

TypeScript 通过判别字段与 never 类型回退,可以实现”漏分支即编译错误”的穷尽性检查:

// 利用判别字段与 never 回退实现穷尽性检查
type PaymentCommand =
| { kind: "charge"; amount: number; cardToken: string }
| { kind: "refund"; transactionId: string; amount: number }
| { kind: "query"; transactionId: string };
function assertNever(x: never): never {
throw new Error("Unexpected object: " + x);
}
function processPayment(command: PaymentCommand): string {
switch (command.kind) {
case "charge":
return `Charging $${command.amount} to card ${command.cardToken}`;
case "refund":
return `Refunding $${command.amount} for transaction ${command.transactionId}`;
case "query":
return `Querying status for transaction ${command.transactionId}`;
default:
// 如果遗漏了某个 kind,TypeScript 会报错:
// Type 'string' is not assignable to type 'never'
return assertNever(command);
}
}

这种方式在编译时就能确保所有可能的情况都被处理,是 TypeScript 中解决 instanceof 问题的有效方案。

Haskell:代数数据类型与类型类

函数式传统把数据抽象推向一个更显式的方向:代数数据类型(ADT)类型类。Haskell 是观察这种抽象方式的好例子。

代数数据类型:数据的代数表达

Haskell的ADT以声明式方式组合直积(“与”)与直和(“或”):

-- 定义基础类型
type Money = Double
type Text = String
-- 支付命令:和类型(OR关系)
data PaymentCommand
= Charge { amount :: Money, cardToken :: Text }
| Refund { transactionId :: Text, amount :: Money }
| Query { transactionId :: Text }
| RefundAll
deriving (Show, Eq)
-- 用户:积类型(AND关系)
data User = User
{ userId :: Int
, userName :: Text
, userEmail :: Text
, userAge :: Int
, isActive :: Bool
} deriving (Show, Eq)
-- 递归数据类型:二叉树
data BinaryTree a
= Leaf
| Node (BinaryTree a) a (BinaryTree a)
deriving (Show, Eq, Functor)

模式匹配:穷尽性保证

Haskell的模式匹配默认要求穷尽,让编译器帮你检查所有可能的情况:

-- 处理支付命令,编译器会确保处理所有情况
processPayment :: PaymentCommand -> Text
processPayment (Charge amount cardToken) =
"Charging " ++ show amount ++ " to card " ++ cardToken
processPayment (Refund transactionId amount) =
"Refunding " ++ show amount ++ " for transaction " ++ transactionId
processPayment (Query transactionId) =
"Querying status for transaction " ++ transactionId
processPayment RefundAll =
"Refund all remaining balance"
-- 使用模式匹配处理递归数据类型
treeSum :: Num a => BinaryTree a -> a
treeSum Leaf = 0
treeSum (Node left value right) = treeSum left + value + treeSum right
-- 复杂的模式匹配
validateCommand :: PaymentCommand -> Either Text PaymentCommand
validateCommand cmd@(Charge amount _)
| amount <= 0 = Left "Charge amount must be positive"
| otherwise = Right cmd
validateCommand cmd@(Refund _ amount)
| amount < 0 = Left "Refund amount cannot be negative"
| otherwise = Right cmd
validateCommand cmd = Right cmd

类型类:行为的抽象接口

Haskell的类型类捕捉适用于多种类型的行为,同时保持实现彼此独立:

-- 基础类型类:可比较
class Comparable a where
compare :: a -> a -> Ordering
(<), (>), (<=), (>=) :: a -> a -> Bool
-- 默认实现
x < y = compare x y == LT
x > y = compare x y == GT
x <= y = compare x y /= GT
x >= y = compare x y /= LT
-- 为Int实例化
instance Comparable Int where
compare x y | x == y = EQ
| x < y = LT
| otherwise = GT
-- 半群:结合性操作
class Semigroup a where
(<>) :: a -> a -> a
-- 幺半群:带有单位元的半群
class Semigroup a => Monoid a where
mempty :: a
mappend :: a -> a -> a
mappend = (<>)
-- 列表的幺半群实例
instance Semigroup [a] where
(<>) = (++)
instance Monoid [a] where
mempty = []
-- 数字的乘法幺半群
newtype Product a = Product { getProduct :: a }
deriving (Show, Eq)
instance Num a => Semigroup (Product a) where
(Product x) <> (Product y) = Product (x * y)
instance Num a => Monoid (Product a) where
mempty = Product 1

实际应用:简单的验证示例

-- 简单的验证类型类
class Validatable a where
validate :: a -> Either Text a
-- 为PaymentCommand添加验证
instance Validatable PaymentCommand where
validate (Charge amount _)
| amount <= 0 = Left "Charge amount must be positive"
| otherwise = Right (Charge amount _)
validate (Refund _ amount)
| amount < 0 = Left "Refund amount cannot be negative"
| otherwise = Right (Refund _ amount)
validate cmd = Right cmd
-- 使用验证
processValidatedCommand :: PaymentCommand -> Either Text Text
processValidatedCommand cmd = do
validatedCmd <- validate cmd
return $ processPayment validatedCmd

Haskell 的类型类实现了临时多态(ad-hoc polymorphism),同时保留类型推导与高效编译。在高阶类型的加持下,它们能表达 Applicative、Lens 等抽象;在类型系统较弱的语言中,同类写法往往更冗长,也更依赖约定。ADT 从构造层面让非法状态无法表示,这也是 Haskell 类型系统很值得学习的一点。

深度对比:Java接口 vs Haskell代数数据类型

为了理解 Haskell 类型系统的表达方式,可以用一个具体例子对比 Java interface 和 Haskell ADT。

Java的Comparator接口:运行时多态

Java的Comparator接口是一个典型的运行时多态例子:

// Java Comparator:需要显式实现接口
public interface Comparator<T> {
int compare(T a, T b);
}
// 具体实现类
class StudentGradeComparator implements Comparator<Student> {
@Override
public int compare(Student a, Student b) {
return Integer.compare(a.getGrade(), b.getGrade());
}
}
class StudentNameComparator implements Comparator<Student> {
@Override
public int compare(Student a, Student b) {
return a.getName().compareTo(b.getName());
}
}
// 使用:运行时动态选择
Comparator<Student> comparator = getComparatorFromUser();
students.sort(comparator);

这种方式的特点:

  • 运行时多态:具体的比较逻辑在运行时确定
  • 显式实现:每个比较器都需要明确实现Comparator接口
  • 开放扩展:任何人都可以创建新的比较器
  • 类型擦除:运行时丢失泛型信息

Haskell的Ord类型类:编译时多态

Haskell通过类型类实现类似的功能,但编译期就能确定行为:

-- Haskell Ord类型类:编译期推导
class Ord a where
compare :: a -> a -> Ordering
(<), (<=), (>), (>=) :: a -> a -> Bool
-- 默认实现
x < y = compare x y == LT
x <= y = compare x y /= GT
x > y = compare x y == GT
x >= y = compare x y /= LT
-- 为Student类型实例化
data Student = Student
{ name :: String
, grade :: Int
} deriving (Show, Eq)
instance Ord Student where
compare (Student n1 g1) (Student n2 g2)
| g1 /= g2 = compare g1 g2
| otherwise = compare n1 n2
-- 使用:编译期就确定了比较行为
sortStudents :: [Student] -> [Student]
sortStudents = sort -- sort自动使用Ord实例

核心差异对比

  1. 多态机制

    • Java:运行时分派 - 通过虚函数表动态查找
    • Haskell:编译期特化 - 每个类型生成专门的比较函数
  2. 类型安全性

    • Java:运行时检查 - 可能抛出ClassCastException
    • Haskell:编译期保证 - 如果类型没有Ord实例,编译失败
  3. 性能特征

    • Java:虚函数调用开销 + 可能的装箱/拆箱
    • Haskell:静态调用 + 在常见优化下接近零成本(near zero-overhead under specialization)
  4. 表达力

    • Java:接口约束 - 只能定义方法签名
    • Haskell:类型类约束 - 可以有默认实现和关联类型

更复杂的例子:Equality vs Eq

再看一个稍复杂的例子,展示 Haskell 类型系统能表达什么:

Java的Equality检查

// Java:需要多个接口和实现
public interface EqualityChecker<T> {
boolean areEqual(T a, T b);
}
public interface HashProvider<T> {
int hashCode(T obj);
}
// 复合接口
public interface HashableEquality<T> extends EqualityChecker<T>, HashProvider<T> {}
// 具体实现
public class PersonHashableEquality implements HashableEquality<Person> {
@Override
public boolean areEqual(Person a, Person b) {
return a.getName().equals(b.getName()) &&
a.getAge() == b.getAge();
}
@Override
public int hashCode(Person obj) {
return Objects.hash(obj.getName(), obj.getAge());
}
}

Haskell的Eq类型类

-- Haskell:一个类型类解决所有问题
class Eq a where
(==) :: a -> a -> Bool
(/=) :: a -> a -> Bool
-- 默认实现
x == y = not (x /= y)
x /= y = not (x == y)
-- 自动推导Eq实例
data Person = Person
{ name :: String
, age :: Int
} deriving (Show, Eq)
-- Haskell可以自动生成:
-- 1. 两个Person的相等比较
-- 2. 基于字段的hashCode实现
-- 3. 编译期类型检查

Haskell类型系统的代价与收益

收益

  1. 编译时安全性

    -- 如果类型没有Eq实例,编译直接失败
    findDuplicates :: Eq a => [a] -> [a]
    findDuplicates xs = [x | x <- xs, count x xs > 1]
    -- 错误:No instance for (Eq SomeType)
    findDuplicates [someType1, someType2]
  2. 类型推导自动化

    -- 编译器自动推导出需要Ord约束
    sortStudents :: [Student] -> [Student]
    sortStudents = sort -- sort :: Ord a => [a] -> [a]
  3. 在常见优化下接近零成本

    -- GHC的SPECIALISE/INLINE优化下接近手写代码性能
    instance Ord Student where
    compare = compareStudents -- 内联优化
  4. 非法状态不可表示

    -- 编译期就能防止非法状态
    data PaymentStatus = Pending | Processing | Completed
    -- 不可能创建除这三种之外的状态

代价

  1. 学习曲线陡峭

    • 需要理解类型类、实例、约束等概念
    • 类型推导机制复杂
    • 错误信息抽象难懂
  2. 编译时间长

    • 复杂的类型推导需要大量计算
    • 编译期优化增加编译时间
  3. 运行时灵活性降低

    • 动态行为受限
    • 运行时反射能力有限
  4. 生态系统限制

    • 库的数量相对较少
    • 与主流OO框架集成困难

现实意义

Haskell的类型系统展示了编程语言设计的终极追求:将尽可能多的错误移到编译期。这种设计哲学在实践中意味着:

  • 减少测试负担:编译器已经排除了整类错误
  • 提升重构信心:类型系统保证修改的安全性
  • 文档即代码:类型签名就是最准确的文档
  • 性能优化:编译期信息支持深度优化

这种表达能力也有代价。Haskell 不适合所有场景,特别是需要快速迭代、运行时灵活性或团队技能多样化的项目。理解这种权衡,是选择技术栈时必须考虑的一部分。

instanceof 出发,每种抽象方式都在回答同一个问题:如何在保持灵活性的同时确保正确性? Haskell 给出了一个更偏形式化的答案,而这个答案是否值得采用,取决于具体需求和约束条件。

横向对比

特性 / 语言Java 接口与泛型C++ 模板Kotlin/Java 密封类型TypeScript 结构化类型系统Haskell ADT 与类型类
核心抽象名义类型上的行为契约面向类型的编译期代码生成受限扩展的闭合层级以联合类型、推断与工具整合为核心的结构类型数据与行为的代数式组合
可扩展性开放世界;任何类都可实现开放世界;随处可实例化仅限声明的子类开放世界;按形状兼容通过新增数据构造子扩展,但整体受限
运行时表示擦除泛型,单分派每次实例化都生成专门代码JVM 类及密封层级的元数据运行时擦除,但有控制流收窄辅助丰富的编译期信息,最终擦除至高效核心语言
安全保障行为契约;穷尽性有限取决于约束;可能出现不安全情况已知变体上的穷尽 when/switch收窄与联合类型捕获大量运行时错误模式匹配穷尽;非法状态不可表示
工具体验成熟 IDE 支持编译器强大但复杂Kotlin/Java IDE 强制密封规则语言服务器解释推断形状与判别联合编译器与 REPL 协助校验公理与实例

这张表说明,没有一种方式能在所有维度一枝独秀。演化的每一步都只是在开发者工具箱里增添新选择。

从instanceof到抽象:完整的思维转变

回到我们最初的问题:如何避免使用 instanceof?这个问题不是一个绕开扣分点的小技巧,而是一种设计习惯:把不确定的运行时分支,尽量移动到语言能够检查的结构里。

问题解决的演进路径

  1. 识别问题instanceof带来的不完备性和运行时风险
  2. 理解本质:需要将运行时类型判断转换为编译时类型保证
  3. 选择工具:根据语言特性和场景选择合适的抽象机制
  4. 实施解决方案
    • Java/Kotlin:使用接口、密封类、模式匹配
    • C++:利用模板、Concepts、编译期多态
    • TypeScript:采用结构类型、判别联合、类型收窄
    • Haskell:通过ADT、类型类、模式匹配

实际应用建议

对于初学者

  • 从Java接口开始,理解行为抽象的基本概念
  • 逐步探索密封类和模式匹配,看清编译期检查能捕捉什么
  • 尝试TypeScript的结构类型,感受”鸭子类型”的类型安全版本

对于有经验的开发者

  • 在多语言项目中,理解不同抽象风格的映射关系
  • 根据性能需求、团队技能、生态成熟度选择合适的技术栈
  • 建立统一的抽象思维,不被具体语法限制

对于系统设计者

  • 在架构层面考虑类型安全的传递
  • 利用强类型系统构建可靠的分布式系统
  • 在灵活性和安全性之间找到平衡点

结语:在数学、语言与计算的交汇处

重新整理这篇旧笔记时,我也意识到自己为什么还在意这个主题。数据类型抽象刚好处在一个有意思的边界上:编程语言提供机制,数学提供形式结构,而语言学不断追问一个符号到底在表达什么。

计算机科学的视角:抽象的层次性

从计算机科学的角度看,我们今天讨论的抽象本质上是一个层次化的问题。从机器码到汇编,从过程式编程到面向对象,再到函数式编程,每一步都是将底层的复杂性包装成更高级的抽象。

物理层 → 逻辑门 → 指令集 → 汇编语言 → 高级语言 → 抽象设计模式

类型系统是这套抽象结构中的一层。它让我们在编译期捕捉一部分错误,而不是等到程序在用户面前崩溃之后才发现问题。这首先是很实际的工程收益,同时也指向一种更偏科学的编程观:程序可以被显式结构检查,而不只是事后测试。

纯数学的视角:形式系统

作为一个喜欢数学的人,我经常会注意到类型系统和形式系统之间的相似性。Haskell 的类型类让我想到群、环、域这样的代数结构;代数数据类型里的”和”与”积”会对应到集合论里的不交并与笛卡尔积;类型推导也有一点像小型的证明搜索问题。

data PaymentCommand = Charge ... | Refund ... | Query ...
-- 这是一个和类型,对应数学中的不交并

Curry-Howard 同构给了一个很漂亮的说法:程序即证明,类型即命题。一个类型正确的函数,也可以被看成一个小证明:某些输入会被约束到某些输出。这种思想影响了很多现代编程语言设计。

语言学的视角:语义的精确表达

语言学教会我们关注表达的精确性。自然语言中的模糊性在编程中往往是错误的根源。当我们说”一个对象”时,我们到底指的是什么?是一个具体的实例,还是一个抽象的概念?

类型系统就像是一门精确的形式语言,它迫我们在编码之前就思考清楚:

  • 这个数据表示什么?
  • 它有哪些可能的取值?
  • 对它可以进行哪些操作?

这种精确性训练,让我在阅读和写作时也更加注重概念的准确性和逻辑的严密性。

跨学科的统一:抽象的本质

在这三个领域中,我看到了抽象的共同本质:

在数学中,我们通过公理和定义来抽象具体的数值关系,从而证明普遍适用的定理。

在语言学中,我们通过语法规则来抽象具体的表达方式,从而构建有意义的交流。

在计算机科学中,我们通过类型系统来抽象具体的数据操作,从而构建可靠的软件系统。

它们都在回答同一个根本问题:如何用有限的规则来表达无限的可能性?

我从这里带走的工作习惯

这里的收获不需要写成很大的“编程哲学”。对我来说,它更像几个想长期保留的习惯:

1. 当数学结构能澄清设计时,就把它说出来:理解类型系统背后的数学形状,可以帮助我们更好地选择抽象工具。如果一个 interface 实际上在编码某种代数结构,把这个结构命名出来会让设计更清楚。

2. 把编程语言当作思维工具:选择一种语言,也是在选择哪些结构更容易被看见,哪些错误更容易被写出来。

3. 让抽象贴近问题本身:抽象只有在帮助我们看清问题形状时才有意义。如果它只是制造术语,就反而会把问题藏起来。

对未来的思考

在这个边界上,有两个方向对我尤其相关:

  • 依赖类型:将数学证明直接融入编程语言,让程序正确性可以在编译期得到形式化验证
  • 自然语言处理:将类型系统的思想应用到自然语言的理解和生成中,构建更精确的人机交互

最后的思考

最初的问题很小:如何避免 instanceof

写完这些例子之后,我更在意的问题变成了:程序到底知道什么?这些知识应该放在哪里?有时它应该放在 interface 里,有时应该放在 sealed hierarchy、discriminated union、type class,甚至一个接近证明的 type signature 里。

这也是我还愿意保留这篇长文的原因。类型抽象刚好落在编程语言、数学和语言学的交界处:它问的是,有限的符号如何把巨大的意义空间描述得足够精确,以至于机器也能参与检查。