====== 02 - La Forja: primera versión funcional ======

El diseño del paso 01 pasa a Java: La Forja existe y atiende a un **solo usuario** en la consola. Se usa el repertorio del tema y solo él: variables y constantes, la clase **IO**, estructuras de selección, bucles, **arrays** y ya también **funciones**, con las que nombrar cada acción. Es la versión más humilde del curso: los héroes viven en arrays paralelos y el programa entero en una sola clase — no porque no se pueda hacer mejor, sino porque lo que molesta hoy es la motivación de los pasos que vienen.

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

La primera versión funcional del gremio:

  * Menú que se muestra y se repite hasta que el usuario elige salir, y que **solo orquesta**: cada opción es una llamada a una función con nombre, y ninguna secuencia de instrucciones vive suelta en el ''main''.
  * Registro de héroes con nombre, clase y nivel, con las validaciones decididas en el diseño del paso 01.
  * Listado de la plantilla y búsqueda de un héroe por nombre.
  * Un **límite de plazas**: constante con nombre; si el gremio se llena, el registro avisa en vez de corromper datos.
  * El estado del gremio (los datos, los contadores, el límite) en **variables de clase**: toda función lo ve sin pasarlo de mano en mano.
  * El **poder de combate** de un héroe es un cálculo, no una impresión: una función con su entrada y su devolución, que la ficha ya usa.
  * Una acción con **variante**: misma responsabilidad, distinta lista de parámetros — por ejemplo, listar toda la plantilla frente a listar los héroes que superan un nivel mínimo.
  * Mensaje conveniente en cada caso: confirmación, aviso, error u opción inválida.

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

  * Todo lo del tema: variables y constantes, ''IO.readln''/''IO.println'', estructuras de selección, bucles, arrays, y cabecera y cuerpo, **devolución** de valores, **ámbito**, paso de parámetros, **variables de clase** y **sobrecarga**.
  * Las decisiones del diseño del paso 01 siguen vigentes (datos, validaciones, mensajes); este paso decide además dónde vive cada instrucción y quién puede llamarla.

^ Diseño (paso 01) ^ Herramienta de Java ^
| pseudocódigo ''REPETIR...HASTA'' | el bucle del menú |
| ramas 'SI opcion...' | la estructura de selección |
| guardar los datos de cada héroe | arrays paralelos (nombre, clase, nivel) |
| el límite de plazas que no se repite | **constante** |
| la acción con nombre del diagrama | **función** |
| leer / imprimir | ''IO'' |

<note tip>Cada limitación que duela hoy justifica el concepto de un tema futuro: arrays paralelos, clases de juego como números y validación repartida son dolores que esconden pasos. Se escriben funciones porque el tema las trae; no se adelanta nada más: ni objetos, ni colecciones, ni excepciones.</note>

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

  * ¿Cómo representas cada héroe con **solo arrays**? Sus datos tienen que viajar juntos y en su posición correcta: si la correspondencia entre posiciones se rompe, el héroe queda corrompido.
  * ¿Cuántas funciones necesitas y cómo se llaman? Un nombre dice lo que hace la función, y la función hace solo eso.
  * ¿Qué pasa por **parámetros** y qué se lee de las variables de clase? Elige un criterio y sostenlo: mezclar ambos caminos al azar es el desorden que el tema viene a evitar.
  * ¿Qué funciones devuelven un valor y qué devuelven: un cálculo, un resultado de búsqueda, un estado?
  * ¿Dónde vive el cálculo del poder? Piensa que en el paso siguiente la ficha y los informes lo van a necesitar por separado.
  * ¿Cómo conviertes lo que teclea el usuario para la clase (''1'', ''2'', ''3''...) en algo con significado para el programa? Que ese lugar sea uno solo: en el 03 la conversión tendrá que salir a otra parte.
  * ¿Cómo decides si un nombre está en la plantilla? ¿Y qué quiere decir "encontrado" si hay varios héroes con nombres parecidos?
  * ¿Cómo sabes cerrar cada bucle y contarlo: por posición, por contador de usados...?
  * ¿Existe alguna función con estructura anidada que pida **recursividad**? Si la respuesta es no, se argumenta en el propio código y queda para los ejercicios del tema.

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

  * El menú se repite y solo sale con su opción; una opción rara no tumba el programa: avisa y vuelve. El ''main'' cabe en un pantallazo: menú y llamadas.
  * Cada función hace una cosa y cabe en la pantalla; ninguna mezcla menú con cálculo, ni cálculo con impresión: la que calcula devuelve el valor y quien llama decide qué hacer con él.
  * Registrar un héroe y después listar y buscar muestra sus datos juntos y en el lugar correcto; en búsquedas fallidas el aviso es el decidido en el diseño, y el listado en vacío no muestra basura.
  * Las dos variantes de la acción sobrecargada se llaman igual y se distinguen por su lista de parámetros, y cualquiera de las dos se invoca sin tocar el resto.
  * Un registro con el gremio lleno avisa de que no hay plazas — y las plazas ocupadas no se pierden ni se mezclan con el siguiente intento.
  * Una clase o un nivel sin sentido avisan, como se decidió en el paso 01; escribir **letras** donde van números tumba la app: se anota en los pendientes, porque arreglarlo aún no se sabe.
  * La despedida se muestra solo al salir.

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

  * Los arrays paralelos se desincronizan a la primera, y la clase sigue siendo un número que solo entiende el ''switch'' -> objetos y **enum** (**03**).
  * La validación vive repartida por el código y teclear letras en el nivel tumba el programa (''NumberFormatException'') -> punto único de control y **excepciones** (**05**).
  * Cuando la capacidad se agota no hay forma de crecer -> colecciones (**04**).