Kotlin 的 SAM 到底解决了什么？

前几天同事问我：Kotlin 里的 SAM 到底是什么？为什么有时候明明需要传一个接口，最后却可以直接塞一段 lambda 进去？

这个问题如果直接从 SAM 开始讲，很容易变成一句干巴巴的定义：SAM 是 Single Abstract Method，也就是只有一个抽象方法的接口。定义没错，但听完大概率还是不知道它为什么存在，也不知道 Kotlin 为什么能把一段 lambda 转成一个接口实现。

所以我当时的回答是：要把 SAM 讲明白，得先从 lambda 说起。

因为 SAM 转换真正解决的问题，并不是"接口怎么写"，而是"如何把一段行为更自然地传给另一个函数"。

Lambda 负责表达这段行为，SAM 接口负责承接这段行为，而 SAM 转换则是 Kotlin 帮我们把两者接起来的那一步。

下面我们就先从 lambda 表达式开始，再一步步看函数式接口和 SAM 转换到底在解决什么问题。

Lambda 表达式

Lambda 表达式写在花括号 {} 中，通常由参数列表（如果有参数）和 -> 组成，-> 用来把参数和函数体分开。

val greet = { name: String -> "Hello, $name" }
println(greet("skydoves")) // 输出：Hello, skydoves

在这个例子里，lambda 表达式 { name: String -> "Hello, $name" } 接收一个名为 name 的 String 参数，并返回一条问候消息。

简写语法

如果 lambda 只有一个参数，并且这个参数类型可以从上下文推断出来，Kotlin 会提供隐式的 it 关键字来表示这个参数，因此不必再显式声明它：

val square: (Int) -> Int = { it * it }
println(square(4)) // 输出：16

这里通过 (Int) -> Int 明确了函数类型，lambda 就可以使用 it 表示唯一参数，让代码更简洁。

与高阶函数配合使用

Lambda 表达式经常和高阶函数一起使用。高阶函数可以接收函数作为参数，也可以返回函数。

Kotlin 的集合函数，例如 filter、map 和 forEach，就经常使用 lambda：

val numbers = listOf(1, 2, 3, 4, 5)
val doubledNumbers = numbers.map { it * 2 }
println(doubledNumbers) // 输出：[2, 4, 6, 8, 10]

这里把 lambda { it * 2 } 传给 map 函数，用来把列表中的每个数字都翻倍。

捕获作用域中的变量

Lambda 表达式可以捕获周围作用域中的变量，因此能够维护状态，并与外层上下文交互：

var counter = 0
val increment = { counter++ }
increment()
increment()
println(counter) // 输出：2

Lambda { counter++ } 捕获了 counter 变量，并直接修改了它。

小结

Lambda 表达式灵活且实用，可以帮助我们写出简洁的函数式代码。它们支持内联定义行为，支持在单参数场景下使用 it 简写，也可以和外层作用域中的变量交互。

无论用于高阶函数、集合转换，还是事件处理，lambda 表达式都是编写整洁、富有表现力的 Kotlin 代码的基础特性。

好，Lambda 表达式很快讲完，现在，我们进入正题。

---

什么是函数式（SAM）接口

函数式接口，也叫单一抽象方法（Single Abstract Method，SAM）接口，指的是恰好只有一个抽象方法的接口。

这类接口用于表示一个单一操作或函数，因此它们是启用函数式编程构造、简化 lambda 表达式使用方式的重要特性。

在 Java 中，为了让语义更清晰，函数式接口可以使用 @FunctionalInterface 注解，不过这个注解并不是必需的。Kotlin 中则使用 fun interface 显式声明函数式接口。

可能好多后续转 Kotlin 的开发者，根本不知道有 @FunctionalInterface 这个注解。

函数式接口的关键特征是只包含一个抽象方法，因此我们可以用 lambda 表达式来实现它，而不必编写冗长的实现类。

fun interface Greeter {
    fun greet(name: String): String
}

val greeter = Greeter { name -> "Hello, $name from skydoves!" }
println(greeter.greet("Kotlin")) // 输出：Hello, Kotlin from skydoves!

在这个例子中，Greeter 函数式接口只定义了一个方法 greet。创建 Greeter 实例时，可以直接用 lambda 表达式提供实现。

SAM 转换

SAM（Single Abstract Method，单一抽象方法）转换是一种机制，它允许 Kotlin 把 lambda 表达式当作函数式接口的实现。

这个特性消除了样板代码，也能与 Java 函数式接口无缝集成，例如 java.util.function 包中的接口。

val runnable = Runnable { println("Running with SAM conversion in skydoves!") }
runnable.run() // 输出：Running with SAM conversion in skydoves!

这里，Java 的 Runnable 接口是一个函数式接口。

借助 Kotlin 的 SAM 转换，我们可以直接提供一个 lambda 表达式，而不需要创建显式的实现类。

函数式接口的关键特性

函数式接口可以让 Kotlin 代码更简洁、更具表现力，也更容易互操作，尤其适合与 lambda 表达式和 SAM 转换配合使用。

1. 对 lambda 友好：函数式接口允许使用 lambda 代替冗长的匿名类，从而简化代码。
2. 无缝互操作：Kotlin 的 SAM 转换既适用于 Kotlin 定义的函数式接口，也适用于 Java 定义的函数式接口，让跨平台集成函数式编程构造更容易。
3. 减少样板代码：把 lambda 表达式与函数式接口结合使用，可以写出更简洁、可读且易维护的代码。

