Functional (SAM) interfaces,
explained properly.

01The concept

A name for a very specific shape of interface.

An interface with exactly one abstract member function is called a functional interface, or a SAM interface — Single Abstract Method. It may carry any number of non-abstract members (functions with bodies), but only one method can be left abstract.

In Kotlin you opt in explicitly with the fun modifier on the interface declaration:

fun interface KRunnable {
    fun invoke()
}

That little fun is a contract with the compiler. It says: this interface will always have exactly one abstract method, so let callers implement it with a lambda. The compiler enforces the contract — add a second abstract method and the declaration stops compiling.

02Your first one, step by step

From a plain interface to a one-liner, in five moves.

interface IntPredicate {
    fun accept(i: Int): Boolean
}

// Creating an instance of a class
val isEven = object : IntPredicate {
    override fun accept(i: Int): Boolean {
        return i % 2 == 0
    }
}

fun interface IntPredicate {
    fun accept(i: Int): Boolean
}

// Creating an instance using a lambda
val isEven = IntPredicate { it % 2 == 0 }

fun main() {
    println("Is 7 even? - ${isEven.accept(7)}")
}

// Output:
// Is 7 even? - false

03SAM conversion, up close

What the compiler actually does when you hand it a lambda.

The one-liner in step 4 isn't magic syntax — it's a SAM conversion. When a lambda's signature matches the signature of a functional interface's single method, Kotlin converts the lambda into code that dynamically instantiates an implementation of that interface. Conceptually, you write the left tab and the compiler produces something equivalent to the right tab:

val isEven = IntPredicate { it % 2 == 0 }

val isEven = object : IntPredicate {
    override fun accept(i: Int): Boolean {
        return i % 2 == 0
    }
}

Two things follow from this mental model:

fun countMatching(numbers: List<Int>, predicate: IntPredicate): Int =
    numbers.count { predicate.accept(it) }

fun main() {
    val nums = listOf(1, 2, 3, 4, 5, 6)

    // bare lambda: converted implicitly because the parameter type is known
    println(countMatching(nums) { it % 2 == 0 })   // 3

    // works with function references too
    println(countMatching(nums, ::isPositive))        // 6
}

fun isPositive(i: Int): Boolean = i > 0

04Rules & gotchas

What the compiler will and won't let you get away with.

Exactly one abstract method — but non-abstract members are fine

"Functional" doesn't mean "single-member." The interface can carry helper functions with bodies; only the abstract count is restricted:

fun interface Validator {
    fun validate(input: String): Boolean          // the one abstract method

    fun validateOrThrow(input: String) {           // has a body — fine
        require(validate(input)) { "Invalid: $input" }
    }
}

Two abstract methods? Compile error.

fun interface Broken {
    fun first()
    fun second()   // error: fun interface must have exactly one abstract method
}

They're real types: extension and inheritance work

Because a functional interface creates a genuine new type, it can extend other interfaces and be the target of extension functions — capabilities you'll lean on in section 08.

05Java interop

You've been using SAM conversions all along.

SAM conversion also applies to Java interfaces with a single abstract method — no fun modifier needed, since Java interfaces can't opt in and Kotlin extends the courtesy automatically. Every time you've passed a lambda where a Java API wanted a Runnable or Comparator, this is what happened:

import java.util.concurrent.Executors

fun main() {
    val executor = Executors.newSingleThreadExecutor()

    // java.lang.Runnable is a SAM interface — lambda converts implicitly
    executor.submit { println("running on ${Thread.currentThread().name}") }

    // java.util.Comparator too
    val byLength = Comparator<String> { a, b -> a.length - b.length }
    println(listOf("kotlin", "jvm", "sam").sortedWith(byLength))

    executor.shutdown()
}

A useful bit of history: Kotlin supported SAM conversion for Java interfaces from the very beginning, but for Kotlin's own interfaces you must opt in with fun interface. The reason is that Kotlin already has first-class function types — the language wants you to be deliberate about choosing interface semantics over a plain (Int) -> Boolean.

06Migrating legacy patterns

Retiring the "interface + factory function" idiom without breaking callers.

Before fun interface existed, a common workaround was to pair a plain interface with a same-named factory function that accepted a lambda:

interface Printer {
    fun print()
}

fun Printer(block: () -> Unit): Printer = object : Printer {
    override fun print() = block()
}

fun interface Printer {
    fun print()
}

documentsStorage.addPrinter(::Printer)

@Deprecated(
    message = "Use the fun interface constructor instead",
    level = DeprecationLevel.HIDDEN
)
fun Printer(block: () -> Unit): Printer = Printer(block)

07Functional interfaces vs. type aliases

Same shape at the call site — completely different type semantics.

The IntPredicate example can be rewritten with a type alias for a functional type, and at a glance it looks almost identical:

fun interface IntPredicate {
    fun accept(i: Int): Boolean
}

val isEven =
    IntPredicate { it % 2 == 0 }

// invoked via the method name
isEven.accept(7)

typealias IntPredicate =
    (i: Int) -> Boolean

val isEven: IntPredicate =
    { it % 2 == 0 }

// invoked directly
isEven(7)

The difference is in what exists afterward. A type alias is just a name for an existing type — IntPredicate and (Int) -> Boolean are the same type, fully interchangeable. A functional interface creates a new nominal type, and that buys real capabilities:

The decision, in two questions

08Patterns in practice

Where fun interfaces earn their keep in real codebases.

Pattern 1 — Pluggable strategies with lambda-friendly call sites

A functional interface gives the dependency a domain name and a documented contract, while callers still get to pass a one-line lambda:

fun interface RetryPolicy {
    /** Returns the delay in ms before [attempt], or null to stop retrying. */
    fun delayFor(attempt: Int): Long?
}

class WebhookDispatcher(private val retryPolicy: RetryPolicy) {
    // ... uses retryPolicy.delayFor(attempt) between deliveries
}

// Call sites read like configuration:
val dispatcher = WebhookDispatcher { attempt ->
    if (attempt <= 5) 1000L * (1 shl attempt) else null   // exponential backoff, 5 tries
}

Pattern 2 — Composition through extension functions

This is the capability a type alias can't give you: extensions scoped to this interface, not to every (String) -> Boolean in the program:

fun interface Validator {
    fun validate(input: String): Boolean
}

// Extensions specific to Validator — impossible on a bare function type
infix fun Validator.and(other: Validator) =
    Validator { validate(it) && other.validate(it) }

infix fun Validator.or(other: Validator) =
    Validator { validate(it) || other.validate(it) }

fun main() {
    val notBlank  = Validator { it.isNotBlank() }
    val maxLength = Validator { it.length <= 64 }
    val looksLikeEmail = Validator { "@" in it }

    val emailField = notBlank and maxLength and looksLikeEmail

    println(emailField.validate("erick@example.com"))  // true
    println(emailField.validate(""))                    // false
}

Pattern 3 — A contract richer than a signature

When the single method carries non-trivial semantics — ordering guarantees, idempotency expectations, threading rules — the interface is the right home for that documentation. The signature (Event) -> Unit says nothing; EventHandler with a KDoc contract says everything:

fun interface EventHandler {
    /**
     * Handles a single event.
     *
     * Implementations MUST be idempotent: the same event may be
     * delivered more than once. Called from a single consumer
     * thread — no internal synchronization required.
     */
    fun handle(event: Event)
}