Now that almost all Android developers have switched from Java to Kotlin, they are finding how much easier, cleaner, and more concise Kotlin is than Java. Kotlin introduces a number of developer-friendly features for less code, reducing the number of problems.

Kotlin is a modern, concise and powerful programming language that has gained immense popularity in recent years. One of the reasons for its success is its support for functional programming concepts. In this blog, we will explore important higher-order functions in Kotlin: let, run, also and apply.

The let function

The let function is a higher-order function that takes a lambda expression as an argument and executes it with the value of the calling object as its argument. The result of the lambda expression is then returned. Let's take a look at an example:

val name: String? = "John Doe"

val result = name?.let {
    "Hello, $it!"
} ?: "Unknown"

println(result) // Output: Hello, John Doe!

In this example, we use the safe call operator to ensure that the let function is only called if the name variable is not null. The lambda expression in the let function concatenates the string "Hello, " with the value of it, which is the non-null value of name. If name is null, the ?: operator returns the default value of "Unknown".

The run function

The run function is similar to the let function in that it takes a lambda expression as an argument and executes it with the value of the calling object as its argument. However, the difference is that the run function does not return the result of the lambda expression, but instead returns the calling object itself. Here's an example:

val numbers = mutableListOf<Int>(1, 2, 3, 4)

val sum = numbers.run {
    add(5)
    add(6)
    sum()
}

println(sum) // Output: 21

In this example, we use the run function to add two numbers to the numbers list and then calculate the sum of all the elements in the list using the sum() function. The result of the sum() function is returned by the run function, but since it doesn't matter in this case, we ignore it.

The also function

The also function is similar to the let function in that it takes a lambda expression as an argument and executes it with the value of the calling object as its argument. However, the difference is that the also function does not return the result of the lambda expression, but instead returns the calling object itself. Here's an example:

val message = "Hello, World!"

val result = message.also {
    println(it)
}.length

println(result) // Output: 13

In this example, we use the also function to print the value of the message variable and then return its length. The it parameter in the lambda expression refers to the value of the message variable. Since the also function returns the calling object, we can chain other functions after it.

The apply function

The apply function is similar to the run function in that it takes a lambda expression as an argument and executes it with the value of the calling object as its argument. However, the difference is that the apply function returns the calling object itself, rather than the result of the lambda expression. Here's an example:

class Person(var name: String, var age: Int)

val person = Person("John Doe", 30).apply {
    age += 1
}

println(person.age) // Output: 31

In this example, we use the apply function to create a Person object with the name "John Doe" and the age 30. We then use the apply function to increment the age of the person object by 1. Since the apply function returns

All there is to know about Kotlin's Scoped functions. We hope that our blog has provided you with a greater understanding of and a method for constructing the proper scoped function in the right place, even though we may be using this in our code.

I greatly thank you for your time.

If you want to read more content like this, please go check out my profile.

Mansi Vaghela LinkedIn Twitter Github Youtube

In Kotlin, there are two ways to initialize a property that is not available at the time of object creation: lateinit and lazy. Both of these keywords allow you to postpone the initialization of a property until it is actually needed, but they work in slightly different ways. In this blog, we will compare and contrast lateinit vs lazy and discuss when to use each.

lateinit

lateinit is a keyword that allows you to declare a non-null property without initializing it immediately. You can then initialize the property at a later time, as long as you do so before you try to access it. The most common use case for lateinit is when we are working with dependency injection frameworks like Dagger or Koin, where the initialization of certain properties might be deferred until runtime.

lateinit var myObject: MyObject

fun initializeMyObject() {
    myObject = MyObject()
}

There are a few things to keep in mind when using lateinit:

• The property must be a non-null type, or else you'll get a compilation error.

• You can only use lateinit with properties that are declared at the class level (i.e., not local variables).

• If you try to access a lateinit property before it has been initialized, you'll get a lateinit exception at runtime.

lazy

lazy is a keyword that allows you to declare a property whose initialization is deferred until the first time it is accessed. The property is then cached, so subsequent accesses to the property will return the same value without re-initializing it. This is useful when you have expensive initialization logic that you don't want to perform unnecessarily.

val myObject: MyObject by lazy {
    MyObject()
}

When using lazy, you should keep the following in mind:

• The property must be declared with val, not var.

• You can only use lazy with properties that are declared at the class level (i.e., not local variables).

