Programmer Dictionary: Higher Order Function
In previous part we’ve discussed most important terms of Kotlin functional programming. In this part we are going to discuss very popular functional programming term: Higher order function. Here is a definition:
A higher order function is a function that takes a function as an argument, or returns a function.
Yes, it is possible in Kotlin ;)
Here is an example of higher order function that takes function as an argument:
fun sendData(data: Data, callback: ()->Unit) {
thread {
api.sendData(data)
callback()
}
}
Here is an example of higher order function that returns a function:
fun makeLogger(for: Any) = fun(e: Error) {
Log.e(for::class.simpleName, e.message ?: "Error", e)
}// Usage in MainActivity
val logger = makeLogger(this)
val error = Error("Simple error")
logger(error) // Logs: MainActivity: Simple error ...
Analogically we use term first order functions to reference function that doesn’t take a function as an argument or return a function as output.
Higher order functions are very important in Kotlin while their usage is an important improvement over older languages. Nearly all functions used to process collections are higher-order:
students.sortedBy { it.grade }
.take(10)
.map { it.name }
Kotlin stdlib includes also different extension higher order functions like let, run, apply, also, takeIf and takeUnless. Similarly, like collection processing functions, they are often used all around the projects.
Next thing to notice is that many important Kotlin features are included to support higher order functions:
- Inline functions (introduced to improve efficiency of higher order functions)
- Implicit name of the single parameter (rarely useful for defining functions as a value because type inference is not possible, but extremely useful in lambdas provided as arguments)
- Last lambda in the argument convention (another way to support passing functions as an argument)
Fact that such an important features exist to support higher order functions clearly shows how important they are. Let’s be honest, we are using them all around the Kotlin code and without them it would be impossible to implement DSL or stream processing. They are great and we love them ;)
Subject of higher order functions and their importance in Kotlin I deeply described in chapter 5 of Android Development with Kotlin.
This post is twelfth part of the Kotlin programmer dictionary. To stay up-to-date with new parts, just follow this medium or observe me on Twitter. In case you need some help, remember that I am open for consultation.
If you like it, remember to clap. Note that if you hold the clap button, you can leave more claps.
Here are other parts of the Kotlin programmer dictionary:
- Parameter vs Argument, Type parameter vs Type argument
- Statement vs Expression
- Function vs Method vs Procedure
- Property vs Field
- Class vs Type vs Object
- Object expression vs Object declaration
- Receiver
- Implicit receiver vs explicit receiver
- Extension receiver vs Dispatch receiver
- Receiver type vs Receiver object
- Function Type vs Function literal vs Lambda expression vs Anonymous function
- Function literal with receiver vs Function type with receiver
- Invariance vs Covariance vs Contravariance
- Event listener vs Event handler
- Delegation vs Composition