Forem: Mahdi Abolfazli

Kotlin in Action Summary - Part 3

Mahdi Abolfazli — Thu, 01 Sep 2022 12:16:23 +0000

This is part 3 of the series Kotlin in Action Summary. Here is the link to part 2 which we talked about chapter 3 of the book with the title "Defining and Calling Functions". As mentioned before, it is highly recommended to read the book first and consider this series as a refresher. We do NOT cover all the materials in the book. Let's start with part 3, chapter 4 of the book: "Classes, Objects and Interfaces"!

Interfaces
Open, Final and Abstract Modifiers
Visibility Modifiers
Inner and Nested Classes
Sealed Classes
Constructors and Properties
Universal Object Methods
Data Classes
Class Delegation
The object Keyword

Interfaces

pages 68, 69, 70

Kotlin's interfaces are similar to that of Java 8. They can contain abstract methods and implementation of non-abstract methods(like Java 8 default methods), but they cannot have any state!
This is how we declare and use interfaces in Kotlin:

interface Clickable {
    fun click()
    fun showOff() = println("Clickable showOff")
}

interface Focusable {
    fun setFocus(b: Boolean)
    fun showOff() = println("Focusable showOff")
}

class Button: Clickable, Focusable {
    override fun click() = println("button clicked")
    override fun setFocus(b: Boolean) = println("set focus")

    override fun showOff() {
        super<Focusable>.showOff()
        super<Clickable>.showOff()

    }
}

Here are some points to consider:

In Kotlin, we use colon : instead of implements and extends keywords
override is like the @Override annotation in Java, but it is mandatory to use in Kotlin.
To provide implementation for a method in Kotlin, we do not need to use the default keyword.
If we implement two interfaces in a class that contain the same method signature, we must provide the implementation of that method in our class.
To call the parent class's method, we need to use the super keyword in Kotlin. But to select a specific implementation we need to use super alongside with the ClassName inside angle brackets: super<Clickable>.showOff()

Open, Final and Abstract Modifiers

pages 70, 71, 72

In contrast to java, Kotlin classes are final by default. If we want to allow a class to be extended, we need to mark it with the open modifier. All properties and methods of that class are also final, so we have to use the open modifier for every one of them that we want to be overridden.

open class  RichButton : Clickable {
    // 1
    fun disable() {}

    // 2
    open fun animate() {}

    // 3
    override fun click() {}
}

1 -> disable() function is not open (methods are final by default), so it cannot be overridden
2 -> animate() function is open, so it can be overridden
3 -> click() function overrides an open method, so it is open itself and can be overridden

NOTE: If we override a member of a base class or interface, the overridden member is open by default. To prevent it from being overridden, we should mark it with final modifier.

As in Java, Kotlin supports abstract classes which cannot be instantiated. Why do we use abstract classes? Sometimes we need a contract but do not want to provide implementation. We want the implementation to be provided by the subclasses. Abstract members of an abstract class are always open and do not require us to use open keyword:

abstract class Animated {
    // 1
    abstract fun animate()

    // 2
    open fun stopAnimating() {}

    // 3
    fun animateTwice() {}
}

1 -> animate() function is marked with abstract keyword, so it is open and do not need the open modifier
2 -> stopAnimating() function is marked with open, so it can be overridden
3 -> animateTwice() function is neither abstract nor open, so it cannot be overridden by subclasses.

NOTE: A member in an interface is always open; we cannot declare it to as final. It's abstract if it has no body, but the keyword is not required.

Visibility Modifiers

pages 73, 74

Visibility modifiers help us to control access to declarations in our code base. Why should we do so? Because by enforcing encapsulation, we are sure that other classes do not depend on the implementation of our class, but rather on the abstraction. We can freely change the implementation and do not break anything in the client code!

Visibility modifiers in Kotlin are similar to those in Java. We have public, private, and protected with some differences. One difference is that, a class with no modifier is public by default and Kotlin does not support package-private modifier.
Why Kotlin does not have package-private modifier? Because they have replaced it with something better: we can use internal to declare a class to be visible inside a module.
What is a module? A module is a set of Kotlin files compiled together. It might be IntelliJ IDEA module, Gradle or Maven project.
What is the advantage? It provides real encapsulation for the implementation details of our module.

Another difference is that Kotlin allows the use of private visibility for top-level declarations, including classes, functions and properties. These are visible only in the file where they are declared.

To list the difference in visibility between Java and Kotlin:

Kotlin default visibility is public
Kotlin does NOT have package-private visibility
Kotlin supports module private visibility with internal keyword.
Kotlin supports private visibility for top-level declarations meaning visible inside the file.
protected modifier in Kotlin is just visible to the class itself or its subclasses, but in Java, it is also visible to classes in the same package!
Unlike Java, an outer class doesn't see private members of its inner (or nested) classes in Kotlin
Kotlin forbids us to reference less visible types from more visible members(e.g. referencing a private class from a public function) because it will expose the less visible type!

// 1
fun TalkativeButton.giveSpeech() {
    // 2
    yell()

    // 3
    whisper()
}

1 ->
2 ->
3 ->

Inner and Nested Classes

pages 75, 76,

As in Java, you can declare a class inside another class in Kotlin. Difference? Unlike Java, the Kotlin inner class does not have access to the outer class instance, unless we specify so.

A nested class in Kotlin is the same as a static nested class in Java. To turn a nested class to an inner class (so the inner class has a reference to the outer class), we have to mark it with inner modifier.

How do we reference an instance of an outer class inside the inner class? We use this@OuterClassName syntax as in the following example:

class Outer {
    inner class Inner {
        fun getOuterReference(): Outer = this@Outer
    }
}

In Java, we use OuterClassName.this syntax to refer to the outer class instance.

Sealed Classes

pages 77, 78

On the first glance sealed classes are similar to enums. The difference is quite obvious — enums are a group of related constants, sealed classes are a group of related classes with different states. The other difference is that, enum constant is available only in one instance, whereas sealed classes can have multiple instances with different values.

We use sealed classes when we want to impose restriction on the number of options and values to a super class. What would be the benefit? First, we don't have to provide an else branch in when expressions. Second, when we add another subclass to the super class, we get a compile time error if we don't cover that subclass in the when expressions that we have written.
Let's see an example:

interface Result
class Success(val data: Any) : Result
class Error(val error: Exception) : Result

fun result(result: Result) : Any =
    when (result) {
        is Success -> result.data
        is Error -> result.error
        else -> throw java.lang.IllegalArgumentException("Unknown Expression")
    }

In the sample above, there are some problems. First problem is that we always have to provide an else branch for every when expression we write for Result interface. Also, if we decide to add another type to the subtypes of the Result, say NetworkError, then we will face an IllegalArgumentException at runtime.

To resolve these issues, we use sealed classes. When we use sealed classes and handle all the subclasses in a when expression, we don't have to provide the else branch. If we add another subclass and forget to handle that new subclass in a when expression, we'll get a compile time error. Let's see the above example converted to a sealed class:

// 1
sealed class Result<out T> {
    // 2
    data class Success<out T>(val data: T) : Result<T>()
    data class Error(val error: Exception) : Result<Nothing>()
}

fun <T> result(result: Result<T>) : Any? =
    // 3
    when (result) {
        is Result.Success<T> -> result.data
        is Result.Error -> result.error
    }

1 -> sealed classes are open by default (because they are implicitly abstract), we don't have to provide the open modifier
2 -> we are able to subclass sealed classes just inside it or in the same file it is declared in
3 -> when we use a sealed class inside a when expression and we cover all possible cases, we don't have to provide the else branch

NOTE: Under the hood, the sealed class has a private constructor which can be called only inside the class.

To list all the characteristics of sealed classes:

They are implicitly abstract
Subclasses must be declared inside itself or in the same file as it is in
They ease the pain of providing else branches when we cover all the instances
If we add another instance and we forget to cover that instance inside a when expression, we will get a compile time error

Constructors and Properties

pages 79, 80, 81, 82, 83, 84, 85, 86

Primary Constructors

pages 79, 80, 81

You can read about Kotlin classes and constructors at Kotlin Official site.

Kotlin, just like Java, allows us to declare more than one constructor. However, Kotlin makes distinction between a primary constructor and secondary ones.

class User(val name: String)

The primary constructor is declared after the class name, outside the class body. We can use the constructor keyword, or omit that if we don't have annotations or visibility modifiers. The primary constructor roles are:

