La lección anterior terminó con una molestia legítima: Catalogo.PorTitulo es una clase completa —declaración, @Override, cuerpo, nombre y un hueco en el espacio de nombres— para una sola línea de lógica que se usa exactamente en un sitio. Cuando el código que quieres escribir cabe en una línea y la ceremonia para envolverlo ocupa cinco, algo sobra.

Las clases anónimas eliminan esa ceremonia. Permiten declarar una implementación e instanciarla en la misma expresión, en el punto exacto donde hace falta y sin darle nombre. Fueron durante quince años el mecanismo estándar de Java para pasar comportamiento a un método: cada Comparator, cada listener de interfaz gráfica, cada Runnable se escribía así. Hoy las lambdas han ocupado buena parte de ese terreno, pero las clases anónimas siguen siendo la única opción en varios escenarios concretos, y sobre todo siguen apareciendo en todo el código Java existente: leerlas con soltura no es opcional. Además, entenderlas a fondo es la mejor preparación posible para la lección 04-05, porque una lambda no es más que una clase anónima a la que se le ha quitado todo lo prescindible.

1. Qué es una clase anónima
2. La sintaxis, diseccionada
3. Qué puede y qué no puede hacer
4. El bloque de inicialización de instancia
5. Métodos propios: existen, pero casi no sirven
6. Captura de variables efectivamente finales
7. this dentro de una clase anónima
8. Uso clásico 1: un Comparator para el catálogo
9. Uso clásico 2: una devolución de llamada
10. Uso clásico 3: extender puntualmente una clase
11. Cuándo sigue siendo la opción correcta y cuándo usar una lambda
12. El "double brace initialization" y por qué evitarlo
13. Peso en el bytecode y legibilidad
14. Tabla de decisión final
15. Errores Comunes y Consejos
16. Ejercicios

Una clase anónima es una clase sin nombre que se declara e instancia en una sola expresión. Puede ser:

• Una implementación de una interfaz, o
• Una subclase de una clase (concreta o abstracta).

Compara las dos formas de obtener un comparador por título:

La segunda forma no declara ninguna clase con nombre, no ocupa un lugar en el espacio de nombres de Catalogo y pone la lógica exactamente donde se usa. Quien lee Arrays.sort(...) ve en el acto por qué criterio se ordena, sin ir a buscar otro fichero.

La expresión new Comparator<Material>() { ... } hace tres cosas a la vez:

1. Declara una clase nueva que implementa Comparator<Material>.
2. La instancia.
3. Devuelve esa instancia como valor de la expresión.

Esta es la parte que conviene mirar con lupa, porque tiene una estructura peculiar:

Pieza por pieza:

Ese punto y coma final es la fuente de error número uno con clases anónimas. La razón es que toda la construcción es una expresión dentro de una sentencia, no una declaración de clase. Piénsalo así: si escribes int x = 5;, el ; es evidente. Aquí ocurre lo mismo; lo que despista es que en medio hay una llave de cierre, y el ojo la lee como el final de una clase.

Cuando la anónima va como argumento de un método, el paréntesis de cierre aparece después de la llave, algo que resulta chocante al principio:

Ese }); es la firma visual de una clase anónima en código Java. Aprende a reconocerlo.

La limitación central es no tener constructor. Y la razón es sencilla: un constructor lleva el nombre de su clase, y esta clase no tiene nombre. No hay forma de escribirlo.

¿Y si extiendes una clase que sí tiene constructor? Entonces puedes pasarle argumentos en los paréntesis del new, que se reenvían al constructor de la superclase:

Aquí ("Nuria Vidal", "EMP-003") no es el constructor de la anónima: es la invocación del constructor de Empleado. La anónima recibe un constructor implícito que se limita a reenviarlos.

Si no hay constructor, ¿cómo inicializas un campo con lógica? Con un bloque de inicialización de instancia: un bloque { ... } suelto en el cuerpo de la clase, que se ejecuta al construir el objeto, justo después del constructor de la superclase.