• The initialization logic should be thread-safe, as lazy properties are only initialized once and can be accessed by multiple threads.

When to use each

So, when should we use lateinit vs lazy? Here are some guidelines:

• Use lateinit when we need to declare a non-null property that cannot be initialized immediately, but we know it will be initialized before it is accessed. For example, if we are working with a dependency injection framework, we might use lateinit for properties that are injected at runtime.

• Use lazy when we need to declare a property that might not be accessed immediately, and we want to avoid unnecessary initialization. For example, if we have an expensive operation that calculates a property value, we might use lazy to ensure that it is only calculated when it is actually needed.

In summary, lateinit and lazy are two powerful tools that can help you write cleaner and more efficient Kotlin code. By understanding the differences between the two and knowing when to use each, we can write code that is both more correct and more performant.

If you want to read more content like this, please go check out my profile.

Mansi Vaghela LinkedIn Twitter Github Youtube

I want to share some extension functions to make your experience with the Firebase Database a little more comfortable with Kotlin.

We are going to make reusable code that is also going to avoid the need for callbacks and take advantage of suspend functions.

Mapping operations

Here is a function to cast the value of every node in the database to whatever object you need. Thanks to the reified and inline keywords, you can make this transformation in one line with clear looking code.

// This would be called like so, snapshot.toDomain<String>()

inline fun <reified T> DataSnapshot.toDomain(): T? = getValue(T::class.java)

Read operations

For one-shot read operations, you can use the following function. In all the methods that you are going to see in this post, an exception is going to be thrown if the operation fails, so take that into account when using them.

suspend fun DatabaseReference.read(): DataSnapshot = suspendCoroutine { continuation ->
    val valueEventListener = object : ValueEventListener {
        override fun onCancelled(error: DatabaseError) {
            continuation.resumeWithException(error.toException())
        }

        override fun onDataChange(snapshot: DataSnapshot) {
            continuation.resume(snapshot)
        }
    }
    addListenerForSingleValueEvent(valueEventListener)
}

To subscribe to changes in the database, we have the following function that listen to node children, returns a Flow than be collected every time a node creation happens.

To make it a little more interesting, I made it so that you can pass it a mapper function instead of doing the mapping outside.

/* This function can be called like 
 * subscribeModifiedChildren(DataSnapshot::toBoolean)
 * where toBoolean is 
 * fun toBoolean() = toDomain<Boolean>() ?: false
 */

suspend fun <T> DatabaseReference.subscribeNewChildren(
    mapper: DataSnapshot.() -> T
): Flow<T> = callbackFlow {
    val childEventListener = object : ChildEventListener {
        override fun onChildAdded(snapshot: DataSnapshot, previousChildName: String?) {
            trySend(snapshot.mapper())
        }

        override fun onChildChanged(snapshot: DataSnapshot, previousChildName: String?) {}

        override fun onChildRemoved(snapshot: DataSnapshot) {}

        override fun onChildMoved(snapshot: DataSnapshot, previousChildName: String?) {}

        override fun onCancelled(error: DatabaseError) {}
    }
    addChildEventListener(childEventListener)
    awaitClose {
        removeEventListener(childEventListener)
    }
}

In this next method, we have the same idea as above, but now we are listening changes to a specific node.

@OptIn(InternalCoroutinesApi::class)
suspend fun <T> DatabaseReference.subscribeModifiedChildren(
    mapper: DataSnapshot.() -> T
): Flow<T> = callbackFlow {
    val valueEventListener = object : ValueEventListener {
        override fun onCancelled(error: DatabaseError) {
            handleCoroutineException(coroutineContext, error.toException())
        }

        override fun onDataChange(snapshot: DataSnapshot) {
            trySend(snapshot.mapper())
        }
    }
    addValueEventListener(valueEventListener)
    awaitClose {
        removeEventListener(valueEventListener)
    }
}

For queries, we do exactly the same as the read operation, but we extend from the Query object.

suspend fun Query.read(): DataSnapshot = suspendCoroutine { continuation ->
    val valueEventListener = object : ValueEventListener {
        override fun onCancelled(error: DatabaseError) {
            continuation.resumeWithException(error.toException())
        }

        override fun onDataChange(snapshot: DataSnapshot) {
            continuation.resume(snapshot)
        }
    }
    addListenerForSingleValueEvent(valueEventListener)
}

