ProgrammationDéveloppeur Kotlin

Expliquez les particularités de la gestion des types Nullable dans Kotlin. Quels outils du langage permettent de travailler en toute sécurité avec des valeurs null ? Donnez un exemple de code et décrivez les meilleures pratiques.

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse.

Kotlin réalise un travail sécuritaire avec null grâce à son système de types : tout type ne peut par défaut être null, par exemple, val a: String = null entraînera une erreur de compilation. Pour désigner la possibilité d'assigner null, le symbole de question ? est utilisé, par exemple :

val name: String? = null

Pour travailler avec des types Nullable, les outils suivants sont fournis :

  • Opérateur de sécurité : ?., qui retourne null si l'objet lui-même est null, et appelle la méthode/champ dans le cas contraire : name?.length.
  • Opérateur Elvis : ?:, pour établir une valeur par défaut si à gauche, il y a null : val length = name?.length ?: 0
  • Vérification via if/when : Exemple :
if (name != null) { println(name.length) }
  • Opérateur d'affirmation (!!) : Pour récupérer de force une valeur, lançant NullPointerException si l'objet est null (utilisé avec prudence) :
val length = name!!.length

Meilleures pratiques : minimiser les types Nullable, utiliser l'opérateur de sécurité et l'opérateur Elvis, éviter !!, et modéliser clairement les situations où null est admissible.

Question piège.

Peut-on assigner une valeur null au type val a: String, et comment l'éviter ?

Réponse : Non, par défaut, dans Kotlin, les types ne peuvent pas être égalés à null. Pour permettre l'assignation de null, il faut explicitement indiquer val a: String? = null. Les types sans ? sont toujours non-null.

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet.


Histoire

Dans le projet d'application bancaire, une variable de type User stockait le résultat de la recherche d'un client. Le développeur a défini var user: User, mais parfois le client n'était pas trouvé et le service retournait null. Cela a entraîné des NPE et des pannes massives.


Histoire

Dans un chatbot pour le support, on a utilisé !! pour accéder aux messages de l'utilisateur (message!!.text), pensant que les messages arrivent toujours. Le bot plantait dès le premier message vide. L'opérateur de sécurité aurait évité le problème.


Histoire

Dans une application mobile, les données de la base pouvaient ne pas être chargées et arrivaient comme null. Au lieu d'une approche sécurisée, le développeur a utilisé un accès direct, ce qui a entraîné des pannes dans tous les cas de données incomplètes.