Kotlin List ne contient pas add ? À la recherche des méthodes manquantes

Pourquoi Kotlin nous a-t-il "enlevé" add, remove et put ? Comprenons une fois pour toutes

Si vous avez déjà programmé en Java avant de passer à Kotlin, vous avez probablement rencontré ce moment de léger désarroi. Vous créez une List, vous voulez y ajouter un élément — vous écrivez .add(), et l'environnement de développement le souligne en rouge. Ou vous essayez de placer une valeur dans une Map avec .put() — et à nouveau une erreur.

Ça vous dit quelque chose ? Et comment ! La question "Kotlin's List missing "add", "remove", Map missing "put", etc?" sur Stack Overflow a recueilli des milliers de vues et des dizaines de commentaires. C'est un véritable obstacle pour les débutants, et même les développeurs expérimentés se surprennent parfois à penser : "Mais où sont passées mes méthodes habituelles ?"

Dans cet article, nous ne nous contenterons pas de répondre à cette question. Nous montrerons comment la philosophie de Kotlin transforme ce "défaut" en votre principal atout. Vous découvrirez les meilleures pratiques pour travailler avec les collections en 2025, apprendrez à choisir le bon type de collection et cesserez de confondre listOf et mutableListOf. C'est parti !

Quel est le secret ? L'immuabilité comme mode de vie

La première chose à comprendre : Kotlin a été conçu dès le départ comme un langage qui encourage un code sûr et prévisible. L'un des principes fondamentaux est l'immuabilité (immutability) par défaut.

En Java, vous avez une seule interface List, et elle contient toujours les méthodes add(), remove(), set(), etc. Même si vous créez une liste avec List.of() (Java 9+), vous avez toujours accès à ces méthodes — elles lèvent simplement une exception à l'exécution. Ce n'est ni pratique ni sûr.

Kotlin a emprunté une autre voie. Il a divisé les collections en deux types :

\n
• Immuables (lecture seule) : List, Set, Map — elles n'ont pas de méthodes modifiant le contenu.
\n
• Mutables : MutableList, MutableSet, MutableMap — celles-ci ont toutes les méthodes familières add, remove, put.
\n

C'est précisément pourquoi listOf(1, 2, 3) n'a pas de méthode .add(). Elle retourne une liste immuable. Alors que mutableListOf(1, 2, 3) retourne une liste mutable, et elle a bien .add().

Cela semble logique ? Regardons le code.

Exemples : ce qui fonctionne et ce qui ne fonctionne pas

Voici une situation classique qui embrouille les débutants :

// ❌ Erreur ! List n'a pas de add()\nval fruits = listOf("pomme", "banane")\nfruits.add("orange") // Erreur de compilation\n\n// ✅ Correct : on utilise MutableList\nval mutableFruits = mutableListOf("pomme", "banane")\nmutableFruits.add("orange") // Maintenant ça marche !\nprintln(mutableFruits) // [pomme, banane, orange]\n

Même histoire avec Map :

// ❌ Erreur ! Map n'a pas de put()\nval capitales = mapOf("Russie" to "Moscou", "France" to "Paris")\ncapitales.put("Allemagne", "Berlin") // Erreur de compilation\n\n// ✅ Correct : on utilise MutableMap\nval mutableCapitales = mutableMapOf("Russie" to "Moscou", "France" to "Paris")\nmutableCapitales.put("Allemagne", "Berlin")\n// Ou encore plus court :\nmutableCapitales["Allemagne"] = "Berlin"\nprintln(mutableCapitales) // {Russie=Moscou, France=Paris, Allemagne=Berlin}\n

Remarquez : pour MutableMap, on peut utiliser les crochets opérateurs [] — c'est en fait put() sous le capot. Très pratique !

Mais pourquoi ? Pourquoi Kotlin complique-t-il autant la vie ?

À première vue, cela semble être une complication inutile. Pourquoi devoir se souvenir de deux types de collections ? En réalité, c'est une solution géniale. Voici les trois principales raisons :

1. Sécurité au niveau des types

Le compilateur s'assure désormais que vous ne modifiez pas accidentellement une liste qui devrait rester