specifying constructor parameters
defining properties that are initialized by constructor parameters

If we want to write the equivalent Java way of the code above, it would look like this:

// 1
class User constructor(
    // 2
    _name: String
) {
    val name: String

    // 3
    init {
        name = _name
    }
}

In the code snippet above we have two new keywords:

1 -> constructor: begins the declaration of a constructor in Kotlin
2 -> init: introduces an initializer block
3 -> underscore: the underscore in constructor parameter is used to distinguish the parameter name from the property name. We could have used this.name = name instead.

What is an initializer block?
An initializer block contains code that's executed when the class is created and intended to be used together with primary constructors.
Why do we need initializer blocks? Because the primary constructors are concise in Kotlin and cannot contain logic, we need initializer blocks.

NOTE: We can have more than one initializer block in a class. Initializer blocks are executed in the same order as they appear in the code.

In the code snippet above, there can be two modifications:

we can omit the constructor keyword if there are not visibility modifiers or annotations on primary constructor
we can omit the initializer block and assign the property to to parameter directly.

class User(_name: String) {
    // 1
    val name = _name
}

1 -> This is called property initialization

Kotlin has an even more concise syntax for declaring properties and initializing them from the primary constructor. These properties can be declared as immutable (val) or mutable (var).

class User(val name: String)

As with functions, we can declare constructors with default values in Kotlin:

class User(val name: String = "John Doe")

NOTE: If all constructor parameters have default values, the compiler generates an additional constructor without parameters that uses the default values. It does so to make it easier to use Kotlin with libraries that instantiate classes without parameters.

If we extend another class, our primary constructor must initialize the super-class:

// 1
open class User(val name: String) {

}

// 2
class TwitterUser(username: String) : User(username) {

}

1 -> mark the super-class open to be able to extend it
2 -> TwitterUser must call its super-class constructor

Just like Java, if we don't provide any constructors, a no-arg constructor is generated for the class. And if we extend this class, we still need to call its constructor:

// 1
open class User

// 2
class InstagramUser : User() {

}

1 -> We did not declare any constructor for the User, but the compiler generates a no-arg constructor for the class
2 -> Although User does not have any declared constructor or parameters, we still need to call its generated constructor!

NOTE: Be aware of the difference between extending a class and implementing an interface in Kotlin. Because interfaces don't have any constructors, we don't put parentheses after their name when implementing them!

NOTE: To make sure that a class cannot be instantiated, we should make the primary constructor private:

class User private constructor() {

}

Secondary Constructors

pages 81, 82, 83

Because Kotlin has default values for constructor parameters, secondary constructors are not used as widely as they are used in Java.
We declare secondary constructors (like primary constructors) with the constructor keyword.
Let's take a look at an example from the Android world:

open class View {
    constructor(ctx: Context) {

    }
    constructor(ctx: Context, attr: AttributeSet) {

    }
}

class TextView : View {
    // 1
    constructor(ctx: Context) : super(ctx) {

    }

    constructor(ctx: Context, attr: AttributeSet) : super(ctx, attr) {

    }
}

1 -> if we extend a super-class and declare secondary constructors, we need to call the super class constructor in every constructor that we declare by using the super keyword (the exception is when we call another constructor of our class)

Just as in Java, we can call another constructor of our class using the this keyword:

class TextView : View {
    val myStyle =     // some code to instantiate myStyle 

    constructor(ctx: Context, attr: AttributeSet) : super(ctx, attr) {

    }

    // 1
    constructor(ctx: Context) : this(ctx, myStyle) {

    }
}

1 -> we use this keyword to call another constructor of our class

Properties in Interfaces

pages 83, 84

Kotlin interfaces can contain abstract properties.

interface User {
    // 1
    val name: String
}

1 -> The interface does not have a state because of this property because it does not specify whether it is a field or just a getter. It just means that classes that implement the interface need to provide a way to obtain the value of name. Pay attention that all classes are overriding the name property.

// Primary constructor property
class PrivateUser(override val name: String) : User

// Custom getter -> it does not have a backing field
class SubscribingUser(val email: String) : User {

    override val name: String
        get() = email.substringBefore('@')
}

// Property initializer
class FacebookUser(val accountId: Int) : User {
    override val name = getFacebookName(accountId)

    private fun getFacebookName(accountId: Int): String {
        //code to get the facebook name
    }
}

Accessing Backing Fields

page 85

Let's see how we can access a backing field from the accessors. To do so, we use the field identifier in the body of a setter.

class User7(val name: String) {
    var address: String = "unspecified"
        // 1
        set(value) {
            // 2
            println(
                """
            address changed for $name: 
            $field -> $value
            """.trimIndent()
            )
            // 3
            field = value
        }
    get() {
        // 2
        return "$name address: $field"
    }
}

1 -> We define a setter by writing a set function under the property (the property must be mutable (var))
2 -> We can access the property backing field by the field keyword.
3 -> We change the value of the property

NOTE: If we provide custom accessors for a property and do not use the field keyword, the compiler won't generate a backing field for that property (for getter in val property and for both accessors in var property).

class User(val name: String) {
    // 1
    var address: String = "unspecified"
        set(value) {
            println(
                "address for $name: $value"
            )

        }
    get() {
        return "$name address: "
    }
}

If we write such a code, it won't compile with the error Initializer is not allowed here because this property has no backing field. Why? Because we did not use the field keyword in neither the setter nor the getter.

Changing Accessor Visibility

page 86

The accessor's visibility is the same as the property's visibility. We can change the accessor's visibility by putting a visibility modifier before the get or set keyword.

class User(val name: String) {
    // 1
    var id: Int = 0
        // 2
        private set(value) {
            field = getAutoGeneratedId()
        }


    private fun getAutoGeneratedId(): Int {
        // code to get an auto generated id
    }
}

1 -> the property's visibility is public and can be accessed outside the class
2 -> we limit the setter's visibility to the class because we do not want other classes to set this property

NOTE: Accessors cannot be more visible than the property itself. Meaning that if the property is protected, the accessors can be private but cannot be public!

Universal Object Methods

pages 87, 88, 89

We use some classes specifically to hold data. These classes usually need to override some methods like toString(), equals(), and hashCode(). Let's see how we should implement them in Kotlin.
First, we declare a Person class.

class Person(
    val name: String,
    val phoneNumber: String,
    val address: String
)

toString()

toString() method is used primarily for debugging and logging. It should be overridden in almost every class to make the debugging easier. If we do not override the toString() method, when we print an object, the result looks like Person@23fc625e

class Person(
    val name: String,
    val phoneNumber: String,
    val address: String
) {
    override fun toString(): String {
        return "Person(name=$name, phone number=$phoneNumber, address=$address"
    }
}

equals()

equals() method is used to check whether two objects' values are equal, not the references!

class Person(
    val name: String,
    val phoneNumber: String,
    val address: String
) {
    override fun toString(): String {
        return "Person(name=$name, phone number=$phoneNumber, address=$address"
    }

    override fun equals(other: Any?): Boolean {
        if (other == null || other !is Person)
            return false
        return name == other.name &&
                phoneNumber == other.phoneNumber &&
                address == other.address
    }
}

hashCode()

The hashCode() method should be always overridden together with the equals() method! If two objects are equal, they must have the same hash code.

class Person(
    val name: String,
    val phoneNumber: String,
    val address: String
) {
    override fun toString(): String {
        return "Person(name=$name, phone number=$phoneNumber, address=$address"
    }

    override fun equals(other: Any?): Boolean {
        if (other == null || other !is Person) 
            return false
        return name == other.name &&
                phoneNumber == other.phoneNumber &&
                address == other.address
    }

    override fun hashCode(): Int {
        return name.hashCode() + 
                phoneNumber.hashCode() + 
                address.hashCode()
    }

}

NOTE: Why the hashCode() method should be always overridden together with the equals() method? Because some clients (like HashSet) first use the hashCode() method to check for equality and if the hash codes are equal, then they check the equals() method!

Data Classes

pages 89, 90, 91

Kotlin has made it easier for us to declare classes to hold data. We just mark that class with the data modifier and the Kotlin compiler would generate the previously mentioned methods for us! The compiler will generate toString(), equals(), hashCode(), (also copy(), and componentN()) functions from the properties declared in the primary constructor.

data class Person(
    val name: String,
    val phoneNumber: String,
    val address: String
)