Write operations

The write operation uses the suspendCoroutine again, but now we called the setValue method provided by the Firebase SDK.

suspend fun <T> DatabaseReference.write(data: T) {
    suspendCoroutine { continuation ->
        setValue(data)
            .addOnSuccessListener {
                continuation.resume(Unit)
            }
            .addOnFailureListener {
                continuation.resumeWithException(it)
            }
    }
}

In case you want to get a node or create it if it doesn’t exist, you have the following functions. This is pretty useful, for example, if you need to add a new node when a user is trying to register in your app, but he did sign up before and didn’t remember.

suspend inline fun <reified T> DatabaseReference.getOrCreate(data: T): DataSnapshot =
    suspendCoroutine { continuation ->
        val transactionHandler = object : Transaction.Handler {
            override fun doTransaction(currentData: MutableData): Transaction.Result {
                return if (currentData.getValue<Any>() != null) {
                    Transaction.success(currentData)
                } else {
                    currentData.value = data
                    Transaction.success(currentData)
                }
            }

            override fun onComplete(
                error: DatabaseError?,
                committed: Boolean,
                currentData: DataSnapshot?
            ) {
                if (committed && currentData != null) {
                    continuation.resume(currentData)
                } else {
                    error?.let { throw error.toException() }
                }
            }
        }
        runTransaction(transactionHandler)
    }

Delete operations

To finish, here is a delete operation. We are going to follow the same technique used in the write function, so that we can know if the operation was completed successfully or if we need to manage the error.

suspend fun DatabaseReference.delete() {
    suspendCoroutine { continuation ->
        removeValue()
            .addOnSuccessListener {
                continuation.resume(Unit)
            }
            .addOnFailureListener {
                continuation.resumeWithException(it)
            }
    }
}

If you want to read more content like this, please go check out my profile.

Mansi Vaghela LinkedIn Twitter Github Youtube

Although there is something that works a bit differently when setting up Dagger in Kotlin, most of it is quite simple, and in a few steps I’m going to show you here today.

Also be aware that, thanks to the power of Kotlin, there are other ways to solve the injection, and even some libraries made exclusively in Kotlin for it.

But Dagger is still a viable option and one of the most versatile (if not the most).

Configuring the project to use Dagger 2

If you’ve already configured the Kotlin plugin in your project, all you need to do is configure kapt.

If you already used Dagger, you probably know apt. kapt is just the version for Kotlin, which creates the necessary self-generated classes for Dagger.

To configure it, you need to add the following to build.gradle:

kapt {
    generateStubs = true
}

You can add it just before the dependencies section. If you want, you can instead use the new experimental plugin, which is pretty stable already:

apply plugin: 'kotlin-kapt'

Now you just need to add the dependencies of the Dagger compiler (using kapt to not be included in the apk) and the actual library:

kapt 'com.google.dagger:dagger-compiler:2.5'
compile 'com.google.dagger:dagger:2.5'

Everything is ready to start using Dagger.

Main module implementation

As you may know, for the main graph you’ll need a Module and a Component.

The application module, in this simple example, will only return the instance of the application itself.

To do this we’ll create a class annotated with @Module, which will receive the application instance via constructor, store it in a property, and return it using a method annotated with @Provides @Singleton:

@Module class AppModule(val app: App) {
    @Provides @Singleton fun provideApp() = app
}

You can see that, even for this easy class, the code is much simpler than in Java.

Now we have to implement the Component, which needs an array of modules to load, and specifies who is going to be able to manually inject it:

@Singleton
@Component(modules = arrayOf(AppModule::class))
interface AppComponent {
    fun inject(app: App)
}

Just create the class App, which will be responsible of generating the graph:

class App : Application() {

    val component: AppComponent by lazy {
        DaggerAppComponent
                .builder()
                .appModule(AppModule(this))
                .build()
    }

    override fun onCreate() {
        super.onCreate()
        component.inject(this)
    }
}

The interesting thing to see here is that, thanks to the lazy statement, we can specify the value of the graph in the definition of the property, and thus get read-only access to that property.

The code defined by the property won’t be executed until component.inject (this) is done, so that by that time this already exists and can be created securely way.

One module implementation per scope

The modules by scope allow that part of the graph only to live during the lifetime of the object that creates it.

In this way, we can create subgraphs that live and die with an Activity, for example.

We would create our module with what we need:

@Module
class HomeModule(val activity: HomeActivity) {
}

A Subcomponent in a very similar way to the previous one, indicating that it’ll be injected into the HomeActivity:

@Singleton
@Subcomponent(modules = arrayOf(HomeModule::class))
interface HomeComponent {
    fun inject(activity: HomeActivity)
}

And a plus method in AppComponent, to indicate that this component can be added subcomponents of that type:

interface AppComponent {
    ...
    fun plus(homeModule: HomeModule): HomeComponent
}

Now, in the HomeActivity you only need to declare the subcomponent:

val component by lazy { app.component.plus(HomeModule(this)) }

And you can inject it after the setContentView:

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)
    component.inject(this)
}

If you’re wondering where app comes from, it’s a extension property that looks like this:

val Activity.app: App
    get() = application as App

It’s simply a way to avoid having to do casting every time you access application if you have your own custom one.

Conclusion

Dagger 2 is also easy to use in Kotlin. You no longer have an excuse to implement a great decoupled architecture in Kotlin.

Mansi Vaghela LinkedIn Twitter Github Youtube

Why do we need these patterns?

Adding everything to a single activity or fragment would lead to problems in testing and refactoring the code. Hence, the use of separation of code and clean architecture is recommended.

Model—View—ViewModel (MVVM) is the industry-recognized software architecture pattern that overcomes all the drawbacks of MVP and MVC design patterns. MVVM suggests separating the data presentation logic (views or UI) from the core business logic part of the application.

The separate code layers of MVVM are:

• Model: This holds the data of the application. It cannot directly talk to the View. Generally, it’s recommended to expose the data to the ViewModel through Observables.

• View: It represents the UI of the application devoid of any Application Logic. It observes the ViewModel.

• ViewModel: It acts as a link between the Model and the View. It’s responsible for transforming the data from the Model. It provides data streams to the View. It also uses hooks or callbacks to update the View. It’ll ask for the data from the Model.

The following flow illustrates the core MVVM pattern.

The MVVM pattern has some similarities with the MVP (Model—View—Presenter) design pattern, as the presenter role is played by ViewModel. However, the drawbacks of the MVP pattern have been solved by MVVM in the following ways:

• ViewModel does not hold any kind of reference to the View.

• Many to-1 relationships exist between View and ViewModel.

• No triggering methods to update the View.

There are two ways to implement MVVM in Android:

• Data Binding

• RXJava

Here, we’ll be using data binding only. Google introduced the Data Binding Library in order to bind data directly in the XML layout. We’ll be creating a simple login page example application that asks for user inputs. We’ll see how the ViewModel notifies the View when to show a toast message without keeping a reference to the View.

How is it possible to notify a class without having a reference to it? It can be done in three different ways:

• Using Two Way Data Binding

• Using Live Data

• Using RxJava

Two Way Data Binding

Two-way Data Binding is a technique of binding your objects to your XML layouts such that the Object and the layout can both send data to each other. In our case, the ViewModel can send data to the layout and also observe changes. For this, we need a BindingAdapter and custom attribute defined in the XML. The binding adapter would listen to changes in the attribute property. This point can be visualized by the example in this tutorial.

Syntax for the two way data binding is @={variable}

Adding the Data Binding Library

Add the following code to your app’s build.gradle file:

android {
    dataBinding {
        enabled = true
    }
}

This enables data binding in your application.

Adding the Dependencies

Add the following dependencies to your build.gradle file :

implementation 'android.arch.lifecycle:extensions:1.1.1'

Data Class

The data class would hold the user’s email and password. The following User.kt class does it:

package com.dev.androidmvvmbasics.model

data class User(
    var email: String,
    var password: String
)

Two-way Data Binding allows us to bind objects in the XML layouts such that the object can send data to the layout, and vice versa. The Syntax for two way data binding is @={variable}

Layout