Este mecanismo no es exclusivo de las anónimas —cualquier clase puede tenerlo—, pero aquí es la única vía para ejecutar código de inicialización. El orden completo, ampliando lo que viste en 03-04, es:

En la práctica, si tu clase anónima necesita un bloque de inicialización complejo, considéralo una señal: probablemente merece ser una clase con nombre.

Una clase anónima puede declarar métodos que no están en la interfaz o la clase base. Compilan. Pero hay una trampa:

El motivo es la regla de polimorfismo de 03-06: el tipo declarado decide qué puedes llamar. La variable es de tipo Comparator<Material>, y Comparator no tiene getComparaciones(). Y no puedes declararla del tipo real, porque el tipo real no tiene nombre.

Hay un resquicio, que sirve para entender el mecanismo aunque no lo uses: invocar el método sobre la propia expresión, antes de que el tipo se pierda.

Funciona porque el compilador conoce el tipo anónimo mientras dura la expresión. En cuanto lo asignas a una variable, el tipo se generaliza y el método se vuelve inalcanzable.

Conclusión práctica: los métodos propios de una anónima solo son útiles dentro de ella misma, como auxiliares privados del método que sí forma parte del contrato. Si necesitas exponer métodos nuevos, necesitas una clase con nombre.

Se aplica exactamente la misma regla que a las clases locales (04-03): una clase anónima puede leer variables locales y parámetros del método que la rodea, siempre que sean final o efectivamente finales.

Si en cualquier punto del método escribieras diasTranscurridos = 30;, la variable dejaría de ser efectivamente final y el error aparecería dentro de la clase anónima:

La razón es la que estudiaste en 04-03: la variable local vive en la pila y muere con el método; el objeto anónimo vive en el montón y puede sobrevivirle. Java copia el valor dentro del objeto, y permitir la modificación produciría dos copias descoordinadas.

Y una nota importante que evita confusiones: la restricción afecta a la variable, no al objeto. Puedes capturar una referencia y modificar el objeto al que apunta:

Runnable es la interfaz de las tareas ejecutables; su uso real con hilos es el módulo 8.

Este es el punto que provoca más errores sutiles del módulo, y merece atención completa.

Dentro de una clase anónima, this se refiere a la propia clase anónima, no a la clase que la rodea.

Las dos últimas líneas lo demuestran sin lugar a dudas: this es un objeto de la clase GestorPrestamos$1, la clase anónima que el compilador ha generado (04-03, apartado 9).

Para llegar a la instancia externa hay que escribir ClaseExterna.this, la misma sintaxis de las clases internas.

¿Por qué importa tanto? Porque el error típico es silencioso:

Ese acceso funciona porque no hay ningún ultimoCriterio en la anónima. Pero en cuanto la anónima declara un campo con el mismo nombre —o llamas a un método registrar() que existe en ambas—, la resolución cambia de destino sin avisar y el programa hace algo distinto de lo que esperabas. La regla de resolución, igual que en 04-03: variable local → miembro de la anónima → miembro de la externa.

Guarda esta tabla, porque en 04-05 vas a compararla con el comportamiento de las lambdas y verás que es justo el contrario:

El uso más frecuente. Aquí está el Catalogo de 04-03 reescrito con anónimas, más un tercer criterio compuesto:

El ordenadoPorTipoYTitulo es un buen ejemplo de anónima que sigue justificándose: tiene lógica de varias líneas con una condición intermedia. Ordenar así con un solo compare es exactamente lo que Comparator.comparing().thenComparing() resolverá de forma más elegante en 04-06.

Una devolución de llamada (callback) es un objeto con comportamiento que le pasas a otro para que lo invoque cuando ocurra algo. Es el mecanismo que permite que una clase de servicio notifique sin saber a quién.

Y ahora el uso, con dos oyentes distintos definidos en el punto exacto donde se decide qué hacer:

Fíjate en lo conseguido: GestorPrestamos no sabe nada de recibos ni de alertas. Solo conoce la interfaz OyenteDevolucion y llama a su método. Es la inversión de dependencias de 04-01 en acción, y es la base del patrón Observer que formalizarás en 12-02.

Las anónimas también sirven para crear una variante puntual de una clase existente, típicamente en pruebas:

Y con clases abstractas, que no se pueden instanciar (04-02) pero sí extender anónimamente:

Este uso —crear al vuelo una implementación mínima de una clase abstracta para probar la lógica de la base— es muy habitual en el módulo 11 con JUnit. Y observa el detalle: new Material(...) está prohibido, pero new Material(...) { ... } sí es legal, porque no instancia Material, sino una subclase anónima que sí es concreta.

Con Java 8 llegaron las lambdas, que expresan lo mismo en mucho menos espacio:

Pero la lambda no sustituye a la clase anónima en todos los casos. La regla es tajante:

Una lambda solo puede implementar una interfaz con un único método abstracto (una interfaz funcional, 04-06). Para todo lo demás, sigue haciendo falta una clase anónima.

Ejemplo de anónima insustituible, con estado propio entre llamadas:

La sintaxis completa de la lambda, sus formas abreviadas y sus reglas son el contenido de la lección 04-05. Aquí basta con saber que existe y cuándo no te sirve.

Existe un truco muy difundido que combina una clase anónima con un bloque de inicialización para inicializar objetos "en línea". Se llama double brace initialization por las dos llaves consecutivas:

Se lee así: la primera llave abre la clase anónima, la segunda abre un bloque de inicialización de instancia. Parece elegante y compacto. Es una mala práctica reconocida, por cuatro razones concretas:

1. Crea una clase extra por cada uso. Cada {{ }} genera un fichero .class más. Un método que se llame mil veces con esta sintaxis en un bucle genera una clase, sí, pero mil instancias de una subclase innecesaria.
2. El objeto ya no es de la clase que crees. marta.getClass() devuelve App$1, no Empleado. Y como los equals bien escritos comparan con getClass() (03-09), marta.equals(otroEmpleado) devuelve false aunque tengan el mismo identificador. Es un bug real y difícil de encontrar.
3. Retiene la instancia externa. Es una clase interna no estática: arrastra la referencia oculta this$0 con todo lo que eso implica (04-03), incluida la fuga de memoria si el objeto se guarda en una caché.
4. Rompe la serialización. Una clase anónima no serializa bien (módulo 7).

Las alternativas correctas ya están en tu mano desde el módulo 3:

Dos costes que conviene tener presentes.

Una clase por cada anónima. El compilador genera Externa$1.class, Externa$2.class, Externa$3.class... numerando por orden de aparición. Consecuencias:

• Más ficheros en el .jar y más tiempo de carga de clases al arrancar.
• Trazas de error crípticas: at com.nexussoftware.bibliotech.servicio.Catalogo$2.compare(Catalogo.java:41). El nombre no dice nada; hay que ir a la línea 41 para saber de qué comparador se habla.
• Renumeración: si añades una anónima antes de otra, todas las siguientes cambian de número. En depuración esto despista.

Las lambdas mitigan esto, porque no generan una clase por lambda: usan la instrucción invokedynamic y crean la implementación en tiempo de ejecución. Es una de sus ventajas menos conocidas y es la razón de que las lambdas no encarezcan el arranque como sí lo hacían miles de anónimas.

Legibilidad. Una anónima de tres líneas mejora la lectura, porque pone la lógica donde se usa. Una anónima de treinta líneas destroza la lectura del método que la contiene: el flujo principal queda enterrado bajo una declaración de clase. La regla informal más útil:

Si la clase anónima no cabe entera en la pantalla junto con el código que la rodea, sácala a una clase con nombre.

Este es el resumen del módulo hasta aquí. Guárdalo: responde a la pregunta "¿qué forma de clase uso?" en casi cualquier situación real.

Olvidar el punto y coma final. }; cierra una sentencia, no una clase. Es el error número uno, y el mensaje del compilador (';' expected) apunta a la línea siguiente, lo que despista.

