Réponse.

L'objet compagnon (companion object) en Kotlin est un objet déclaré à l'intérieur d'une classe avec le mot-clé companion, permettant de regrouper des méthodes et propriétés statiques, semblable aux membres statiques en Java. Contrairement à Java static, en Kotlin, chaque objet compagnon est un véritable objet, et au niveau du bytecode, l'accès à ses membres se compile comme statique.

Principales caractéristiques et limites :

Nom par défaut — s'il n'est pas spécifié explicitement, l'objet s'appelle Companion.
L'objet compagnon peut implémenter n'importe quelle interface, ce qui le rend pratique, par exemple, pour créer des méthodes de fabrication.
À l'intérieur de l'objet compagnon, il y a un accès aux membres privés de la classe externe.
Chaque classe ne peut avoir qu'un seul objet compagnon.
On peut accéder aux membres de l'objet compagnon à la fois comme statiques via le nom de la classe, ou comme membres de l'objet.

Exemple :

class MyFactory private constructor(val value: Int) {
    companion object {
        fun create(x: Int): MyFactory = MyFactory(x)
    }
}

val instance = MyFactory.create(10)

Question piège.

Pourquoi il n'est pas recommandé de conserver un état (par exemple, des variables mutables) à l'intérieur de l'objet compagnon dans les applications multithread ?

Réponse avec exemple :

Si un état mutable est placé à l'intérieur de l'objet compagnon, il devient partagé entre toutes les instances de la classe et les threads, ce qui entraîne une condition de concurrence sans synchronisation supplémentaire.

class Counter {
    companion object {
        var count = 0
        fun increment() { count++ }
    }
}

Counter.increment() // condition de concurrence lors d'appels simultanés

Exemples d'erreurs réelles dues à un manque de compréhension des subtilités du sujet.

Histoire

Dans un projet Android, les développeurs ont placé la configuration de l'environnement à l'intérieur de l'objet compagnon pour gérer le commutateur de débogage. Cela a conduit à de la confusion lorsque différents fragments modifiaient la même valeur globale, provoquant un comportement inattendu lors des transitions asynchrones.

Histoire

Sur le backend, une partie de la fonctionnalité a été déplacée dans l'objet compagnon avec un cache mutable. En cas de forte charge, des erreurs et un état de données incohérent sont survenus en raison de l'absence de synchronisation.

Histoire

Un développeur débutant a essayé d'implémenter une interface uniquement sur l'objet compagnon, pensant pouvoir ensuite utiliser la classe comme cette interface. En conséquence, il s'est heurté à l'impossibilité de passer la classe au lieu de l'objet compagnon, car le compagnon est le seul objet associé à la classe, et non la classe elle-même.