A Look into Kotlin’s Fancy Data Classes

POJOs are extinct. Here’s how to save yourself from extinction…

Rahul Chowdhury
DriveU Blog
5 min readMar 20, 2018

--

With great power, comes great features.

Kotlin is powerful. It was built with the main objective of making a developer’s job of writing apps easier.

I’ve been writing my Android apps in Kotlin for sometime now, and all I can say is it has definitely taken out a lot of pain out of development.

I talked about the same in this article here:

Among all the cool stuff Kotlin has to offer, one pretty handy feature are data classes.

But wait. What the heck are data classes?

Let’s get to know them first.

What are data classes?

In simple words, they’re model classes without the hassle.

If you’re from a Java background then Kotlin’s data classes are almost similar to Java’s POJOs.

When I say “almost” I mean unlike Java, you don’t have to perform too much of ceremony to write a model class in Kotlin.

A few lines is all it takes to write and maintain your data classes.

Let’s have a comparison. Shall we?

POJO vs. Data Classes

A typical POJO called Article would like somewhat like this:

Surprisingly, the same model class in Kotlin, using it’s data class feature would result to something like this:

Yup! That’s all it takes to write a full-fledged model class in Kotlin. Short and sexy.

Now, seeing this tiny class you might be wondering:

Where are all the getters and setters?

They are auto-generated.

Yes, that’s the beauty of Kotlin’s data classes. It does most of the redundant work for you so that you can spend most of your brainpower on logical stuff.

Here’s a list of functions that Kotlin generates for you when you mark a class with the data keyword:

  • equals()/ hashCode() pair
  • toString()
  • componentN() functions for each field
  • copy()

Leaving out the componentN(), these are the methods that you generally need to write/generate in your model classes.

With Kotlin, you take redundancy out of the scene. How cool is that?

But, I’m still not sold…

I get it, you’re a tough sale but I’m no quitter.

The main advantage of these generated functions is that when your model classes change, you don’t have to scratch your head and write/generate these getters/setters and others functions. Kotlin will do that for you.

There can be various situations where your model class changes:

  • Your API response changes
  • Your business requirements change
  • You need to store an extra value to your DB

…and so on.

You can stay insured against these situations by using Kotlin’s data classes as your models.

Done so, it’ll be as easy as just adding a new field to the class. Here’s an example:

Original class

Updated class

That’s a single line change and you’re ready to roll.

Pumping steroids to your data classes

When you create a data class as shown above, which is the general way to create one, you end up in getting a parameterised constructor.

This means, you’ll have to initialise your objects with all the parameters that you’ve declared, which is not the ideal case every time.

You might need to initialise an object with no data or few data and then use it’s setters to fill in appropriate data.

Fear not, it’s pretty easy to create a parameterless constructor.

Adding parameterless constructors

To add a parameterless constructor to your data class, you need to specify default values for each field.

Therefore, your new data class will look something like this:

See? It’s easy.

You can now initialise your object like this:

What this does is create an object with all the fields initialised to the default values that you’ve specified.

Adding constructor overloads

There might be cases where you need to have multiple overloaded constructors to suit your needs.

For example, you might need to have an Article object without an author field, or you might be planning to initialise that field later on in your app.

To do that, you just need to specify a default value for the specific field you want to omit.

And there you go.

You can now initialise your Article object like this:

You can add the author details later on like this:

Sweet, isn’t it?

You don’t need to write a chapter of code to do redundant and trivial work like these.

Playing cool with annotations

High chances are that you’ll be using a data class as an API response model.

If you’re using Retrofit with the GSON adapter to map your response JSON to your data classes, you’ll need to mark your fields with @SerializedName() annotations.

How to do that?

Just add @SerializedName("field_name") before every field you want to annotate. Kind of like this:

And you’re done. Did you expect something more?

The bottom line

It’s not necessary to use data classes when you’re using Kotlin to develop your apps but it’s definitely encouraged.

As you can see from the examples above, it can dramatically reduce your boilerplate code and also make your code super easy to maintain.

Leverage Kotlin to it’s fullest potential by utilising these cool tricks and tips.

Liked what you read here? Clap and show some love. 👏👏

--

--

Rahul Chowdhury
DriveU Blog

I send a newsletter every Friday to help you become 1% better every single week at hulry.com/newsletter