Respuesta.

Historia del tema:

La palabra clave instanceof apareció en Java para verificar si un objeto pertenece a un tipo dado o a su subtipo. Este mecanismo permite aclarar el tipo del objeto en tiempo de ejecución, lo cual es importante para trabajar con colecciones genéricas, polimorfismo y conversión de tipos.

Problema:

Sin una correcta definición del tipo del objeto, pueden surgir errores ClassCastException o un procesamiento de lógica incorrecto en las ramas de código si se realiza la conversión de tipos sin verificación. Además, el uso excesivo de instanceof a menudo es un signo de un diseño deficiente.

Solución:

instanceof devuelve true si el objeto es una instancia de la clase dada o de cualquier subclase, o implementa la interfaz. En Java 16 se presentó el patrón de coincidencia con conversión automática de tipos en el bloque if.

Ejemplo de código:

Object obj = "¡Hola!";

if (obj instanceof String) {
    String s = (String) obj; // Conversión segura
    System.out.println(s.length());
}

Desde Java 16:

if (obj instanceof String s) {
    System.out.println(s.length()); // s se convierte automáticamente a String
}

Características clave:

Funciona para clases e interfaces
Devuelve false de forma segura con null (null instanceof Type siempre es false)
El uso excesivo puede ocultar errores en la arquitectura

Preguntas engañosas.

¿Qué devolverá null instanceof SomeClass?

Siempre false. El operador garantiza que si el objeto es null, el resultado será false, excluyendo NullPointerException.

¿Se puede usar instanceof con parámetros genéricos, por ejemplo if (obj instanceof List<String>)?

No. Debido a la eliminación de tipos (type erasure), no se pueden verificar los parámetros genéricos en tiempo de ejecución. La verificación siempre se realiza solo por el tipo crudo (por ejemplo, List).

Ejemplo de código:

List<String> list = ...;
if (list instanceof List<String>) { ... } // Error de compilación
if (list instanceof List) { ... } // Permitido

¿Puede el uso de instanceof indicar problemas en el diseño del código?

Sí. El uso constante de instanceof en lugar de aplicar abstracciones o patrones (por ejemplo, el patrón Visitor) a menudo indica una violación de los principios de OOP, como la apertura/cierre.

Errores típicos y anti-patrones

Conversión de tipos sin verificación a través de instanceof
Uso de instanceof en bloques grandes para procesar lógica (switch por tipos en lugar de polimorfismo)
Intento de verificar tipos genéricos a través de instanceof

Ejemplo de la vida real

Caso negativo

En el método hay una larga cadena de if-else que verifica todas las posibles subclases de una superclase a través de instanceof, dentro de cada rama hay conversión de tipos y llamada al método correspondiente.

Ventajas:

Implementación rápida para una jerarquía de clases pequeña

Desventajas:

Complejidad al agregar nuevos subclases, violación del SRP, difícil de probar

Caso positivo

En lugar de if-else, se implementa el patrón Visitor: cada subclase tiene un método que llama al comportamiento necesario, lo que elimina la necesidad de instanceof.