Réponse.

En Kotlin, l'immuabilité est généralement entendue comme l'impossibilité de modifier l'état d'un objet après sa création. Cela est réalisé par l'utilisation de propriétés val (immuables), ainsi que par la création de classes avec une initialisation uniquement dans le constructeur sans méthodes permettant de modifier les données internes.

Kotlin, contrairement à Java, offre un mécanisme pratique pour créer des classes immuables via data class et des collections telles que List, Set, Map (qui sont par défaut immuables). Mais il est important de comprendre que dans Kotlin, les collections de base sont immuables uniquement au niveau de l'interface, et l'objet de collection lui-même peut être modifié si on le convertit en MutableList, etc.

Exemple de bonne immuabilité :

// Data class et val assurent l'immuabilité
 data class User(val name: String, val age: Int)
 val user = User(name = "Ivan", age = 30)
// user.name = "Sergey" // ERREUR DE COMPILATION

Exemple de code violant l'immuabilité :

class User(var name: String, var age: Int)
val user = User("Ivan", 30)
user.name = "Sergey" // Modification de l'objet possible

Nuances :

• Même une data class avec des propriétés val ne garantit pas une immuabilité totale si les propriétés sont des types de référence et que leur état interne peut changer.
• Pour une véritable immuabilité, utilisez uniquement des val + des types immuables (par exemple, val scores: List<Int>).

Question piège.

Les objets de classe data class avec uniquement des propriétés val sont-ils totalement immuables ?

Réponse : Non, si les propriétés sont des objets mutables (par exemple, val items: MutableList<Int>), l'état interne peut être modifié.

Exemple :

data class Group(val members: MutableList<String>)
val group = Group(mutableListOf("Tom", "Jerry"))
group.members.add("Spike") // état interne modifié

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

---

Histoire

Dans un projet, une data class immuable avec une propriété val de type MutableList a été utilisée. L'un des développeurs pensait que l'objet ne pouvait pas être modifié, cependant, un autre développeur a ajouté de nouveaux éléments à la collection. Cela a entraîné une incohérence des données et des bugs difficiles à identifier, lorsque deux threads changeaient en parallèle la liste commune.

---

Histoire

Lors du passage d'une instance de classe avec une collection mutable entre les couches d'une application, une couche modifiait le contenu sans informer l'autre couche. Cela a conduit à des situations où l'UI n'était pas au courant des modifications survenues et travaillait avec des données d'entrée non valides.

---

Histoire

Un développeur pensait à tort que List en Kotlin est toujours immuable. En réalité, une implémentation provenant de Java (ArrayList) était utilisée sous le capot, et la tentative de modifier la liste a conduit à une perte inattendue de données et à des bugs lors de l'interaction avec la base de données.