The Person class above is somehow equal to the Person class we declared before this (with toString(), equals(), hashCode() methods overridden).

Data classes must fulfill the following requirements:

The primary constructor needs to have at least one parameter.
All primary constructor parameters need to be marked as val or var.
Data classes cannot be abstract, open, sealed, or inner.

NOTE: As we mentioned earlier, the compiler just takes into account the properties in the primary constructor. In other words, we can declare properties in the class body to exclude it from generated implementations(like toString() and hashCode()).

`copy()` Method

It's strongly recommended that we use read-only (val) properties to make the instances of data classes immutable. This is mandatory if we want to use such instances as keys in a HashMap or a similar container, because otherwise the container could get into an invalid state if the object used as a key is modified after it was added to the container.

Class Delegation

Sometimes we need to change the behavior of a class, but we cannot extend that class (either our class has another parent class, or the class we want to extend is not open). In this situation, we can use the decorator pattern:

We implement the same interface that the class we want to extend is implementing
We declare a property of type of the class we want to extend
We forward the requests that we don't want to change to that property
If we want to change the behavior of a method, we will override that method in our class Let's see this pattern in practice:

class DelegatingCollection<T> : Collection<T> {

    private val innerList = arrayListOf<T>()

    override val size: Int get() = innerList.size

    override fun isEmpty() = innerList.isEmpty()

    override fun iterator() = innerList.iterator()

    override fun containsAll(elements: Collection<T>) = innerList.containsAll(elements)

    override fun contains(element: T) = innerList.contains(element)

}

Here, we have used the decorator pattern as we use it in Java. We forward every call to the innerList variable of type ArrayList. If we want to change the behavior of the method isEmpty(), we can easily do so be defining our own implementation.

Fortunately, Kotlin has provided a first-class support for delegation. To use this feature:

We extend the same interface as our class we want to extend
We declare a property of the class we want to extend
We use the by keyword after the interface implementation.

class DelegatingClass<T>(
    val innerList: Collection<T> = ArrayList<T>()
) : Collection<T> by innerList

This is just the same as the implementation before with much less boilerplate code! We have used the by keyword to delegate the requests to the object specified(innerList here)!

The `object` Keyword

pages 93, 94, 95, 96, 97, 98, 99, 100, 101

The object keyword in Kotlin is used to define a class and create an instance of that class at the same time.

Object Declaration

pages 93, 94, 95

Singleton design pattern is used fairly common in object-oriented design systems. Kotlin provides object declaration which combines the class declaration and a declaration of a single instance of that class.

object DataProviderManager {
    fun registerDataProvider(provider: DataProvider) {
        // ...
    }

    val allDataProviders: Collection<DataProvider>
        get() = // ...
}

Object declarations are created with object keyword. An object declaration defines a class and a variable of that class in a single statement.

NOTE: If we pay attention to its name (object declaration), we understand its purpose. We declare an object, and to declare an object, we must create an instance of that object. With object declarations, we combine the two steps.

An object declaration is just like a normal class with one difference: it does not allow constructors to be declared in it. Objects of object declarations are created immediately at the point of definition, not by calling their constructors.

NOTE: Object declaration, like a variable declaration, is not an expression and cannot be used on the right-hand side of an assignment statement!

Object declarations allow us to call their methods and access their properties by using the class name and the . character:

val numberOfDataProviders = DataProviderManager.allDataProviders.size

DataProviderManager.registerDataProvider(/*...*/)

Object declarations can inherit from classes and interfaces. This is often useful when the framework requires us to implement an interface, but our implementation does not contain any state! The Comparator interface is a great example for this. A Comparator implementation receives two objects and returns an integer indicating which of the two objects is greater! Comparators never store any data, so we usually need a single Comparator instance for a particular way of comparing objects. This is a perfect use for object declaration!

data class Person(val name: String, val age: Int)

object AgeComparator : Comparator<Person> {
    override fun compare(p1: Person, p2: Person): Int {
        return p1.age - p2.age
    }
}

We can use singleton objects in any context where an ordinary object can be used.

We can also declare objects in a class. Such objects also have just a single instance; they don't have a separate instance per instance of the containing class. Take the Person class as an example. Isn't it more logical to put different Comparator implementations inside the class itself for further use?

data class Person(val name: String, val age: Int) {

    object AgeComparator : Comparator<Person> {
        override fun compare(p1: Person, p2: Person): Int {
            return p1.age - p2.age
        }
    }

    object NameComparator : Comparator<Person> {
        override fun compare(p1: Person, p2: Person): Int {
            return p1.name.compareTo(p2.name)
        }
    }
}

To refer to the instance of the singleton object in Java which is created by the object declaration, we should use the INSTANCE static field:

AgeComparator.INSTANCE.compare(person1, person2);

Companion Objects

pages 96, 97, 98, 99, 100

Kotlin does not have the static keyword which exists in Java. Most of the time, our needs for static members and methods is satisfied with top-level member and functions in Kotlin. However, we cannot access private members of the class. So, if we need to write a function that can be called without an instance of the class, but has access to the private members of the class, we can use the object declaration inside that class.

NOTE: Please be aware that companion object (just like static methods) cannot access instance members of the class. To do so, we must provide an instance of the class for the companion object:

class Person {

    private lateinit var name: String

    object Print {
        fun printName1(person: Person) {
            println(person.name)
        }

        fun printName2() {
            val person = Person()
            println(person.name)
        }
    }
}

If we mark the object declaration with the keyword companion, we can access the methods and properties inside that object declaration directly through the name of the containing class (without specifying the object name).

For example, to call the methods in the above example, we use this syntax:

Person.Print.printName1(Person())
Person.Print.printName2()

Now, if we omit Print (the object declaration name) and put the companion keyword before object, we can use the methods like static methods in Java:

class Person {

    private lateinit var name: String

    companion object {
        fun printName1(person: Person) {
            println(person.name)
        }

        fun printName2() {
            val person = Person()
            println(person.name)
        }
    }
}

To use the methods above, we use this syntax:

Person.printName1(personInstance)
Person.printName2()

Note that we do not use any object name (Print in previous example) to call the methods inside companion object.

One of the most important use-cases of companion object is to implement the factory pattern. Why? Because companion objects have access to the private members of the class, including the constructors.

class Person private constructor(val name: String, val role: Role){

    companion object {
        fun newManager(name: String) = 
            Person(name, Role.MANAGER)

        fun newEmployee(name: String) =
            Person(name, Role.EMPLOYEE)
    }

    enum class Role {
        MANAGER, EMPLOYEE
    }
}

Here, we have used factory methods to create instances of the Person object. To create instances of Person, we use the class name with the method from the companion object:

Person.newManager("Tom")

Factory methods are useful for several reasons:

They can be named according to their purpose
Can return subclasses depending on the method that we invoke
We can also avoid creating new objects when it's not necessary.

The downside with using factory methods instead of constructors is that we cannot override them in subclasses!

Companion Objects Extension

We can define an extension function (just like normal extension functions) for companion objects. The only requirement is that the class should have at least one companion object. If it does not have any, we should define an empty one to extend it.
Suppose we want to add an extension function (say setupFakeManager()) to the Person class we declared earlier. Here is a sample code:

fun Person.Companion.setupFakeManager() : Person {
    return Person.newManager("FakeManager")
}

Because we had a companion object in the Person class, we just extended the companion object to have another function. Note the Companion keyword after the class name. By using the Companion keyword, we are indicating that we are extending the companion object!

Object Expressions

The third use-case of the object keyword is to declare anonymous objects. Anonymous objects are here to replace the Java's anonymous inner classes. For instance, we can use them to setup click listeners in Android:

button.setOnClickListener(object : View.OnClickListener {
    override fun onClick(view: View?) {
        // Do some work here
    }

})

As we see, the syntax is the same as the object declaration but we have dropped the object name!

NOTES: Object expressions in Kotlin:

can implement multiple interfaces or no interfaces(Java can just extend one class or implement one interface).
can access the variables in the function where they are created.
are useful when we want to override multiple methods in our anonymous object. Otherwise, we are better to use lambda expressions.
if we need the instance of it, we can assign the expression to a variable.

This is the end of part 3 which was the summary of chapter 4 (a long one:-) ). There were other parts in chapter 4 that I did not cover here because I felt they are not as important and they would have made the article too long. Anyhow, if you found this article useful, please like it and share it with other fellow developers. If you have any questions or suggestions, please feel free to comment. Thanks for your time.