The code for the activity_main.xml is given below:

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="https://schemas.android.com/apk/res/android"
    xmlns:bind="https://schemas.android.com/tools">

    <data>

        <variable
            name="viewModel"
            type="com.dev.androidmvvmbasics.viewmodels.LoginViewModel" />
    </data>


    <androidx.core.widget.NestedScrollView
        android:layout_width="match_parent"
        android:layout_height="match_parent">

        <LinearLayout
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:layout_gravity="center"
            android:layout_margin="8dp"
            android:orientation="vertical">

            <EditText
                android:id="@+id/etEmail"
                android:layout_width="match_parent"
                android:layout_height="wrap_content"
                android:hint="Email"
                android:inputType="textEmailAddress"
                android:padding="8dp"
                android:text="@={viewModel.userEmail}" />

            <EditText
                android:id="@+id/etPassword"
                android:layout_width="match_parent"
                android:layout_height="wrap_content"
                android:hint="Password"
                android:inputType="textPassword"
                android:padding="8dp"
                android:text="@={viewModel.userPassword}" />


            <Button
                android:layout_width="match_parent"
                android:layout_height="wrap_content"
                android:layout_marginTop="8dp"
                android:onClick="@{()-> viewModel.onLoginClicked()}"
                android:text="LOGIN"
                bind:toastMessage="@{viewModel.toastMessage}" />
        </LinearLayout>
    </androidx.core.widget.NestedScrollView>
</layout>

Data Binding requires us to set the layout tag at the top. Here our ViewModel binds the data to the View. ()-> viewModel.onLoginClicked() invokes the Button click listener lambda defined in our ViewModel. The EditText updates the values in the Model (via View Model). bind:toastMessage="@{viewModel.toastMessage}" is a custom attribute we’ve created for two-way data binding. Based on changes in the toastMessage in the ViewModel the BindingAdapter would get triggered in the View.

ViewModel

The code for the LoginViewModel.kt is given below:

package com.dev.androidmvvmbasics.viewmodels

import android.databinding.BaseObservable
import android.databinding.Bindable
import android.text.TextUtils
import android.util.Patterns

import com.android.databinding.library.baseAdapters.BR
import com.dev.androidmvvmbasics.model.User

class LoginViewModel : BaseObservable() {
    private val user : User
    private val successMessage = "Login was successful"
    private val errorMessage = "Email or Password not valid"
    @Bindable var toastMessage : String? = null
        private set

    private fun setToastMessage(toastMessage : String) {
        this.toastMessage = toastMessage
        notifyPropertyChanged(BR.toastMessage)
    }

    @get:Bindable var userEmail : String?
        get() = user.getEmail()
        set(email) {
            user.setEmail(email)
            notifyPropertyChanged(BR.userEmail)
        }
    @get:Bindable var userPassword : String?
        get() = user.getPassword()
        set(password) {
            user.setPassword(password)
            notifyPropertyChanged(BR.userPassword)
        }

    init {
        user = User("", "")
    }

    fun onLoginClicked() {
        if (isInputDataValid) setToastMessage(successMessage) else setToastMessage(errorMessage)
    }

    val isInputDataValid : Boolean
        get() = !TextUtils.isEmpty(userEmail) && Patterns.EMAIL_ADDRESS.matcher(userEmail)
                .matches() && userPassword!!.length > 5
}

The methods called for in the layout are implemented in the above code with the same signature. If the XML counterpart of the method doesn’t exist, we need to change the attribute to app:. The above class can also extend ViewModel. But we need BaseObservable since it converts the data into streams and notifies us when the toastMessage property is changed. We need to define the getter and setter for the toastMessage custom attribute defined in the XML. Inside the setter, we notify the observer (which will be the view in our application) that the data has changed. The view (our activity) can define the appropriate action.

BR class is auto-generated from data binding when you rebuild the project

The code for the MainActivity.kt class is given below:

package com.dev.androidmvvmbasics.views

import android.databinding.BindingAdapter
import android.databinding.DataBindingUtil
import android.support.v7.app.AppCompatActivity
import android.os.Bundle
import android.view.View
import android.widget.Toast
import com.dev.androidmvvmbasics.R
import com.dev.androidmvvmbasics.databinding.ActivityMainBinding
import com.dev.androidmvvmbasics.viewmodels.LoginViewModel


class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState : Bundle?) {
        super.onCreate(savedInstanceState)
        val activityMainBinding : ActivityMainBinding = DataBindingUtil.setContentView(this, R.layout.activity_main)
        activityMainBinding.setViewModel(LoginViewModel())
        activityMainBinding.executePendingBindings()
    }

    companion object {
        @BindingAdapter("toastMessage") fun runMe(view : View, message : String?) {
            if (message != null) Toast.makeText(view.getContext(), message, Toast.LENGTH_SHORT)
                    .show()
        }
    }
}

