Réponse.

Data object — c'est un nouveau type de déclaration en Kotlin (depuis la version 1.9), combinant les propriétés d'un objet singleton et d'une data class. Il est destiné aux cas où l'on souhaite n'avoir qu'une seule instance de l'objet et des méthodes générées automatiquement equals, hashCode, toString (comme pour une data class).

Historique de la question

Auparavant, pour stocker des entités uniques avec des méthodes toString() et equals() générées automatiquement, il fallait écrire un object avec des implémentations manuelles ou utiliser par compromis une data class avec un seul objet (et non des instances).

Problème

Les objets singleton (object) ne possèdent pas d'equals, hashCode, toString générés automatiquement, alors qu'une data class suppose plusieurs instances, ce qui ne convient pas aux modèles enum-like exhaustifs.

Solution

Avec l'apparition du data object, les deux problèmes sont résolus de manière concise :

La classe ne peut être qu'une seule instance (singleton).
Le compilateur génère les méthodes multiméthodes nécessaires.

Exemple de code :

data object LoadingState

data object NoData

println(LoadingState == LoadingState) // true
println(LoadingState.toString()) // LoadingState

Caractéristiques clés :

Toujours singleton — il est impossible de créer une deuxième instance.
Le compilateur ajoute des méthodes equals, hashCode, toString comme pour une data class.
Particulièrement pratique à utiliser avec l'interface scellée pour modéliser des états.

Questions pièges.

En quoi un data object diffère-t-il d'un object ordinaire ?

Seul le data object reçoit l'autogénération des méthodes equals, hashCode, toString au niveau du compilateur ; un object ordinaire utilise des implémentations de Any (égalité référentielle, toString peu riche).

Peut-on créer un data object avec des paramètres de constructeur ?

Non, un data object ne peut pas avoir de constructeur avec des paramètres. Il est toujours sans paramètres, puisqu'il n'existe qu'une seule instance.

Peut-on hériter d'un data object ?

Oui, un data object peut implémenter des interfaces, y compris l'interface scellée, et faire partie des hiérarchies d'états.

Exemple :

sealed interface Result

data object Success : Result

data object Failure : Result

Erreurs typiques et anti-modèles

Tentative d'ajouter des champs de constructeur dans un data object (c'est interdit).
Utilisation d'une data class où une unique instance est prévue.

Exemple de la vie réelle

Cas négatif

Un développeur modélise "pas de données" comme object NoData, puis compare par equals() avec un objet externe et obtient un résultat inattendu (comparaison référentielle, et non sémantique).

Avantages :

Simplicité de la déclaration.

Inconvénients :

Comportement inapproprié lors de equals/toString.

Cas positif

Un data object est utilisé pour les états de chargement, l'égalité et l'impression se font selon les règles des data class attendues. Le modèle de couche utilise de manière fiable le matching par motif en fonction des états.