Create alias in mac zsh

Mahdi Abolfazli — Tue, 30 Aug 2022 05:31:00 +0000

Let's see the steps without any further information:
1- check if we have bash or zsh:

echo $SHELL

2- If it is zsh, open the file .zshenv (if it did not work, add them to .zshrc file):

vim .zshenv

3- Add aliases here (I have created some aliases to use the git more efficiently):

alias g="git"
alias gl="git log"
alias gs="git status"
alias gc="git commit -a"
alias gaa="git add --all"
alias gpusho="git push origin"
alias gpullo="git pull origin"
alias gco="git checkout"
alias gb="git branch"
alias gcb="git checkout -b"

4- Close the terminal and open a new one to apply the effects.

DONE!

If we had bash instead of zsh, we should have used the bashrc file. To see the full video about this, you can watch this amazing video.

If you use any useful aliases, let me know in the comments!

Algorithms Part 1 - Bags, Queues and Stacks

Mahdi Abolfazli — Mon, 15 Aug 2022 13:59:00 +0000

This is part 1 of the Algorithms series. In this series, I will write a summary of the book Algorithms by Robert Sedgewick and Kevin Wayne.

Introduction

You may wonder is this series good for me? If you are a developer or programmer with basic knowledge of Java or Kotlin or any other OOP language who feels an urge to improve his/her knowledge about Algorithms and Data Structures, you are at the right place! Should you read the entire book? It depends. If you want to be an Algorithm guru, of course you not only have to read this book, but also you need to read other books as well! However, to become familiar with algorithms and using them in your code, it is not necessary and this series would suffice. Be sure that we will provide the necessary content to understand the concept that we are covering(this time, Bags, Queues and Stacks). Without further ado, let's dive into world of Algorithms.

What we cover from the book in this chapter: LinkedList, Bag, Stack and Queue and their implementations.

What we do NOT cover the book in this chapter: Generics and Iterators, because we assume our readers have a good knowledge about these concepts. However, I will write another article about Iterators and will provide a link to that post here.

Bags, Queues and Stacks

This section involves understanding three fundamental collections of objects. These collections differ in how they remove the objects or examine the next object. The goal of studying these collections is to understand that the way objects are represented in a collection directly impacts the efficiency of the various operations. Let's first examine the APIs of each of these collections:

Bag, Queue and Stack API

The APIs are almost identical, with the addition of a remove function for Queue(dequeue() method) and Stack(pop() method).

Bag

Bag is a collection where order of iteration is unspecified and removing items is not supported -its purpose is to collect items and iterating through them.
We can use Stack or Queue to provide the same functionality, but to emphasize the fact that order of items is not important, we use Bag. The use-case is when we want to do some calculations on an input data(e.g. calculating average and other statistical functions) and the order of inputs is not important to the client.

Queue

A Queue (or a FIFO Queue) is a collection that is based on the first-in-first-out (FIFO) policy. A typical reason to use a queue in an application is to save items in a collection while at the same time preserving their relative order: they come out in the same order in which they were put in. For instance, if we want to read values from a file or console and save them in the order in which we read them, we can save them in a queue and then dequeue each one to process them.

Stack

A Stack (or a pushdown Stack) is a collection that is based on the last-in-first-out(LIFO) policy. When a client iterates through the items in a stack with the foreach construct, the items are processed in the reversed order in which they were added. A typical reason to use a stack is to save items in a collection while at the same time reversing their relative order.

One of the most important usages of the Stack is in the compilers and in the arithmetic expression evaluation. To process an arithmetic expression, we proceed from left to right and take the entities one at a time. We manipulate the stacks according to four possible cases:

push operands onto the operand stack
push operators onto the operator stack
ignore left parentheses
on encountering a right parentheses, pop an operator, pop the requisite number of operands, and push onto the operand stack the result of applying that operator to those operands.
after the final parentheses has been processed, the one remaining value on the stack is the result of the expression.

Here is the code for the above arithmetic expression evaluation.
NOTE: It's different from the one in the book. It does not use the libraries mentioned in the book. Another thing to notice is that, in the book, StdIn.readString() method has been used. This method may cause the program to fall in an infinite loop because it waits for the user input. We have used the one that uses the arguments when running the program.

import java.util.Stack;

public class Evaluate {
    public static void main(String[] args) {
        Stack<String> ops = new Stack<>();
        Stack<Double> vals = new Stack<>();
        //     ( 1 + ( ( 2 + 3 ) * ( 4 * 5 ) ) )
        //     ( ( 1 + sqrt ( 5.0 ) ) / 2.0 )
        for (String s : args) {

            if (s.equals("(")) ;
            else if (s.equals("+")) ops.push(s);
            else if (s.equals("-")) ops.push(s);
            else if (s.equals("*")) ops.push(s);
            else if (s.equals("/")) ops.push(s);
            else if (s.equals("sqrt")) ops.push(s);
            else if (s.equals(")")) {
                String op = ops.pop();
                double v = vals.pop();
                if (op.equals("+")) v = vals.pop() + v;
                else if (op.equals("-")) v = vals.pop() - v;
                else if (op.equals("*")) v = vals.pop() * v;
                else if (op.equals("/")) v = vals.pop() / v;
                else if (op.equals("sqrt")) v = Math.sqrt(v);
                vals.push(v);
            } else
                vals.push(Double.parseDouble(s));
        }
        System.out.println(vals.pop());

    }
}

This algorithm may seem complicated at first but it is easy to reason about. Any time the algorithm encounters a subexpression consisting of two operands separated by an operator, all surrounded by parentheses, it leaves the result of performing that operation on those operands on the operand stack. The result is the same as if that value had appeared in the input instead of the subexpression, so we can think of replacing the subexpression by the value to get an expression that would yield the same result. We can apply this argument again and again until we get a single value.

NOTE: The code above is a simple example of an interpreter: a program that interprets the computation specified by a given string and performs the computation to arrive at the result.

Implementing Collections

To begin with implementation details, we start with simple classic implementation, and then we will enhance them that will lead us to implementations of the APIs at the first of the article.

Fixed-Capacity Stack

To implement the fixed-capacity stack, an obvious choice is to use an array. The instance variable are an array a[] that hold the items in the stack and an integer N that counts the number of items in the stack. To remove an item, we decrement N and then return a[n]; to insert a new item, we set a[N] equal to the new item and then increment N. This implementation has these properties:

the items in the array are in their insertion order
the stack is empty when N is 0
the top of the stack is at a[N - 1]

The primary performance characteristic of this implementation is that push and pop operations take time independent of the stack size.

Here is the implementation of the fixed-capacity stack:

public class FixedCapacityStack<T> {
    private T[] a;
    private int N;

    @SuppressWarnings("unchecked")
    public FixedCapacityStack(int capacity) {
        a = (T[]) new Object[capacity];
    }

    public boolean isEmpty() {
        return N == 0;
    }

    public void push(T item) {
        a[N++] = item;
    }

    public T pop() {
        return a[--N];
    }

    public int size() {
        return N;
    }

}

Here is a test client for the fixed-capacity stack:

public class FixedCapacityStackClient {
    public static void main(String[] args) {
        FixedCapacityStack<String> stack = new FixedCapacityStack<String>(10);
        for (int i = 0; i < 10; i++) {
            stack.push("item:" + i);
        }
        System.out.println("Is the stack empty? " + stack.isEmpty());
        System.out.println("Stack size? " + stack.size());

        for (int i = stack.size(); i > 0; i--) {
            System.out.println("size is: " + stack.size() + " and item is: " + stack.pop());
        }
        System.out.println("Is the stack empty? " + stack.isEmpty());
        System.out.println("Stack size? " + stack.size());
    }
}

This implementation is not suitable for every use case. At least, we want the stack size to be flexible. To do so, we resize the array in the stack. We will modify our implementation to dynamically adjust the size of the array a[] so that it is sufficiently large to hold all of the items and not so large to waste an excessive amount of space.
To have a full implementation of the stack with arrays, we should consider these steps:

we should implement the Iterable interface to be able to iterate through each item in the stack
we should implement a resize method so that it can increase/decrease the array size if needed
double the array size if the array is full
reduce the array size to half if number of items in the array is less than the quarter of the array size

import java.util.Iterator;

public class ArrayStack<T> implements Iterable<T> {

    private T[] items;
    private int N;

    // 1
    public ArrayStack() {
        this.items = (T[]) new Object[1];
    }

