Effective Kotlin

Platform type - a type that comes from another language and has unknown nullability.

public class UserRepo {
  public User getUser() {
    //...
  }
}

val repo = UserRepo()
val user1 = repo.user        // Type of user1 is User!
val user2: User = repo.user  // Type of user2 is User
val user3: User? = repo.user // Type of user3 is User?

What're the differences between User! and User?

If we are not sure about the type, we should specify it. In an external API, we should always specify types. We cannot let them be changed by accident. Inferred types can be too restrictive or can too easily change when our project envolves.

• require block: a universal way to specify expectations on arguments.
• check block: a universal way to specify expectations on the state.
• assert block: a universal way to check if something is true in testing mode for our own implementation.
• Elvis operator(?:) with return or throw.

Properties are essentially functions, we can make extension properties as well:

val Context.preferences: SharedPreferences
  get() = PreferencesManager
    .getDefaultSharedPreferences(this)

Properties represent accessors, not fields. The general rule is that we should use them only to represent or set state, and no other logic should be involved. If I would define a property as a function, would I prefix it with get/set? If not, it should rather not be a property.

The most typical situations when we should not use properties, and we should use functions instead:

• Operation is computationally expensive or has computational complexity higher than O(1)
• It involves business logic
• It is not deterministic: Calling the member twice in succession produces different results.
• It is a conversion, such as Int.toDouble()
• Getters should not change property state

The biggest enemy of changes is knowledge repetition.

Are they more likely going to change together or separately?

Version names, documentation, and annotations.

When the behavior is not documented and the element name is not clear, developers will depend on current implementation instead of on the abstraction we intended to create.

When a contract is well specified, creators do not need to worry about how the class is used, and users do not need to worry about how something is implemented under the hood.

• Unlike constructors, functions have names.
• Unlike constructors, functions can return an object of any subtype of their return type.
• Unlike constructors, functions are not required to create a new object each time they're invoked.
• Factory functions can provide objects that might not yet exist.
• When we define a factory function outside of an object, we can control its visibility.
• Factory functions can be inline and so their type parameters can be reified.
• Factory functions can construct objects which might otherwise be complicated to construct.
• A constructor needs to immediately call a constructor of a superclass or a primary constructor. When we use factory functions, we can postpone constructor usage.

Factory functions are mainly a competition to secondary constructors.

val dialog = context.alert(R.string.fire_missiles) {
  positiveButton(R.string.fire) { fire() }
  negativeButton { cancel() }
}

val route = router {
  "/home" directsTo ::showHome
  "/settings" directsTo ::showSettings
}

These kinds of DSL builders are generally preferred over classic builder pattern, since they give more flexibility and cleaner notation.

sealed classes

The biggest difference between members and extensions in terms of use is that extensions need to be imported separately.

Extenstions are not virtual, they cannot be redefined in derived classes.

We define extensions on types, not on classes. For instance, we can define an extension on a nullable or a concrete substitution of a generic type.

fun Iterable<Int>.sum(): Int {
    var sum = 0
    for (i in this) {
        sum += i
    }
    return sum
}

Extensions are not listed as members in the class reference. This is why they are not considered by annotation processors and why, when we process a class using annotation processing, we cannot extract elements that should be processed into extension functions.

In local scope we generally do not need the control over how they are changed, so mutable collections should be preferred. Especially in utils, where element insertion might happen many times.