Architecture Patterns in the Realm SDK
You've bravely re-architected your app and brought it into the world of modern Android! Realm's logic and separation of concerns follow a similar pattern.
My name is Francisco Paco Esteres, and this is a talk about types, and about the way that you use them in while developing in Kotlin.
Classic Object Oriented Programming / Data (0:41)
Classic object oriented programming tells you that classes encapsulate both data and behavior.
When representing data in Java, because classes have to adhere to certain standards, you have the possibility of having null fields, constructors, or empty constructor with all the values.
There’s also the issue with immutability. As we’re moving toward a more multi-threaded paradigm, if there are mutable models, and they are shared among threads, you have cases where it’s inconsistent.
A type is a finite set of encapsulated operations. It defines a representation of either a value or a behavior associated with values. This can be represented with classes, and some need language support. The most important part is that they can be checked at compile time.
Types Available in Kotlin (4:02)
In Kotlin, there is type coercion, meaning everything is not implicit. You cannot add to the sum of an integer and a float, or divide an integer and a float in a way that you have an unexpected behavior.
There is no distinction between base types and wrapped types. Everything happens behind the scenes, and only a single type is needed.
Functions are runtime objects, and they have first class support in Kotlin. You can have a function class that is like a value or a variable that’s sent around an application. You can create instances of every function or every method using the operator
Suppose there’s a User Manager class, and there’s a
get in that class you want to use elsewhere. You set the
:: to create an instance.
Collections and combinators (6:20)
Collections and combinators have any loose types, array, map, sets. These are an implementation on top of the original Java classes and are interoperable with Java.
There are two types of collections: mutable and immutable. In Java, when a method is called on an immutable collection, you’ll get an exception. Because of this, we have separate interfaces for mutable and immutable lists.
To illustrate this, create an immutable collection by using
listOf, and if you use
immutableCollection and call
add, you’ll get an error that states
add is not a valid operation.
Immutable collections have operations such as map or filter. You’re able to pass a function that transforms from one to the other, and as a result, the function will have a lambda.
With data classes, you are able to pass any number of values into the constructor, any number of parameters, and those parameters become the fills inside the class.
Because of the type system in Kotlin, there’s a difference between nullable and none nullable types. Every type that has a question mark at the end is defined as nullable.
It’s possible to instatiate a class with select values. For example, if there’s a class that has name, age, and location as properties, a new instance that may only have the location and name. A constructive pattern can be built into the object directly for this.
For enums, each are assigned a value and a position, and you can also access each one of the elements through reflection.
Sealed classes (16:17)
Though sealed classes are not available in Java, it’s not a new concept. It is something that already existed in other languages. They have been described as union types, Archer break data types, or tack unions; the only variation is the implementation for them.
With sealed classes, you’re trying to define your execution in a context that is checked by your compilers, and separate data from general behavior.