    // 2
    public ArrayStack(int capacity) {
        this.items = (T[]) new Object[capacity];
    }

    public void push(T item) {
        // 3
        if (N == items.length)
            resize(N * 2);
        items[N++] = item;
    }

    public T pop() {
        T item = items[--N];
        // 4
        items[N] = null;
        // 5
        if (N > 0 && N == items.length / 4)
            resize(items.length / 2);
        return item;
    }


    public boolean isEmpty() {
        return N == 0;
    }

    public int size() {
        return N;
    }

    private void resize(int maxCapacity) {
        T[] temp = (T[]) new Object[maxCapacity];
        for (int i = 0; i < N; i++) {
            temp[i] = items[i];
        }
        items = temp;
    }


    // 6
    @Override
    public Iterator<T> iterator() {
        return new Iterator<T>() {
            int index = N;

            @Override
            public boolean hasNext() {
                return index > 0;
            }

            @Override
            public T next() {
                return items[--index];
            }
        };
    }
}

1 & 2 -> we have defined two constructors for the stack. One with a default array size of 1. The other is provided for the user to specify an estimate for the capacity of the stack.
3 -> when pushing an item in the stack, if array is full, we are doubling the array size
4 -> when popping an item from the stack, we should set the array position to null to avoid loitering.
5 -> when popping an item from the stack, if the stack size is less than a quarter of the array size, we will shrink the array size to half
6 -> we implement the iterator interface to iterate through the items of the stack. This way, we can use foreach loops in Java and clients are not concerned with iteration.

We have a working implementation of the Stack. There are some issues with this implementation:

More space is required than the actual size of the stack
Time per operation is not independent of the size of the collection

To tackle these issues, we can use linked-lists to implement stack. It will solve the issues mentioned above. Let's see how we can implement stack using linked-list:

import java.util.Iterator;

public class Stack<T> implements Iterable<T> {

    private Node first;
    private int N;

    private class Node {
        T item;
        Node next;
    }


    public void push(T item) {
        Node oldFirst = first;
        first = new Node();
        first.item = item;
        first.next = oldFirst;
        N++;
    }

    public T pop() {
        T item = first.item;
        first = first.next;
        N--;
        return item;
    }


    public boolean isEmpty() {
        return first == null;
    }

    public int size() {
        return N;
    }


    @Override
    public Iterator<T> iterator() {
        return new Iterator<T>() {
            private Node current = first;

            @Override
            public boolean hasNext() {
                return current != null;
            }

            @Override
            public T next() {
                T item = current.item;
                current = current.next;
                return item;
            }
        };
    }
}

As we can see, this implementation is more flexible than the array one. It uses exactly the same memory space as needed by the stack(unlike the array implementation that the array needs more space than the stack). The operations on the stack are also not dependent on the stack size.

This was the full implementation of the stack. Now let's see Bag and Queue implementations. Keep in mind that we can implement Bag and Queue with array as well. But we will not cover those implementations because it's straight forward.

We'll start with queue:

import java.util.Iterator;

public class Queue<T> implements Iterable<T> {

    private Node first;
    // 1
    private Node last;
    private int N;

    private class Node {
        T item;
        Node next;
    }

    public void enqueue(T item) {
        Node oldLast = last;
        last = new Node();
        last.item = item;
        last.next = null;
        if (isEmpty()) first = last;
        else oldLast.next = last;
        N++;
    }

    public T dequeue() {
        T item = first.item;
        first = first.next;
        N--;
        if (isEmpty()) last = null;
        return item;
    }

    public int size() {
        return N;
    }

    public boolean isEmpty() {
        return first.item == null;
    }


    @Override
    public Iterator<T> iterator() {
        return new Iterator<T>() {
            private Node current = first;

            @Override
            public boolean hasNext() {
                return current != null;
            }

            @Override
            public T next() {
                T item = first.item;
                current = first.next;
                return item;
            }
        };
    }
}

1 -> we need last in the queue because every time we add something, we should add it to the end of it(remember that queue is first-in, first-out).

The other parts are the same as the Stack implementation. So, let's see the Bag implementation:

import java.util.Iterator;

public class Bag<T> implements Iterable<T> {

    private Node first;
    private int N;

    private class Node {
        T item;
        Node next;
    }

    public void add(T item) {
        Node oldFirst = first;
        first = new Node();
        first.item = item;
        first.next = oldFirst;
        N++;
    }

    public boolean isEmpty() {
        return first == null;
    }

    public int size() {
        return N;
    }


    @Override
    public Iterator<T> iterator() {
        return new Iterator<T>() {
            private Node current = first;

            @Override
            public boolean hasNext() {
                return current != null;
            }

            @Override
            public T next() {
                T item = current.item;
                current = current.next;
                return item;
            }
        };
    }
}

As we can see, Bag implementation is the same as the Stack with two minor changes:

we should remove the pop() method because Bag does not support removing items
rename the push() method to add()

Kotlin in Action Summary - Part 2

Mahdi Abolfazli — Sun, 14 Aug 2022 12:39:00 +0000

This is part 2 of the series Kotlin in Action Summary. Here is the link to part 1 which we talked about chapter 2 of the book with the title "Kotlin basics". As mentioned before, it is highly recommended to read the book first and consider this series as a refresher. We do NOT cover all the materials in the book. Let's start with part 2, chapter 3 of the book: "Defining and Calling Functions"!

Creating Collections

Let's see how we create collections in Kotlin:

val set = hashSetOf(1, 7 ,53)
val list = arrayListOf(1, 7, 53)
val map = hashMapOf(1 to "one", 7 to "seven", 53 to "fifty-three")

NOTE: Note that to in the hashMapOf is a normal function Kotlin. We will cover it later in the section Infix Calls.

NOTE: Kotlin uses standard Java collections to make it easier to interact with Java.

Java collections have a default toString implementation and the formatting of the output is fixed. If we want to change this formatting, we use third party libraries like Guava or Apache Commons. In Kotlin, a function to handle this issue is part of the standard library.
We use joinToString function to accomplish the mentioned task. This function appends elements of the collection to a StringBuilder, with a separator between them, a prefix at the beginning and a postfix at the end:

fun <T> joinToString(
    collection: Collection<T>,
    separator: String,
    prefix: String,
    postfix: String

) : String {
    val result = StringBuilder(prefix)
    for ((index, element) in collection.withIndex()) {
        if (index > 0) result.append(separator)
        result.append(element)
    }
    result.append(postfix)
    return result.toString()
}

We will edit this function to make it less verbose.

Named Arguments

The first problem with Java's function calls is that if they have a number of arguments especially with the same type (as we have with the joinToString function), the role of each argument is not clear. This is especially problematic with boolean flags. In Java, some programmers use enums as boolean flags and others write comments in the function declaration before each parameter.
Fortunately, Kotlin has come up with a better solution. We can write the name of each argument and assign a value to that. This makes the code much more readable:

val list = listOf(1, 7, 53)

joinToString(
collection = list, separator = ",", prefix = "(", postfix = ")"
)

NOTE: If we specify the name of an argument in a call, we must specify the name of all other arguments after that.

NOTE: Unfortunately, we can't use name arguments when calling methods from Java.

Default Parameter Values

One of the problems with Java functions is the huge number of overloaded methods. Programmers provide overloaded methods for several reasons: backward compatibility, convenience of API users or other reasons. Most of the times, we have a method with all the parameters and other overloaded methods are just a simpler version of that method that omitted some of the parameters and provided them with default values.
In Kotlin, we can avoid overloaded methods because we can provide default parameter values:

fun <T> joinToString(
    collection: Collection<T>,
    separator: String = ", ",
    prefix: String = "",
    postfix: String = ""

): String {
    val result = StringBuilder(prefix)
    for ((index, element) in collection.withIndex()) {
        if (index > 0) result.append(separator)
        result.append(element)
    }
    result.append(postfix)
    return result.toString()
}

val list = listOf(1, 7, 53)

joinToString(
collection = list, prefix = "(", postfix = ")"
)
joinToString(
collection = list, separator = "- "
)

Here, we have provided default values for separator, prefix and postfix. So, we can omit them in some calls or provide all of them. If we wanted to have exact the same functionality in Java, we should have provided 8 overloaded methods.

NOTE: When we are using normal function calls, we should keep the ordering of the arguments the same as the parameters in the function and you can only omit the trailing arguments. But with name arguments, we can provide arguments at any order and we can omit any argument with default values anywhere in the function.

