Réponse.

Contexte :

Le mot-clé instanceof a été introduit en Java pour vérifier si un objet appartient à un type donné ou à un sous-type. Ce mécanisme permet de préciser le type d'objet à l'exécution, ce qui est important pour travailler avec des collections génériques, le polymorphisme et les conversions de type.

Problème :

Sans une détermination correcte du type d'objet, des erreurs ClassCastException ou un traitement incorrect de la logique dans les branches de code peuvent se produire si les conversions de type sont effectuées sans vérification. De plus, un usage excessif de instanceof est souvent un signe d'une mauvaise conception.

Solution :

instanceof renvoie true si l'objet est une instance de la classe donnée ou de l'une de ses sous-classes, ou implémente une interface. Avec Java 16, un patron de correspondance (pattern matching) a été introduit avec conversion automatique du type dans le bloc if.

Exemple de code :

Object obj = "Hello!";

if (obj instanceof String) {
    String s = (String) obj; // La conversion est sûre
    System.out.println(s.length());
}

Avec Java 16 :

if (obj instanceof String s) {
    System.out.println(s.length()); // s est automatiquement converti en String
}

Caractéristiques clés :

Fonctionne pour les classes et les interfaces
Retourne false en toute sécurité pour null (null instanceof Type est toujours false)
Un usage excessif peut masquer des erreurs d'architecture

Questions pièges.

Que retourne null instanceof SomeClass ?

Toujours false. L'opérateur garantit que si l'objet est null, le résultat est false, évitant ainsi NullPointerException.

Peut-on utiliser instanceof avec des paramètres de génériques, par exemple if (obj instanceof List<String>) ?

Non. En raison de l'effacement de type (type erasure), il n'est pas possible de vérifier les paramètres génériques à l'exécution. La vérification est toujours effectuée uniquement selon le type brut (par exemple, List).

Exemple de code :

List<String> list = ...;
if (list instanceof List<String>) { ... } // Erreur de compilation
if (list instanceof List) { ... } // Autorisé

L'utilisation de instanceof peut-elle indiquer des problèmes de conception du code ?

Oui. L'utilisation constante de instanceof au lieu d'appliquer des abstractions ou des motifs (par exemple, le motif Visitor) indique souvent une violation des principes de la POO, tels que l'ouverture/fermeture.

Erreurs typiques et anti-patron

Conversion de type sans vérification via instanceof
Utilisation de instanceof dans de grands blocs pour traiter la logique (switch par type au lieu de polymorphisme)
Tentative de vérification des types génériques via instanceof

Exemple de la vie réelle

Cas négatif

La méthode contient une grande chaîne if-else vérifiant tous les sous-classes possibles d'une super-classe via instanceof, à l'intérieur de chaque branche - conversion de type et appel de la méthode correspondante.

Avantages :

Rapidement réalisé pour une petite hiérarchie de classes

Inconvénients :

Complexité accrue lors de l'ajout de nouvelles sous-classes, violation du SRP, difficile à tester

Cas positif

Au lieu de if-else, le motif Visitor est utilisé : chaque sous-classe a une méthode appelant le comportement souhaité, ce qui élimine le besoin de instanceof.