Functional (SAM) Interfaces

An introduction to functional interfaces, also call SAM interfaces, and an interesting view on why they exist.

— — — — — — — — — — — — — — —

THE CURRENT VERSION OF THIS ARTICLE IS PUBLISHED HERE.

— — — — — — — — — — — — — — —

Tags: #FYI++

This article is part of the Kotlin Primer, an opinionated guide to the Kotlin language, which is indented to help facilitate Kotlin adoption inside Java-centric organizations. It was originally written as an organizational learning resource for Etnetera a.s. and I would like to express my sincere gratitude for their support.

It is recommended to read the Introduction before moving on. Check out the Table of Contents for all articles.

An interface with only one abstract method is called a functional interface, or a Single Abstract Method (SAM) interface. The functional interface can have several non-abstract members but only one abstract member.

Interfaces such as this one are basically equivalent to lambda functions sharing the same signature as the abstract member. Kotlin allows this for interfaces marked with the fun keyword.

If you’re curious as to why the decision was made to make a special keyword necessary, and interesting view was given by Pavel Talanov in the corresponding issue:

SAM are mainly a convenient automatic wrapper for the code that you cannot change. If you’re designing an API in Kotlin you can (and should) make a choice: Is this entity just a function or a separate class that can evolve into something more complex.

In other words, communicate intent.

The same functionality is available by default when calling Java classes.

Go back to Inline (Value) Classes, jump to the Table of Contents, or continue to Extension Functions: Introduction.