Réponse.

Classes imbriquées — ce sont des classes définies à l'intérieur d'une autre classe. Elles peuvent être :

• Static nested classes — classes imbriquées statiques ; n'ont pas accès aux membres non statiques de la classe externe sans une instance.
• Inner classes — classes imbriquées non statiques ; ont accès à tous les membres de la classe externe.
• Classes anonymes — classes internes sans nom, généralement déclarées et créées sur place, souvent lors du travail avec des interfaces/classes abstraites.

Exemple de classe anonyme :

Button b = new Button();
b.setOnClickListener(new OnClickListener() {
  @Override
  public void onClick(View v) {
    // action lors du clic
  }
});

Caractéristiques :

• Les classes anonymes peuvent uniquement accéder aux variables externes qui sont final (effectivement final).
• Chaque instance de la classe interne contient implicitement une référence à l'instance de la classe externe.
• Selon le type (static/inner), cela peut entraîner des fuites de mémoire ou des dépendances inattendues.

Question piège.

Une classe interne (non statique) peut-elle contenir des méthodes ou des variables statiques ?

Réponse : Non, elle ne le peut pas, sauf pour les constantes (static final). Seule une static nested class (classe imbriquée statique) peut avoir des membres statiques.

Exemple (erreur) :

class Outer {
    class Inner {
        static int x = 10; // Erreur de compilation !
    }
}

Correction :

class Outer {
    static class StaticNested {
        static int x = 10; // OK
    }
}

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

---

Histoire

Dans une application Android, nous avons utilisé une classe interne comme gestionnaire d'événements. Le gestionnaire était stocké dans un champ statique et détenait une référence implicite à l'Activity, entraînant une fuite de mémoire lors de sa destruction, et l'application commençait à "fuir", jusqu'à OutOfMemoryError.

---

Histoire

Dans l'un des microservices, nous avons utilisé des classes anonymes qui se référaient à des variables externes-iterateurs. Après le refactoring, les variables ont cessé d'être effectivement finales, et le code a cessé de compiler — les développeurs ont longtemps cherché la raison jusqu'à ce qu'ils se rappellent cette restriction.

---

Histoire

Dans une bibliothèque, nous avons utilisé des variables statiques à l'intérieur d'une classe interne, pensant que c'était une pratique normale. Dans les nouvelles versions de JDK, le projet a cessé de compiler car la norme est devenue plus stricte sur les restrictions. Une refonte urgente de l'architecture était nécessaire.