NOTE: Default values are encoded in the function being called, not at the call site.

Default Values and Java

When we want to use default values from Java code, we should use the @JvmOverloads annotation on the function. This annotation will tell the Kotlin compiler to provide the Java overloaded functions we need to call from Java.

Top-Level Functions and Properties

Unlike Java, Kotlin does not require us to write all functions and properties in classes. This is specially useful because we can avoid create Utility classes. We can write functions at the top-level of a source file, outside of any class. Such functions are still a part of the package they are declared in and we should import them to use them in other packages.

package strings

fun joinToString(...) : String { ... }

How is this compiled and how does it run? Top-level functions and properties are compiled to static methods and static members of a class. Which class? The compiler will create a class called FileNamekt.java and when we want to call these functions from Java, we should use filename.theFunction().
Why does this happen? Because JVM can only execute codes in a class.
Let's assume the above code is in join.kt file. Here's how we can use it in our Java code:

import strings.JoinKt

public class MyClass {
    public static void main(String[] args) {
        List<String> list = Arrays.asList("one", "two", "three");
        JoinKt.joinToString(list, ", ", "", "")
    }
}

NOTE: To change the class name that contains top-level functions generated by the Kotlin compiler, we can use the @file:JvmName("MyPreferredFileName") annotation. We must put this annotation at beginning of the file, even before the package name.
Here we can see a Kotlin file with top-level functions named Join.Kt:

@file:JvmName("StringFunctions")

package strings

fun <T> joinToString(
    collection: Collection<T>,
    separator: String = ", ",
    prefix: String = "",
    postfix: String = ""

): String {
    val result = StringBuilder(prefix)
    for ((index, element) in collection.withIndex()) {
        if (index > 0) result.append(separator)
        result.append(element)
    }
    result.append(postfix)
    return result.toString()
}

Java class that calls the new name of the Kotlin top-level functions:

import strings.StringFunctions

public class MyClass {
    public static void main(String[] args) {
        List<String> list = Arrays.asList("one", "two", "three");
        //notice that we changed the class name with @file:JvmName annotation
        StringFunctions.joinToString(list, ", ", "", "");
    }
}

Top-Level Properties

Properties can also be placed at the top level of a file. The value of such a property is stored in a static field.
Top-level properties can be used to define constatns:

val UNIX_LINE_SEPARATOR = "\n"

NOTE: By default, top-level properties are exposed to Java by accessor methods: a getter for a val and a getter and a setter for a var.
NOTE: If we want to declare constant to Java code as public static final field, we must use the const modifier (this is just allowed for primitive data types as well as for strings):

const val UNIX_LINE_SEPARATOR = "\n" //-> public static final String UNIX_LINE_SEPARATOR = "\n";

Extension Functions

An extension function is a function that can be called as a member of a class but is defined outside of it.
To declare an extension function, you need to put the name of the class or interface that you're extending before the name of the function you are adding.

fun String.lastChar() : Char = this.get(this.length - 1)

The class name you are extending upon is called the receiver type.
The value (or the object) on which you are calling the extension function is called the receiver object.

To call this function, we will use the same syntax for calling ordinary class functions:

println("Kotlin".lastChar()) //this prints n

In a sense, we have added a method to the String class. Although String is not part of our code and we do not have access to its code to modify it. It does not even matter if it is any other JVM based language. We can use this feature as long as the code is compiled to a java class.

In the body of extension functions, we can use this as we would use in a method and we can also omit the this keyword, as we can do it in a normal method.
We also have direct access to the methods and properties of the class we are extending (just like the methods of the class). However, we cannot access the private fields and methods of the class. In other words, extension function do NOT allow us to break the encapsulation.

NOTE: On the call site, we cannot distinguish extension functions from member functions of the class.

Importing Extension Functions

When we are defining an extension function, it does not become available across our entire project. So, we have to import the function like any other class or function when we want to use inside other packages:

import strings.lastChar

val c = "Kotlin".lastChar()

We can also change the name of the class or function you are importing using the as keyword:

import strings.lastChar as last

val c = "Kotlin".last()

Extension Functions Under the Hood

Under the hood, an extension function is a static method that accepts the receiver object as its first argument. Calling an extension function does not involve creating adapter objects or any other runtime overhead.

To call an extension function from Java, you call the static method and pass the receiver object instance. The name of the class is determined from the name of the file where the function is declared.

char c = StringUtils.lastChar("Java");

Utility Functions as Extensions

Now, we can write the final version of the joinToString function:

fun <T> Collection<T>.joinToString(
    separator: String = ", ",
    prefix: String = "",
    postfix: String = ""
) : String {
    val result = StringBuilder(prefix)
    for((index, element) in this.withIndex()) {
        if (index > 0) result.append(separator)
        result.append(element)
    }
    result.append(postfix)
    return result.toString()
}

We have made it an extension function to the Collection interface so we can use it like a member of a class. We have also provided default values for all the arguments.

NOTE: Because extension functions are effectively syntactic sugar over static method calls, we can use a more specific type as a receiver type, not only a class or interface:

fun Collection<String>.joinToStringSpecificVersion(
    separator: String = ", ",
    prefix: String = "",
    postfix: String = ""
) = joinToString(separator, prefix, postfix)

As we can see, we have made the extension function only working for collections of strings. This is possible because they are normal static methods in Java.

NOTE: Because extension function are static, they cannot be overridden in subclasses because the function that's called depends on the declared static type of the variable, not on the runtime type of the value stored in that variable. In other words, overriding does not apply to extension functions. Kotlin resolves extension functions statically.

NOTE: Member functions always take precedence to the extension functions.

Extension Properties

Extension properties provide a way to extend classes with APIs that can be accessed using the property syntax, rather than the function syntax.
Even though we call them properties, they cannot have state because there is no place to store them (we cannot add fields to existing instances of Java objects).

val String.lastChar : Char
    get() = get(length - 1)