Thanks to DataBinding, the ActivityMainBinding class is auto-generated from the layout. The @BindingAdapter method gets triggered whenever the toastMessage attribute defined on the Button is changed. It must use the same attribute as defined in the XML and in the ViewModel. So in the above application, the ViewModel updates the Model by listening to the changes in the View. Also, the Model can update the view via the ViewModel using the notifyPropertyChanged.

More information will be available on the below official page:
https://developer.chrome.com/multidevice/android/customtabs

Mansi Vaghela LinkedIn Twitter Github Youtube

Chrome Custom Tabs are now generally available to all users of Chrome, on all of Chrome’s supported Android versions (Jellybean onwards).

Chrome Custom Tabs allow an app to customize how Chrome looks and feels. An app can change things like:

• Toolbar color

• Enter and exit animations

• Add custom actions to the Chrome toolbar, overflow menu and bottom toolbar

Launching links in custom tabs is faster than Chrome and WebView.

Implementation:
First, add a custom tab library to the build.gradle file.

dependencies { 

        … 
        implementation 'androidx.browser:browser:1.3.0'

}

Then, start url with custom tabs in your code

val url = "https://hashnode.com/@mansivaghela"                         
val builder = CustomTabsIntent.Builder()
var customTabsIntent :CustomTabsIntent  = builder.build();
customTabsIntent.launchUrl(requireContext(), Uri.parse(url))

after this you can customize tabs based on your needs.

More information will be available in below official Chrome page:
https://developer.chrome.com/multidevice/android/customtabs

Mansi Vaghela LinkedIn Twitter Github Youtube

val:
A variable declared with the val keyword is read-only (immutable). It cannot be reassigned after it is initialized.

val name = "Kotlin"
name = "Language" //Error: val can not be reassigned

It is similar to the final variable in Java.

var:
Variable declared using var keyword is mutable. It can be reassigned after it is initialized.

val name = "Kotlin"
name = "Language" //No error. It works

It is similar to regular variable in Java.

Type inference:
In Kotlin, it is not mandatory to explicitly specify the type of variable that you declare. The Kotlin compiler will automatically infer the type of the variable from the initialized section.

val name = "Kotlin" // type infered as "String"
val value = 100 //type infered as "Int"

You can also explicitly define the type of the variable.

val name: String = "Kotlin"
val value: Int = 100

Type of the variable declaration mandatory if you dont initialize the variable.

val name // Error: variable must either have a Type annotation or be initialized
name = "Kotlin"

You can also declare something like this.

val name: String //works
name = "Kotlin"

Mansi Vaghela LinkedIn Twitter Github Youtube

• Null references are controlled by the type system.

• No raw types

• Arrays in Kotlin are invariant

• Kotlin has proper function types, as opposed to Java’s SAM-conversions

• Use-site variance without wildcards

• Kotlin does not have checked exceptions

Java has below that kotlin does not have

• Checked exceptions

• Primitive types that are not classes

• Static members

• Non-private fields

• Wildcard-types

• Ternary-operator a ? b : c

What Kotlin has that Java does not

• Lambda expressions + Inline functions

• Extension functions

• Null-safety

• Smart casts

• String templates

• Properties

• Primary constructors

• First-class delegation

• Type inference for variable and property types

• Singletons

• Declaration-site variance & Type projections

• Range expressions

• Operator overloading

• Companion objects

• Data classes

• Separate interfaces for read-only and mutable collections

• Coroutines

Mansi Vaghela LinkedIn Twitter Github Youtube

In this article, we will figure out what exactly SOLID principles are and, most importantly, we will check out a few Kotlin examples to get an even better understanding. SOLID is an acronym for five design principles in Object-Oriented software development intended to make software designs more understandable, flexible and maintainable. These five principles are described by Robert C. Martin.

SOLID principles are briefly as follows:

• S — Single Responsibility Principle (known as SRP)

• O — Open/Closed Principle

• L — Liskov’s Substitution Principle

• I — Interface Segregation Principle

• D — Dependency Inversion Principle

1. Single-Responsibility Principle

The single-responsibility principle states:

A class should have only one reason to change.

The Single Responsibility Principle indicates that every class should have one and only one responsibility. In other words, if our class does more than one responsibility, we should split the functionalities and responsibilities in various classes. Therefore, this makes the class more robust.

With all of that in mind, let’s see the following example:

class User(
  val id: Int,
  val name: String,
  val email: String,
  val phoneNumber: String
)
class AdminDashboardService {
  fun sendNotification(user: User) {
    println("Preparing email content")
    println("Sending email to ${user.email}")
  }
  fun deleteUser(user: User) {
    println("Deleting user with id ${user.id} from the database")
  }
}

For the purpose of simplicity, the above functions are just printing some text to the output. Nevertheless, in the real-life scenarios the sendNotification() would be responsible for preparing an HTML content for the email and sending it to the given email address. On the other hand, the deleteUser() would perform an SQL query deleting the record from connected database.

In such a case, we can clearly see that our service is responsible for three different things. Moreover, let’s imagine that:

• the marketing team requested a change in the e-mail template because of the branding change

• the CTO requested an email automation provider change

• the data team requested a change in SQL query

We can clearly see that each of these requests may easily affect theoretically unrelated business functions.

As the next step, let’s see how the refactored code could look like:

class UserAccountService {
  fun deleteUser(user: User) {
    println("Deleting user with id ${user.id} from the database")
  }
}
class EmailContentProvider {
  fun prepareContent() {
    println("Preparing email content")
  }
}
class EmailNotificationService {
  fun sendNotification(user: User) {
     println("Sending email to ${user.email}")
  }
}

This time, we can clearly see that each class is responsible for exactly one thing (has one reason to change).

Benefits

• most importantly- any bug introduced to the particular class affects less parts of the system (and organization as a whole)

• additionally, the number of merge conflicts is reduced when multiple people are working with the codebase

• whatsoever, it can introduce much better readability than the monolithic classes

2. O — Open/Closed Principle

As the next step, let’s take a look at the open-closed principle:

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

The Open/Closed principle states “software entities such as classes, components, and modules should be open for extension but closed for modification." That is, such an entity can allow its behavior to be extended without modifying its source code.

Let’s imagine that we were asked to implement a logging feature for custom header objects. However, the logger itself should avoid printing the values of particular headers: header-one and header-two, as they contain vulnerable data.

Given these requirements, we’ve decided to put the excluded headers inside the companion object and expose a log() function, which will make sure that we won’t log any vulnerable data:

data class Header(
  val name: String,
  val value: String
)
class HeadersLogger {
  companion object {
    private val forbiddenHeaders = setOf("header-one", "header-two")
  }
  fun log(header: Header) {
    if (!forbiddenHeaders.contains(header.name))
      println(header.value)
  }
}

Everything works perfectly, but what if at some point the client asks us to exclude additional headers?

Given the above code, we have no other option, than to either modify the HeadersLogger class to contain the additional header or implement a new one. Definitely, the above code is neither open for extension nor closed for modification.

How could we change the above code to follow the above principle? Well, let’s see the following snippet:

class HeadersLogger(val forbiddenHeaders: Set<String> = setOf()) {
  companion object {
    private val forbiddenHeaders = setOf("header-one", "header-two")
  }
  fun log(header: Header) {
    val headerName = header.name
      if (!forbiddenHeaders.contains(headerName)
        && !additionalForbiddenHeaders.contains(headerName)
      )
        println(header.value)
  }
}

As we can see, such a small change gives us much more flexibility. Although we’ve predefined two headers, which should be always skipped, we can easily add new without modification of the existing class. Furthermore, we can extract this code as a common dependency and reuse it in multiple parts of the system.

Benefits

• first of all, reusability and flexibility. We can use already existing codebase to implement new features or apply changes without the need of reinventing the wheel

• moreover, the above advantage is a great time-saver

• additionally, modification of existing classes might introduce unwanted behavior everywhere they’ve been used. With the open-closed principle, we can easily avoid this risk

3. Liskov substitution principle

Next, let’s check the definition of the Liskov substitution principle:

Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T.

This principle indicates that parent classes should be easily substituted with their child classes without changing the behavior of software. It means that a sub-class should override the methods from a parent class, which does not break the functionality of the parent class.

Let’s say that we’ve got two types of users in the app: standard and admin. Both types of the account can be created. Nevertheless, the admin account can not be deleted in our app (for instance it can be done only from an external one).

Given that, let’s have a look at the example:

interface Managable{
  fun create()
  fun delete()
}
class StandardUser : Managable{
  override fun create() {
    println("Creating Standard User account")
  }
  override fun delete() {
    println("Deleting Standard User account")
  }
}
class AdminUser : Managable{
  override fun create() {
    println("Creating Admin User account")
  }
  override fun delete() {
    throw RuntimeException("Admin Account can not be deleted!")
  }
}

At first glance, everything seems to be working, as expected. The interface methods has been overriden and we can compile it successfully. Additionally, we’ve applied the requirements and the delete() implementation prohibits from deleting the Admin account.

Nevertheless, we can clearly spot, that replacement of the interface invocation with the derived method will definitely break the flow. Let’s imagine that someone else wrote a generic test for Managable interface. Given the contract, tester assumed that invoking the delete() should remove the data from the external database regardless of the user type. Unfortunately, that’s not the case here and the test will work as expected with the StandardUser instance and fail with the exception for the AdminUser.

There are plenty of possibilities when it comes to the above code. Let’s see the example one:

interface Creatable {
  fun create()
}
interface Deletable {
  fun delete()
}
class StandardUser : Creatable, Deletable {
  override fun create() {
    println("Creating Standard User account")
  }
  override fun delete() {
    println("Deleting Standard User account")
  }
}
class AdminUser : Creatable {
  override fun create() {
    println("Creating Admin User account")
  }
}

This time, we’ve introduced a more specific contract with two, separate interfaces. Definitely, the hypothetical substitution won’t break the flow.

Benefits

• when our subtypes conform behaviorally to the supertypes in our code, our code hierarchy becomes cleaner

• furthermore, people working with the abstraction (interface in our case) can be sure that no unexpected behavior occurs

4. Interface segregation principle

We've already covered three rules, so it’s time to check the interface segregation principle:

Many client-specific interfaces are better than one general-purpose interface.

The interface-segregation principle indicates classes that implement interfaces, should not be forced to implement methods they do not use. This principle is related to the fact that a lot of specific interfaces are better than one general-purpose interface. In addition, this is the first principle, which is used in interface, all the previous principles applies on classes.

You might already noticed that we’ve already seen this violation in the chapter five:

interface Managable{
  fun create()
  fun delete()
}

First of all, people working with the above interface can not be sure what exactly are its boundaries at first glance. What exactly does "manage" mean in terms of our application? Is it just creating and deleting people, or should suspending also count in this case?

Furthermore, frequent violations of this rule may lead to the creation of a monolithic monster. And trust me, we don’t want to get back to such a code at some point in the future.

Similarly, we’ve already introduced a possible solution in the previous chapter:

interface Creatable {
  fun create()
}
interface Deletable {
  fun delete()
}

This time, we don’t have any doubts when working with the above interfaces. We can definitely assume that all classes implementing Creatable will be responsible for the creation, and in case of Deletable- for removal.

Benefits

• well designed interfaces help us to follow the other principles. It’s much easier to take care of single responsibility and as we could see- Liskov substitution

• additionally, precise contract described by the interface makes the code less error-prone

• whatsoever, it really improves readability of the hierarchy and the codebase itself

5. Dependency inversion principle

Finally, let’s check out the dependency inversion principle:

Depend upon abstractions, [not] concretions.

This principle suggests that high level modules should not depend on low level. So, both should depend on abstractions. Furthermore, abstraction should not depend on details. Details should depend upon abstractions.

Just like in the previous examples, let’s see the code, which does not apply the above principle:

class EmailNotificationService {
  fun sendEmail(message: String) {
    val formattedMessage = message.uppercase()
    println("Sending formatted message: $formattedMessage")
  }
}

As we can see, the EmailNotificationService will send a formatted to upper case message. Although everything is working as expected, we can spot that this method depends on the specific implementation.

Let’s modify the service a bit:

class EmailNotificationService {
  fun sendEmail(message: String, formatter: (String) -> String) {
    val formattedMessage = formatter.invoke(message)
    println("Sending formatted message: $formattedMessage")
  }
}

This time, we made the EmailNotificationService independent of the formatter implementation. The only thing that this service care about is that the formatter has to return a String value. As we can see, applying this principle gives us much more flexibility.

Benefits

• allows the codebase to be easily expanded and extended with new functionalities

• furthermore, it improves reusability

Conclusion

Writing code according to SOLID principles will make our software more readable, understandable, flexible, and maintainable.

Mansi Vaghela LinkedIn Twitter Github Youtube