Intentar escribir un constructor. No existe. Usa un bloque de inicialización de instancia, o pasa los argumentos al constructor de la superclase en los paréntesis del new.

Llamar desde fuera a un método propio de la anónima. No compila: la variable tiene el tipo de la interfaz o la superclase. Si necesitas exponer métodos nuevos, necesitas nombre.

Creer que this es la clase externa. Es el error conceptual más caro. Dentro de la anónima, this es la anónima. Usa Externa.this. Y prepárate para que en 04-05 esto sea justo al revés con las lambdas.

Modificar una variable local capturada. Prohibido: debe ser efectivamente final. Pero sí puedes modificar el objeto al que apunta una referencia capturada.

Usar double brace initialization. Cambia la clase real del objeto, rompe equals con getClass(), retiene la instancia externa y genera clases de más.

Anónimas gigantes. Una anónima de treinta líneas dentro de una llamada a método es un método ilegible. Sácala.

Consejo: pon siempre @Override. Igual que en herencia (03-05), detecta al instante una firma mal escrita. Sin él, un compare(Material a, Object b) mal tecleado se convierte en un método nuevo y el compilador se queja mucho más tarde y peor.

Consejo: nombra la variable si vas a reutilizar la anónima. Si el mismo comparador se usa en tres métodos, asígnalo a un campo private static final Comparator<Material> POR_TITULO = new Comparator<>() { ... };. Se crea una sola instancia y el nombre documenta el criterio.

Consejo: el diamante <> funciona desde Java 9. new Comparator<>() { ... } es válido y ahorra repetir el tipo. Antes de Java 9 había que escribir new Comparator<Material>() { ... }.

Escribe un método static void mostrarOrdenado(Material[] materiales, String criterio, int dias) que ordene una copia del array con Arrays.sort usando una clase anónima distinta según el criterio recibido: "titulo" (alfabético ascendente), "plazo" (menor plazo primero) y "multa" (mayor multa primero, para los días indicados). Usa switch de flechas (02-03). Prueba los tres con el catálogo de BiblioTech.

Amplía el GestorPrestamos del apartado 9. Escribe una clase anónima OyenteDevolucion que acumule el número de devoluciones y el total de multas en campos propios, e imprima un resumen cada tres devoluciones. Explica por qué esta anónima no podría ser una lambda.

Escribe una clase Auditor con un campo private String origen = "Auditor" y un método auditar() que cree una clase anónima Runnable con su propio campo origen = "Tarea". Dentro de run(), imprime: el campo de la anónima, el de la clase externa, el nombre de clase de this y el nombre de clase de Auditor.this. Predice la salida antes de ejecutarla.

Solución 1

Dos notas técnicas. Primera: Integer.compare(a, b) y Double.compare(a, b) en lugar de restas manuales; la resta de enteros puede desbordar y la de double obliga a convertir el resultado a int, perdiendo precisión. Segunda: el orden entre los dos libros de plazo 15 se mantiene tal como estaban en el array, porque Arrays.sort sobre objetos es estable. Ese detalle importará mucho en 05-09.

Y una observación que anticipa la próxima lección: los cuatro cuerpos tienen exactamente una línea de lógica útil, envuelta cada uno en cinco líneas de ceremonia. En 04-05 este método entero se quedará en cuatro líneas.

Solución 2

Por qué no puede ser una lambda: una lambda no tiene campos. Su cuerpo solo puede usar sus parámetros, los miembros de la clase envolvente y variables locales capturadas, y estas últimas deben ser efectivamente finales, es decir, no se pueden incrementar. Aquí devoluciones y totalMultas cambian en cada invocación y su valor debe persistir entre llamadas: eso exige estado en el objeto, y estado en el objeto exige una clase. Además, esta anónima usa un bloque de inicialización, algo que tampoco existe en una lambda. Es el caso de manual donde la clase anónima sigue siendo la herramienta correcta en Java 17.

