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.

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.

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

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

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

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