ProgrammationDéveloppeur Backend

Expliquez les différences entre les classes de données (data classes), les classes ordinaires et les classes avec héritage en Kotlin. Dans quels cas devez-vous utiliser une data class et quelles restrictions le compilateur impose-t-il ?

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse

En Kotlin, data class est destiné à stocker des données. Le compilateur génère automatiquement pour eux les méthodes equals(), hashCode(), toString(), ainsi que les fonctions copy() et componentN(), ce qui facilite considérablement le travail avec de tels objets :

data class User(val name: String, val age: Int) val u1 = User("Ivan", 30) val u2 = u1.copy(age = 31)

Les classes ordinaires n'ont pas de telles méthodes générées automatiquement ; tout doit être écrit manuellement. Il est préférable d'utiliser une data class pour les DTO, les modèles et les structures de données.

Restrictions des data classes :

  • Le constructeur principal doit contenir au moins un paramètre.
  • Tous les paramètres du constructeur doivent être marqués comme val ou var.
  • Les data classes ne peuvent pas être abstract, open, sealed ou inner.
  • Il n'est pas recommandé d'utiliser des data classes pour des classes ayant une logique métier ou une hiérarchie d'héritage.

Question piège

"Peut-on déclarer une data class héritant d'une autre data class ? Pourquoi (ou pourquoi pas) ?"

Non, il n'est pas possible d'hériter directement d'une data class à une autre. Une data class ne peut hériter que d'une interface ou d'une classe ordinaire (pas une data class). Cela a été fait pour éviter la confusion avec les méthodes générées automatiquement (par exemple, copier des propriétés héritées n'est pas évident).

data class Base(val id: Int) data class Child(val name: String) : Base(1) // Erreur de compilation : non autorisé

Exemples d'erreurs réelles dues à l'ignorance des subtilités du sujet


Histoire

Dans un projet bancaire, des data classes étaient utilisées avec de la logique métier et de l'héritage. Après l'ajout d'un nouveau champ, il est devenu impossible de copier correctement les objets, une partie de la logique métier a été perdue (les méthodes n'ont pas été héritées), ce qui a conduit à des erreurs de calcul des commissions.


Histoire

Dans une plateforme de e-commerce, une data class était utilisée pour stocker l'état du panier de l'utilisateur. Après avoir mis à jour l'état via copy(), ils ont oublié que les listes internes ne se copient pas profondément. En raison de cela, il y avait des "fuites" de données entre les sessions des utilisateurs.


Histoire

Dans un projet d'intégration d'une API externe, la sérialisation de la data class en JSON a conduit à l'apparition de champs avec une visibilité privée, ce qui a violé le contrat API et a entraîné des erreurs côté client.