an extension property looks like a regular property with a receiver type added
the getter must always be defined (because there's no backing field and no default getter)
initializers are not allowed either for the same reason

NOTE: If we define a property for a mutable object like StringBuilder, we can make it a var because the content of it can be modified:

var StringBuilder.lastChar: Char
    get() = get(length - 1)
    set(value: Char) {
        this.setCharAt(length - 1, value)
    }

We can access extension properties exactly like member properties

println("Kotlin".lastChar) //prints n
val sb = StringBuilder("Kotlin?")
sb.lastChar = '!' //replaces ? with !
println(sb) //prints Kotlin!

NOTE: To access an extension property from Java, we must invoke its getter explicitly:

StringUtils.getLastChar("Java");

Varargs

In Kotlin, when we call a function to create a list, we can pass any number of arguments to it:

val list = listOf(2, 3, 5, 7, 11)

Let's take a look at the listOf method to see how it is declared:

fun <T> listOf(vararg values: T) : List<T> = if (values.isNotEmpty()) values.asList() else emptyList()

As we can see, Kotlin uses the vararg to declare such library functions. As we know from Java, vararg is a feature that allows us to pass an arbitrary number of values to a method by packing them in an array.
Kotlin uses the same concept but with different syntax. In Kotlin, instead of three dots (...), we use the vararg modifier on the parameter.
The other difference between varargs in Java and Kotlin is that in Java we can pass an array as it is to a method argument of vararg. But in Kotlin, we must explicitly unpack the array, so that every element becomes a separate argument to the function being called. This features is called spread operator. How should we accomplish this? We should put * character before the corresponding argument:

fun spreadOperator(args: Array<String>) {
    val list = listOf(*args)
    val listWithFixedValue = listOf("args:", *args)
}

As we can see in the listWithFixedValues, in Kotlin, we can pass some values alongside with the array when we are using varargs parameter. This feature is not supported by Java.

Infix Calls

In an infix call, the method name is placed immediately between the target object name and the parameter, with no extra separators. Infix call can be used with regular methods and extension functions that have one required parameter. The to function in the mapOf function to create a map is an infix call:

val map = mapOf(1 to "one", 7 to "seven", 53 to "fifty-three")

To declare an infix call for a function, we need to mark it with the infix modifier. Here we can see a simplified version of the to function:

infix fun Any.to(other: Any) = Pair(this, other)

Here, the function returns a Pair which is a Kotlin standard library class.

We can also initialize two variables with the contents of a Pair directly:

val (number, name) = 1 to "one"

This feature is called destructuring declaration.

We can use the destructuring declaration feature in for loop with a map for its keys and values, with collections in a loop to have the element and the index. Let's take a look at some code:

val (pairNumber, pairName) = 1 to "one"

val map = mapOf(1 to "one", 7 to "seven", 53 to "fifty-three")
for ((number, name) in map) {
    println("$number = $name")
}

val list = listOf("one", "seven", "fifty-three")
for ((index, element) in list.withIndex()) {
    println("index $index element is: $element")
}

Local Functions

Kotlin supports local functions: a function inside another function. A local function has access to the variables and parameters of the parent function. This feature is useful to remove duplicate code. As an example, if take a look at the code below, we can see that it has a duplicate code that can be removed:

fun saveUser(user: User) {
    if (user.name.isEmpty()) {
        throw IllegalArgumentException("Can't save user ${user.id}: empty Name")
    }
    if (user.address.isEmpty()) {
        throw IllegalArgumentException("Can't save user ${user.id}: empty Address")
    }
    // save the user to the database
}

We can extract the validation logic into a local function, and call that function within the parent function. It reduces the duplicate code, and if we want to change the logic, we can do it in just ONE place! Let's take a look at the code:

fun saveUser(user: User) {
    fun validate(value: String, fieldName: String) {
        if (value.isEmpty())
            throw IllegalArgumentException("Can't save user ${user.id}: empty $fieldName")
    }

    validate(user.name, "Name")
    validate(user.address, "Address")
}

As we can see, the local function has access to the parameters of the parent function!

To make the code even more tidy, we can make the saveUser() function an extension function(instead of being a part of the User class). This way, the class is not polluted with a code that is not a part of the class responsibility and not needed by most of the clients(here, just the repository class needs this function to save it to the database!).

This is the end of part 2 which was the summary of chapter 3. There were other parts in chapter 3 that I did not cover here because I felt they are not as important and they would have made the article too long. Anyhow, if you found this article useful, please like it and share it with other fellow developers. If you have any questions or suggestions, please feel free to comment. Thanks for your time.

Kotlin in Action Summary - Part 1

Mahdi Abolfazli — Tue, 09 Aug 2022 08:37:00 +0000

In this series, we will explore the most important topics in the Kotlin in Action book. Because this is just a summary of the book without the details, and to get the most of this series, I highly recommend that you read the book and after reading each chapter, you can read the corresponding article to review the concepts and material. This series is also great for developers who are getting ready for an interview. Because chapter 1 of the book is just some general information, we will skip this chapter and start from chapter 2 of the book. I will mention the page number after each section title, so you will be able to read the concept if it is not clear by the article. Let's dive in.

If you have already read this article or you feel you do not need to read this chapter, you can read part 2 here.

Functions

pages 18, 19

To declare a function, we use the fun keyword.
Functions can be declared at the top level of the file(outside the class).
Parameter types are written after the parameter name separated by a colon.
Return type of the function is written after the parameters' parentheses separated by a colon.
If function is a block expression, we can omit the return type and the curly braces(block expression is discussed later).

Statements vs Expressions

page 19

An expression has a value which can be used as a part of another expression.
A statement is a top-level element in its enclosing block and does not have its own value.
Most of Java statements can be used as expressions in Kotlin(if, try, when). Because if can be used as an expression in Kotlin, we do not have ternary operator(int k = booleanVariable ? 1 : 0;) that Java has.
Please bear in mind that if can be either used as an expression or statement in Kotlin. If it covers all the cases and assigned to a variable, it is an expression. Otherwise, it is a statement.

Expression Body vs Block Body

page 19

If a function returns a value directly without using the curly braces, it has an expression body. On the other hand, if the function has the curly braces, it has a block body.

Variables

pages 20, 21

Unlike Java, Kotlin does not require us to begin variable with their type because there are times we can omit the variable type(using the type inference capability of the Kotlin compiler).
We use val or var to declare variables in Kotlin. val is the shorthand for value and var is the shorthand for variable. As the names suggest, val is immutable and var is mutable.
NOTE: We should always use the val keyword and use the var if we really need to change the variable, then we should use the var.
NOTE: Although val creates an immutable variable, bear in mind that the object itself might be mutable.

val s = arrayListOf("hi")
s.add("hello")

String Templates

page 22

Kotlin supports String templates. We can declare a variable, then use it alongside with the dollar sign($) to mention it in strings.

val appleNumbers = 1100
println("there are $appleNumbers in the inventory")

NOTE: If we want to use the dollar sign itself in a string, we should escape it:

println("\$x")

This will print $x, not the value of a variable named x.

Classes and Properties

pages 23, 24, 25

class Person {
    val name: String,
    var isMarried: Boolean

Classes that contain only data and no other code are called value objects.

In Kotlin, public is the default visibility modifier.

In Java, the combination of a field and its accessors is often referred to as a property. In Kotlin, properties are supported by the language and replace fields and accessor methods.
When we declare a property as val, a field and a getter is generated for them. Whereas for the var properties, a field, a getter and a setter is generated.

When we call the property of an object, it seems like we are accessing it directly, but under the hood, we are accessing it via the getter method generated.
val person = Person("Bob", true)
println(person.name)
Bob
>>>print(person.isMarried)
true

There are cases when we do not need a backing field for a property. For example, if we can calculate the property from the value of other properties. We can declare a custom getter for such a property, and no backing field will be generated for that.

class Rectangle(val height: Int, val width: Int) {
    val isSquare: Boolean
        get() {
            return height == width
        }
}

In the code above, the compiler will not generate any backing field for the isSquare property.

Enums

pages 28, 29

enum class Color {
    RED, BLUE, YELLOW, GREEN
}

Enum is a rare case in Kotlin that uses more keywords than the Java's equivalent.

In Kotlin, enum is a soft keyword. It has a special meaning when it comes before class, but we can use it elsewhere in our code.

Enums are not just a list of values. We can declare methods and properties in enums.

enum class Color(
  val r: Int, val g: Int, val b: Int
) {
  RED(255, 0, 0), BLUE(0, 0, 255), YELLOW(255, 255, 0), 
    GREEN(0, 255, 0);

  fun rgb() = (r * 256 + g) * 256 + b
}

In the enum constructor, we have declared the properties of enum constants.
Semicolon is required if we declare methods in the enum.

When

pages 29, 30, 31

Like if, when is an expression that returns a value.
Unlike Java, when does not require us to write break after each case.

fun getWarmth(color: Color) =
  when (color) {
    Color.RED -> "warm"
    Color.BLUE -> "cold"
    Color.YELLOW -> "warm"
    Color.GREEN -> "neutral"
  }

We can combine multiple values in the same branch separated with a coma(,).

fun getWarmth(color: Color) =
  when (color) {
    Color.RED, Color.YELLOW -> "warm"
    Color.BLUE -> "cold"
    Color.GREEN -> "neutral"
  }

Unlike switch in Java which requires us to use constants(enums, strings, or number literals) as branch conditions, when in Kotlin allows us to use any objects.

fun mix(c1: Color, c2: Color) =
  when(setOf(c1, c2)) {
    setOf(RED, YELLOW) -> ORANGE
    setOf(BLUE, YELLOW) -> GREEN
    setOf(BLUE, VIOLET) -> INDIGO
    else -> throw Exception("Dirty color")
  }
}

Here we have used Set as the branch condition.

The previous example is not efficient because it creates a set for every invocation. We can instead use a when without an argument to accomplish the same result:

fun mixOptimized(c1: Color, c2: Color) =
  when {
    (c1 == RED && c2 = YELLOW) || 
    (c1 == YELLOW && c2 = RED)  -> ORANGE

    (c1 == BLUE && c2 = YELLOW) || 
    (c1 == YELLOW && c2 = BLUE) -> GREEN

    (c1 == BLUE && c2 = VIOLET) || 
    (c1 == VIOLET && c2 = BLUE) -> GREEN -> INDIGO
    else -> throw Exception("Dirty color")
  }
}

NOTE: If no argument is supplied for the when expression, the branch condition is any boolean expression.

Smart Casts

pages 31, 32, 33

To illustrate the casting mechanism in Kotlin, we will use an example in arithmetic expression. In this example, we will just use one operation: the sum of two numbers. Let's dive in:
First we declare an interface to have the same type for both a value and an expression of two values. Then, we implement the interface in two classes Sum and Num.

