Respuesta.

Historia del asunto

El pattern matching es una técnica tomada de lenguajes funcionales y de scripts que permite verificar el tipo y extraer datos en un solo paso. En Java, el desarrollo del pattern matching comenzó con Java 14 (característica de vista previa), mejoró en Java 16-17, y en las últimas versiones se está expandiendo a switch.

Problema

El método clásico de verificación de tipo y conversión era engorroso:

if (obj instanceof String) {
    String s = (String) obj;
    ...
}

Aparecían variables innecesarias, una gran cantidad de código repetitivo y el riesgo de errores de conversión de tipos.

Solución

El pattern matching permite combinar la verificación de tipo, la declaración de una nueva variable y su uso en una sola expresión:

if (obj instanceof String s) {
    System.out.println(s.length());
}

Patrones similares ahora aparecen en la construcción switch, lo que hace que el código sea más conciso y menos propenso a errores.

Características clave:

Manejo conciso y seguro de tipos.
Reducción de errores en las conversiones.
Facilidad de mantenimiento del código y ampliación a nuevos tipos.

Preguntas capciosas.

¿Se puede usar el pattern matching para clases personalizadas o solo para tipos estándar?

Se puede usar para cualquier clase. El Pattern Matching funciona para todas las clases con las que se puede aplicar instanceof.

¿Estará la variable del patrón disponible fuera del bloque if/switch?

No, la variable declarada dentro del pattern matching solo es visible dentro del bloque donde fue creada (por ejemplo, dentro de if o caso switch).

Ejemplo de código:

if (obj instanceof Integer i) {
    // i es visible solo dentro de este bloque
    System.out.println(i + 10);
}
// Aquí i no está disponible

¿Se puede usar el pattern matching con genéricos?

Sí, de esta manera:

Object list = List.of("a", "b");
if (list instanceof List<?> l) {
    System.out.println(l.size());
}

Pero el trabajo con tipos crudos y la conversión a tipos parametrizados aún está limitado debido a la eliminación de tipos.

Errores típicos y anti-patrones

Suposición de que el pattern matching maneja automáticamente null: si el objeto es null, la condición no se cumplirá (instanceof con null siempre es false).
Uso del pattern matching donde sería suficiente con el método getClass().
Un uso excesivo del pattern matching puede deteriorar la arquitectura si las intenciones no son evidentes.

Ejemplo de la vida real

Caso negativo

El equipo implementó el pattern matching en todos los casos, incluidos DTO internos, clases de servicio y casos donde era suficiente el polimorfismo. El código se volvió demasiado dependiente de instanceof, y la función de las jerarquías de clases se desdibujó.

Ventajas:

Implementación rápida.
Estilo conciso.

Desventajas:

Fallos arquitectónicos.
Menor legibilidad.

Caso positivo

En el proyecto, el pattern matching se aplicó solo a interfaces generales, utilidades auxiliares y el procesamiento de colecciones de tipo desconocido. La arquitectura OOP se mantuvo, utilizando el patrón solo donde era absolutamente necesario.