====== 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**.

===== 1. Qué se pide =====

  * 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.

===== 2. Con qué =====

  * 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.

===== 3. Decisiones tuyas =====

  * ¿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.

===== 4. Comprobación =====

  * 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.

===== 5. Pendientes =====

  * 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**).