interface Expr
class Num(val value: Int) : Expr
class Sum(val left: Expr, val right: Expr) : Expr

NOTE: To implement an interface in a class, we use a colon after the class name, and then the interface name:

The Expr interface has two implementations, so we have two options:

If an expression is a number, we return the corresponding value.
If it's a sum, we have to evaluate the left and right expressions and return their sum.

First, let's see a simple implementation:

fun eval(e: Expr) : Int {
  if (e is Num) {
    val n = e as Num
    return n.value
  }
  if (e is Sum) {
    return eval(e.right) + eval(e.left)
  }
  throw IllegalArgumentException("unknown expression")
}

is vs instanceof
The is check in Kotlin is the same as the instanceof in Java. In Java, if we have checked a variable with the instanceof, we also have to cast it to the type. However in Kotlin, if we check a variable with the is check, it already can be used as the type we have checked with the is check. In effect, the compiler performs the cast for us(which is called smart cast).

NOTE: The smart cast works only if a variable could not have changed after the is check. For a property of a class, it must be val or it should not have a custom accessor!

Because we have the smart cast option in Kotlin, we can remove the cast in the above code.
We can also remove the curly braces and the return keywords, because in Kotlin if is an expression.
The result of the two above modifications is:

fun eval(e: Expr) =
  if (e is Num) {
    e.value
  } else if (e is Sum) {
    eval(e.right) + eval(e.left)
  } else
  throw IllegalArgumentException("unknown expression")

NOTE: Both if and when can have blocks. In this case, the last expression in the block is the result.

We can also replace the if branches with when:

fun eval(e: Expr) =
  when (e)  {
    is Num -> e.value
    is Sum -> eval(e.right) + eval(e.left)
   else -> throw IllegalArgumentException("unknown expression")
  }

The While Loop

page 35

The while and do while loop in Kotlin is the same as their corresponding loops in Java.

while (condition) {
  //while block
}

do {
  //do-while block
} while(condition)

For Loops and Ranges

pages 36, 37

Java for loop: We initialize a variable, update its value on every step in the loop, exit the loop when the value reaches a certain bound.
Kotlin introduced ranges to replace the common loop use-case.
Range: A range is an interval between two values, usually numbers: a start and an end. We write it using the .. operator.
NOTE: Ranges in Kotlin are closed or inclusive(the second value is always part of the range).

val oneToTen = 1..10
for (i in oneToTen) {
  println(i)
}

for (i in 1..10) {
  println(i)
}

In ranges, we can use downTo, step and until functions.
downTo: iterates backward in a loop
step: allows us to skip some numbers
until: allows us define a half-closed range(the last value is not included in the range)

for (i in 100 downTo 1 step 2) {
  println(i) //prints 100, 98, 96 ... 4, 2
}

for (i in 1 until 100) {
  println(i) //prints 1, 2, 3, ..., 98, 99
}

Iterating over Collections

pages 37, 38

The most common use-case of a for in loop is to iterate over a collection. Let's see how we can do this in Kotlin.

At first, we will see how to use the for loop to iterate through a map:

val binaryReps = TreeMap<Char, String>()
//here we will create a range of characters
for (c in 'A'..'F') {
  val binary = Integer.toBinary(c.toInt())
  //put each binary character in the map
  binaryReps[c] = binary
}

//iterating through the map
for ((letter, binary) in binaryReps) {
  println("$letter = $binary")
}

In the above code, we can see that the range function not only works for numbers, but also works fine for characters.
We can also see that we are unpacking the elements of a collection to iterate over them. In the case of maps, we should unpack it into two variables: one for the key the other for the value.

NOTE: As we can see, we are using the shorthand version of accessing and updating the map values. We use the map[key] = value instead of using the get and put functions:
map[key] = value

We can also iterate through a collection and keep track of the index of the current item:

val list = arrayListOf("10", "11", "1001")
//here we iterate through each element in the list
for (element in list) {
    println("$element")
}

//here we iterate through each element in the list and keep the index of current element
for ((index, element) in list.withIndex()) {
    println("$index: $element")
}

The in operator

pages 38, 39

We can use the in operator to check whether a value is in a range, or its opposite, !in, to check whether a value is NOT in a range:

fun isLetter(c: Char) = c in 'a'..'z' || c in 'A'..'Z'

fun isNotDigit(c: Char) = c !in '0'..'9'

The in and !in operators also work in when expressions:

fun recognize(c: Char) = when (c) {
    in '0'..'9' -> "It's a digit!"
    in 'a'..'z' , in 'A'..'Z' -> "It's a letter!"
    else -> "I don't know!"
}

NOTE: Ranges are not restricted to the characters either. If you have any class that supports comparing instances (by implementing the java.lang.Comparable interface), you can create ranges of objects of that type. But keep in mind that you cannot enumerate all objects in the range.

Exceptions

pages 39, 40

Exception handling Kotlin is similar to Java. A function can complete in a normal way, or throw an exception. Either the caller catches and handles the exception, or the exception propagates and is rethrown further up the stack.
Unlike Java, in Kotlin the throw construct is an expression and can be used as a part of other expressions:

val percentage =
    if (number in 0..100)
        number
    else
        throw java.lang.IllegalArgumentException("Illegal percentage value")

try, catch, and finally

pages 40, 41

Just like Java, we can use the try with catch and finally blocks.

fun readNumber(reader: BufferedReader): Int? {
    try {
        val line = reader.readLine()
        return Integer.parseInt(line)
    } catch (e: java.lang.NumberFormatException) {
        return null
    } finally {
        reader.close()
    }
}

The biggest difference in exception handling between Java and Kotlin is that throws clause is NOT present in the code because Kotlin does not differentiates between checked and unchecked exceptions.

try as an Expression

pages 41, 42

The try keyword in Kotlin, just like if and when, introduces an expression, and you can assign it to a variable. Unlike if, you have to enclose the try statement body in curly braces.

fun readNumber(reader: BufferedReader) {
    val number = try {
        val line = reader.readLine()
        Integer.parseInt(line)
    } catch (e: java.lang.NumberFormatException) {
        null
    }
}

If the execution of a try block behaves normally, the last expression in the block is the result. If an exception is caught, the last expression in a corresponding catch block is the result.

This is the end of part 1 which was the summary of chapter 2. There were other parts in chapter 2 that I did not cover here because I felt they are not as important and they would have made the article too long. Anyhow, if you found this article useful, please like it and share it with other fellow developers. If you have any questions or suggestions, please feel free to comment. Thanks for your time.

Here is the link to part 2 of this series.

Forem: Mahdi Abolfazli

Kotlin in Action Summary - Part 3

Contents

Interfaces

pages 68, 69, 70

Open, Final and Abstract Modifiers

pages 70, 71, 72

Visibility Modifiers

pages 73, 74

Inner and Nested Classes

pages 75, 76,

Sealed Classes

pages 77, 78

Constructors and Properties

pages 79, 80, 81, 82, 83, 84, 85, 86

Primary Constructors

pages 79, 80, 81

Secondary Constructors

pages 81, 82, 83

Properties in Interfaces

pages 83, 84

Accessing Backing Fields

page 85

Changing Accessor Visibility

page 86

Universal Object Methods

pages 87, 88, 89

toString()

equals()

hashCode()

Data Classes

pages 89, 90, 91

copy() Method

Class Delegation

The object Keyword

pages 93, 94, 95, 96, 97, 98, 99, 100, 101

Object Declaration

pages 93, 94, 95

Companion Objects

pages 96, 97, 98, 99, 100

Companion Objects Extension

Object Expressions

Create alias in mac zsh

Algorithms Part 1 - Bags, Queues and Stacks

Introduction

Bags, Queues and Stacks

Bag

Queue

Stack

Implementing Collections

Fixed-Capacity Stack

Kotlin in Action Summary - Part 2

Creating Collections

Named Arguments

Default Parameter Values

Default Values and Java

Top-Level Functions and Properties

Top-Level Properties

Extension Functions

Importing Extension Functions

Extension Functions Under the Hood

Utility Functions as Extensions

Extension Properties

Varargs

Infix Calls

Local Functions

Kotlin in Action Summary - Part 1

Functions

pages 18, 19

Statements vs Expressions

page 19

Expression Body vs Block Body

page 19

Variables

pages 20, 21

String Templates

page 22

Classes and Properties

pages 23, 24, 25

Enums

`copy()` Method

The `object` Keyword