小结

函数式（SAM）接口表示只有一个抽象方法的接口，因此可以用 lambda 表达式或方法引用来实现。

它们通过 SAM 转换增强了与 Java 函数式接口的互操作性，并减少了样板代码，是在 Kotlin 中采用函数式编程范式的实用工具。

无论是定义自定义函数式接口，还是使用已有接口，它们都能让代码更整洁、更具表现力。

进阶：转换的哲学

在编程语言设计中，特性很少凭空出现。它们往往是为了解决某个具体问题，或者为了缓和不同范式之间的摩擦。

单一抽象方法（SAM）转换就是这样的典型例子。它不只是一点语法糖，更体现了一门语言的设计哲学：相比严格的理念纯粹性，它更重视务实的互操作性和开发者体验。

SAM 转换背后的哲学，最初是对 Java 历史痛点的直接回应。在 Java 8 引入 lambda 之前，如果想把一种行为，也就是一段代码块，传给某个方法，唯一的方式就是实例化一个匿名内部类。

以 Java 中随处可见的 Runnable 接口为例：

// 一个只有单一抽象方法的简单 Java 接口。
public interface Runnable {
    void run();
}

如果要把一个简单的"打印"动作传给一个期望接收 Runnable 的方法，开发者必须写出大量样板代码：

// Java 8 之前的仪式性代码
executor.execute(new Runnable() {
    @Override
    public void run() {
        System.out.println("Task is running.");
    }
});

开发者的真实意图很简单："运行这一行代码。"

但由于语言坚持面向对象的纯粹性，他们必须通过类实例化和方法重写这一套仪式来表达这个意图。这样的冗长写法掩盖了核心逻辑，也曾是开发者经常遇到的摩擦来源。

设计哲学：函数是对象

SAM 转换的核心哲学是：一个只有单一抽象方法的接口，本质上就是一份函数签名契约。

Runnable 接口在结构上等价于一个不接收参数、也不返回任何内容的函数（在 Kotlin 中是 () -> Unit）。

像 Kotlin 这样拥抱函数式编程的语言，会把函数视为一等公民。函数可以像值一样被传递。

SAM 转换就是连接这两个世界的桥梁。它相当于语言设计者做出的一种务实声明：

"如果开发者提供了一个 lambda，并且它匹配某个单一抽象方法的签名，我们就理解他们的意图。我们会负责把他们轻量的函数式表达式转换成底层平台所期望的、较重的面向对象结构。"

这种哲学把开发者的意图放在平台的仪式之上。

Kotlin 的实现

Kotlin 设计之初的目标，是成为一门具备 100% 互操作性的"更好的 Java"。

这意味着它必须优雅地接入庞大的既有 Java 库生态，而这些库完全围绕 SAM 接口构建，例如 Runnable、Callable、Comparator，以及大量 Android 监听器（OnClickListener、OnLongClickListener 等）。

Kotlin 对 SAM 转换的实现，正是这种承诺的直接体现。

当 Kotlin 编译器看到一个 lambda 被传给某个期望 SAM 接口的 Java 方法时，它会自动把这段 lambda 适配成该接口的实现。

具体生成的 JVM 代码可能是匿名类，也可能使用 invokedynamic 等机制，取决于 Kotlin 版本和编译目标。

// 在 Kotlin 中，开发者表达的是他们简单的意图。
executor.execute { println("Task is running.") }

// Kotlin 编译器会生成或适配所需的 JVM 代码。
// 从概念上讲，它完成了旧式 Java 代码里手写实现类的工作。

这是一个非常务实的选择。编译器承担了转换负担，而不是让开发者处理现代函数式语言与遗留面向对象 API 之间的不匹配。

这样一来，Kotlin 代码可以保持整洁、符合惯用法并具备函数式风格，同时生成的字节码仍然能与 Java 世界完全兼容。

Java 中的演进

Java 8 最终也引入了自己的 lambda 表达式和方法引用，它们同样依赖 SAM 转换（在 Java 中使用"函数式接口"这个术语）。这验证了 SAM 转换背后的核心哲学。不过，Kotlin 的方式仍然有自己的特点，也依然重要。

在 Kotlin 中，你可以使用 fun 关键字定义自己的接口，显式地把它们标记为"函数式接口"。这会为你自己的 Kotlin 到 Kotlin API 启用 SAM 转换，让你能够设计既可以接收 lambda、又仍然由接口定义的 API。

fun interface ActionHandler {
    fun handleAction(action: String)
}

// 现在可以用 lambda 调用这个 API。
fun performAction(handler: ActionHandler) { /* ... */ }

performAction { action -> println("Handling: $action") }

这说明，这种哲学并不只关乎 Java 互操作性；它也关乎在 Kotlin 内部用一种符合惯用法的方式桥接不同范式。

总结

SAM 转换体现的是一种面向开发者的务实共情。它承认不同编程范式（面向对象与函数式）经常需要共存，尤其是在 JVM 这样成熟的生态系统中。

SAM 转换不会强迫开发者编写冗长、充满仪式感的代码来弥合差距，而是让编译器负责完成转换。

它优先考虑清晰地表达意图（传递一种行为），而不是严格拘泥于某一种范式的实现细节（实例化一个对象）。

通过自动把函数字面量（lambda）转换成满足接口契约的对象，SAM 转换成为一座重要而优雅的桥梁，让函数式世界与面向对象世界之间实现更整洁的代码、更好的可读性以及无缝互操作。