04 - La Forja: el inventario deja de tener techo

Los límites de la plantilla y de la forja son techos artificiales: cuando uno se agota, no hay forma de crecer. Además, consumir una poción del inventario de un héroe exige eliminar elementos mientras se recorre. El paso aplica el tema: List, Set, Map, iteración segura con Iterator e implementaciones hash y de árbol.

• Plantilla y forja crecen sin techo: los límites desaparecen del diseño (y con ellos sus avisos de “gremio completo”).
• La forja ya no admite el mismo ítem dos veces: el equals/hashCode del paso 03, al fin, tiene su consumador.
• El consumo de pociones funciona: aplicar el efecto y eliminar la poción del inventario mientras se recorre no debe tumbar el programa.
• El gremio ofrece informes por agrupación: la plantilla organizada por clase de juego, con el tamaño de cada grupo.
• Existe un ranking por poder de combate: el listado en orden es posible sin ordenar a mano cada vez — si el héroe tiene orden natural, la colección lo mantiene.
• Listar, buscar y las variantes del paso 02 siguen pasando todas sus pruebas.

• Todo lo del tema: genéricos, la familia Collection (Set, List), Map con sus dos recorridos (keySet frente a entrySet), iteración segura (Iterator o su equivalente), Comparable/Comparator y las utilidades de java.util.Collections.
• El criterio del tema manda: se declara por la interfaz y se instancia por la implementación. El cambio de implementación no debe tocar ni una línea del resto del programa.
• Ojo con las colecciones: guardan objetos, no primitivos — la plantilla ya lleva héroes desde el 03, pero cualquier contador que vaya a vivir dentro de una colección es un envoltorio.

• ¿Qué estructura resuelve cada requisito y por qué? El diseño del gremio tiene esa atmósfera: si eliges bien, cada línea del requisito justifica una estructura distinta. Justifica cada elección por lo que manda en ella: si el requisito es de orden, de unicidad o de acceso por clave.
• ¿Qué implementación concreta (hash, árbol, índice) elige cada interfaz? ¿Qué gana y qué cuesta frente a las otras?
• ¿El orden natural del héroe es su poder, o prefieres un comparador aparte para el ranking? ¿Y por quién se pregunta si dos héroes empatan?
• ¿Cómo recorre el informe por clase la plantilla: pregunta por clase a clase, o recorre la relación completa clave-valor a la vez?
• ¿Cómo queda el recuento de héroes si la propia colección lo lleva? Ahí el autoboxing trabaja solo — con un envoltorio por valor, que conviene saber leer.

• Registrar más héroes de los que cabían ayer no avisará de nada: la plantilla ya no sabe de techos.
• Intentar meter dos veces el mismo ítem en la forja altera el tamaño una vez, y solo una.
• Consumir una poción de un héroe con varias elimina la correcta sin tartamudear: ningún error de modificación concurrente.
• El listado por clases suma los tamaños de los grupos y es igual al total de la plantilla.
• El ranking se trae el héroe con mayor poder primero, y empatados en poder se resuelven según la decisión documentada.
• Las pruebas de los pasos anteriores no cambian línea a línea: solo cambia la estructura por debajo.

• El usuario introduce letras en el nivel y la aplicación tumba (NumberFormatException); el punto de control de niveles sigue corrigiendo en silencio → excepciones propias (05).
• Los límites del gremio que se quedan (cuántas plazas *máximas* se configuran…) viven escritos en el código → fichero de configuración (05).
• La agrupación por clase aún se escribe a mano → Stream (06).