loading...

re: Kotlin - The Good, the Bad and the Ugly VIEW POST

TOP OF THREAD FULL DISCUSSION
re: I would disagree about data classes and inheritance. There is absolutely no need in inheritance, especially with data classes.
 

This may depend on your domain. If you want to use data classes for Data Transfer Objects (which would make perfect sense because they are just data containers, or "structs" if you prefer this term), then inheritance is ordinary day-to-day business (at least in the domains I work with). The only alternative to the use of inheritance would be to duplicate fields into every leaf class, and remove the base classes. This makes the design brittle, because not only are you duplicating information (DRY principle), you also run into the issue that you might forget to add a field in one of your leaf classes in the future. I strongly believe that inheritance is necessary, and this is the reason why I don't use data classes for DTOs, as much as I would like to do so.

 

Kotlin allows you to define properties in interfaces, and you can still implement interfaces in a data class. This frees you from the brittle design of duplicated properties (at least, in remembering to put them all in), and also solves the issue of wanting to use a data class as multiple types. I've tried this pattern out in my Dokka-to-JSON formatter and it works quite well, and is very robust.

I do not think the choice of data classes being final was an oversight. I think it was made very intentionally, in order to get you truly using data classes as pure data composed of other data. They are not in the same "class" of objects as normal objects, they are useful primarily for serialization, and its generally a good design to not have your code interact directly with a data class any way. You should abstract your code away from the structure of the serialized data into a format that works better with the business logic.

You should abstract your code away from the structure of the serialized data into a format that works better with the business logic.

Totally in agreement here. That's why a quick way for building serialization formats is a great benefit.

Kotlin allows you to define properties in interfaces, and you can still implement interfaces in a data class.

I must admit that I didn't think of this option yet. It would allow you to do all the inheritance you want on the interface level, and instantiate only the leaf classes. It also enforces the correct properties and types. Okay, granted, that seems reasonable. It does entail though that you need to write the interfaces and the data classes, and in a lot of cases there will be only one implementation for each interface (DTOs for example). Still, thanks for the heads-up. I'll consider this in the future.

You can, of course, implement interfaces in data classes, but, in my opinion, compisition will always be a better way to do it. Want to avoid property duplication in your DTOs/value objects/whatever? Move the duplicated part to a new data class and use it as a property in another class. I have yet to see a use of inheritence which can be justified. Normally it is just a mess. Steer clear of it :-)

Code of Conduct Report abuse