Kotlin Data Classes 101: Understanding Syntax, Usage and Inheritance

https://hardiksachan.com/kotlin-data-classes-101-understanding-syntax-usage-and-inheritance

by hardik_sachan • 3 years ago

56 33 3 years ago

The article does not actually explain how to do inheritance. In case you are wondering, the answer is using sealed classes.

Some neat things with data clases (vs. e.g. Java's records):

- default values for parameters

- if you use vals, your data classes are immutable

- copy constructor that has the same parameters as the constructor with their current values as the default value.

- destructuring values

- extension and delegated properties. Those are not limited to data classes of course but they are really nice to use with data classes.

Kotlin multi platform and data classes are actually a nice combination btw. We have a spring boot project with a Kotlin multi platform API client that we can consume on Android, IOS, in a Browser and in our integration tests for the server. Exact same code working exactly the same way on IOS native, in a browser, or on Android and the JVM. It uses ktor client for http communication, and kotlinx serialization for json parsing. Works great.

Xeophon• 3 years ago

Kotlin is simply amazing if you pair it with the corresponding frameworks, i.e. kotlinx serialization instead of gson/jackson etc. Quickly fell in love with the language and Java, even in the new(er) versions, feels outdated.

pron11• 3 years ago

The reason Java rejected data classes in favour of the very different and more powerful approach of nominal tuples (i.e. records) and algebraic data types in general, was the observation that the vast majority of data classes can be record classes. It's by not trying to cover the remaining small minority of cases with the same construct that we gain the guarantees of a more powerful one based on the property that the full state of a record is described by its canonical constructor and its deconstruction serves as its dual.

All records are well-behaved as collection members; not all data classes are.

All records can be safely serialised and deserialised; not all data classes can.

All records can be deconstructed and reconstructed; not all data classes can.

Data classes are about declaring classes with less code. When you have an object of a data class you know nothing more about its behaviour than you do about an object of any class. Record classes, which are similar in their design philosophy to enums, are not about writing less code, but about being reifying the concept of unencapsulated data, which offers semantic guarantees -- not just less syntax -- about the nature of the objects, just as you can with enums.

Java is able to offer new constructs such as records and enums, with runtime support, as it's not a hosted language.

scns2• 3 years ago

Like your input a lot.

All records are well-behaved as collection members; not all data classes are.
All records can be safely serialised and deserialised; not all data classes can.
All records can be deconstructed and reconstructed; not all data classes can.

Can you give examples please?

jillesvangurp4• 3 years ago

I'm sure there are good reasons for why record classes are the way they are. But the reasons you cite strike me as a bit esotheric / low value.

Serialization works fine with kotlinx.serialization. Java's built in serialization is a bit of a relic of the past that doesn't really have that many use cases left. I'll write that off as a "I couldn't care less". I've actually used java serialization but not this century. There probably is still some legacy stuff around that depends on it but nothing a typical Kotlin user would care about.

As for collections. Not sure what you mean here. The Java collections take just about any object. Including data class objects. You need working hashcode and equals implementations. Which are provided by data classes. There are some limitations with deep comparisons particularly with array types. The Kotlin compiler will warn you about those. Am I missing something else here?

Constructing/destructing seems to work fine for me. Nice feature. Copy constructors in particular are neat. Am I missing out on something here?

You make it sound that this is kind of a big deal or a big compromise but I just don't see it.

tadfisher• 3 years ago

It's important to note that `data class` works on JVM platforms before version 16, and the Kotlin compiler will check the additional constraints and generate records if you add the `@JvmRecord` annotation. This is a reasonable approach for a non-Java JVM language, especially considering records is an ABI- and API-incompatible addition.

sixbrx2• 3 years ago

One downside of Java records seems to be that they can't participate as the alternatives (subtypes) for a sealed abstract type, since they can't extend any classes other than Object. Ie. the very common "sum of product types" pattern can't use records as the product types - which they would have been great for! You can have normal wrapper classes as the subtypes of the sealed type, and have those wrappers use records internally, but all the brevity and clarity is lost that way IMO and it just becomes obfuscation.

TeeWEE2• 3 years ago

How do you deal with schema versioning?

We use the exact same setup. However older client version often trip over server schema changes.

While this is a generic problem, it’s harder to prevent when your models it’s not built into your network data contract.

That’s why we considering using grpc which has backwards compatibility support on its design. Things can still break if you delete endpoints, but at least it’s contained to the idl file.

jillesvangurp4• 3 years ago

I basically don't version schemas currently. We do version our library of course. So you have to opt into using a new version.

But managing compatibility breaking API changes is a bit of an issue of course. Not just for Kotlin.

I mitigate it by configuring the serializer to be tolerant of new or missing keys, enum values, etc. The defaults for this are actually a bit dangerous/wrong IMHO. Also, most new properties that we add are nullable and default to null. This way we can safely deal with values not being there. And we use deprecations before removing anything from the API (which are nice in kotlin because you can automatically fix them in intellij with replace patterns). There are a few other things you can do. Like implementing some good contract tests, etc.

We actually considered grpc at some point but decided against it as being a bit too limiting and mobile centric at the time. Also, grpc in a browser was not well supported at the time we looked. Maybe that has changed?

Kukumber• 3 years ago

I like kotlin a lot, a very well crafted language, syntax is super clean

I wish they'd put WAY more effort into kotlin native

Kotlin Data Classes 101: Understanding Syntax, Usage and Inheritance

Related Stories