Solución 3

Análisis línea a línea:

1. origen sin prefijo devuelve "Tarea". La resolución va de dentro afuera: no hay variable local con ese nombre, así que gana el campo de la anónima y el de Auditor queda ensombrecido. Este es exactamente el mecanismo por el que un cambio inocente —añadir un campo a la anónima— redirige silenciosamente accesos que antes iban a la clase externa.
2. this.origen es lo mismo que la línea 1, y aquí queda explícito: this es la anónima.
3. Auditor.this.origen es la única forma de llegar al campo de la clase envolvente.
4. this.getClass() devuelve Auditor$1, la clase que el compilador generó (04-03, apartado 9). El 1 indica que es la primera anónima de Auditor; si añades otra antes, esta pasará a ser Auditor$2.
5. Auditor.this.getClass() devuelve Auditor, confirmando que son dos objetos distintos.

Repite este mismo ejercicio al terminar 04-05 sustituyendo la anónima por una lambda: las cinco líneas cambian de resultado, porque en una lambda this es la clase externa. Esa diferencia es la fuente número uno de errores al migrar código antiguo de anónimas a lambdas.

Ya sabes declarar e instanciar una implementación en una sola expresión y sin ponerle nombre. Dominas la sintaxis diseccionada —el tipo que se implementa o extiende, los paréntesis que van al constructor de la superclase, el cuerpo entre llaves y ese punto y coma final que cierra una sentencia, no una clase— y reconoces el }); como la firma visual de una anónima en cualquier código Java que abras.

Conoces sus límites y el motivo de cada uno: no puede tener constructor porque un constructor lleva el nombre de su clase y esta no lo tiene, y por eso existe el bloque de inicialización de instancia; puede declarar métodos propios, pero son inalcanzables desde fuera porque la variable tiene el tipo de la interfaz y el tipo real no se puede nombrar; y captura variables efectivamente finales, con la misma regla y el mismo motivo que las clases locales. Y tienes muy presente la trampa que más caro se paga: dentro de una clase anónima, this es la anónima, no la clase envolvente; para llegar a esta hay que escribir Externa.this.

Has visto los tres usos que la convirtieron en el caballo de batalla de Java durante quince años: el Comparator que ordena el catálogo de BiblioTech por título, por plazo o por multa; la devolución de llamada que permite a GestorPrestamos avisar sin saber a quién, con dos oyentes distintos definidos donde se decide qué hacer; y la extensión puntual de una clase, incluida la de una clase abstracta, que hace legal new Material(...) { ... } allí donde new Material(...) está prohibido. Sabes por qué el double brace initialization es una mala práctica —cambia la clase real del objeto y rompe equals, retiene la instancia externa y genera clases de más— y qué coste tiene cada anónima en el bytecode: un .class numerado, trazas crípticas y renumeración al reordenar.

Y sobre todo te llevas la tabla de decisión: clase de primer nivel cuando el tipo tiene entidad, anidada estática para auxiliares, local para tipos de un solo algoritmo, anónima cuando hace falta estado, varios métodos abstractos o extender una clase, y lambda cuando nada de eso hace falta.

Porque esa última fila es lo que viene ahora. Repasa los comparadores que has escrito en esta lección: cada uno tiene una línea de lógica envuelta en cinco de ceremonia. El nombre de la interfaz ya lo conoce el compilador, porque lo dice el parámetro de Arrays.sort. El nombre del método también, porque Comparator solo tiene uno. Los tipos de a y b también. Todo eso sobra. En la lección 04-05, Expresiones Lambda, quitarás la ceremonia pieza a pieza hasta dejar solo lo que aporta información, aprenderás la sintaxis completa con todas sus formas abreviadas, entenderás qué es realmente una lambda —no un puntero a función, sino la implementación de una interfaz funcional—, verás por qué this se comporta al revés que aquí, y escribirás tus propias interfaces funcionales de BiblioTech para cambiar el comportamiento de una clase sin tocar su código.