Book Image

Functional Kotlin

By : Mario Arias, Rivu Chakraborty
Book Image

Functional Kotlin

By: Mario Arias, Rivu Chakraborty

Overview of this book

Functional programming makes your application faster, improves performance, and increases your productivity. Kotlin supports many of the popular and advanced functional features of functional languages. This book will cover the A-Z of functional programming in Kotlin. This book bridges the language gap for Kotlin developers by showing you how to create and consume functional constructs in Kotlin. We also bridge the domain gap by showing how functional constructs can be applied in business scenarios. We’ll take you through lambdas, pattern matching, immutability, and help you develop a deep understanding of the concepts and practices of functional programming. If you want learn to address problems using Recursion, Koltin has support for it as well. You’ll also learn how to use the funKtionale library to perform currying and lazy programming and more. Finally, you’ll learn functional design patterns and techniques that will make you a better programmer.By the end of the book, you will be more confident in your functional programming skills and will be able to apply them while programming in Kotlin.
Table of Contents (22 chapters)
Title Page
Copyright and Credits
Dedication
Packt Upsell
Contributors
Preface
Index

What is immutability?


Functional programming, by its nature, is thread safe; immutability has a great role in making it thread safe. If you go by the dictionary definition, immutability means that something is unchangeable. So, as per the dictionary, an immutable variable is a variable that cannot change. Now, how can that be of any help to thread safety?

The following example shows a simple class, with no extra protective measures for thread safety:

class MutableObject { 
    var mutableProperty:Int = 1 
} 

Just think of a situation when you're calling this class from multiple threads at the same time. There is no guarantee of integrity in this, right?

Now, imagine making mutableProperty immutable; the problem is partly solved, right?

However, if you think of immutability as creating a class and making all its variables read-only, then such a simplified explanation would not only be wrong, but would also be horrible. Actually, immutability is not about forbidding change, but about handling change...