03 - La Forja: el modelo del gremio

La plantilla vive en arrays paralelos que se desincronizan a la primera, la clase de juego sigue siendo un número (1) que solo entiende un switch, la validación está repartida por todo el código y la forja todavía no existe ni como modelo. Este paso construye de una vez el modelo del gremio con las herramientas del tema: clases, visibilidad, getters y setters, constructores, this, miembros estáticos y enumerados; y herencia y super, métodos de Object, polimorfismo, composición, clases abstractas e interfaces.

• El héroe, como objeto:
  • Un héroe, una unidad: todos sus datos viven juntos, no repartidos en arrays con posiciones casadas a ojo. La plantilla pasa a ser un array de objetos.
  • La clase de juego deja de ser un número: es un enum con nombre propio — y cada clase lleva consigo lo que la distingue (para el poder de combate, cada una aporta su valor).
  • Cada héroe recibe un identificador único que nadie teclea: lo asigna el diseño y no se repite entre héroes.
  • Lo que no es válido se detiene donde se guarda: un solo punto decide qué es un nivel (o un nombre, o una clase) correcto, y el resto del programa no repite la comprobación. Esta validación es rudimentaria a propósito — el tema 05 la endurecerá con excepciones —, pero el punto único se construye ya.
  • Los switch con números mágicos desaparecen: la opción del menú se convierte en el enum una sola vez, y a partir de ahí el programa solo habla de clases con nombre.
• La jerarquía:
  • Heroe es una clase abstracta desde el principio: lo común de todo héroe vive en la superclase, y lo específico de cada clase de juego, en su subclase — cada una con su atributo distintivo (la fuerza del guerrero, el maná del mago, la precisión del arquero) y su habilidad con nombre.
  • El poder de combate de un héroe sale de lo común más lo específico de su clase, y cada objeto sabe describirse en su ficha sin que nadie pregunte de cuál es: ahí está el polimorfismo.
  • Los atributos y los métodos comunes no se repiten en las subclases: para eso está el constructor de la superclase.
• La forja:
  • Nace el almacén de ítems: nombre y rareza (enum: común, raro, épico, legendario), y de cada uno hay tres tipos con comportamiento propio — arma con daño, armadura con defensa y poción de curación.
  • Consumir es una acción que no vale para todo: lo consumible se declara en una interfaz; el resto del programa no adivina.
  • La forja no debe guardar dos veces el mismo ítem: dos ítems se identifican por nombre y rareza con equals y hashCode. Hoy solo se garantiza la condición a mano — la estructura que la exigirá llega en el 04.
• El estado:
  • El gremio es un objeto propio: un guerrero es un héroe (herencia), pero el gremio tiene una plantilla y una forja (composición).
• La app sigue pasando todas las pruebas anteriores.

• Todo lo del tema: clases y objetos, visibilidad de los miembros, getters y setters, constructores, this, miembros estáticos y enum; y herencia y super, clases abstractas, interfaces, polimorfismo y enlazado dinámico, composición frente a herencia, y los métodos de Object: toString para las fichas y equals/hashCode para la identidad de los ítems.

• ¿Qué contiene un héroe? Distingue lo esencial (sus datos), lo derivado (lo que se calcula: el poder, la ficha) y lo asignado (lo que el usuario nunca teclea).
• ¿Qué atributos son private y qué getters se publican? Regla de la casa: se publica lo mínimo que alguien necesita usar.
• ¿Qué lleva el enum de la clase: solo el nombre, o también lo que depende de cada una? ¿Y cómo obtiene el resto del programa lo que el enum guarda?
• ¿Quién asigna el identificador y desde dónde se cuenta? Ese contador vivirá tiempo: en el paso 11 es protagonista.
• ¿Qué es exactamente común a todo héroe — y por eso vive en la superclase — y qué es único de cada clase de juego?
• ¿Qué describen las habilidades y cómo se redactan las fichas? ¿Dónde conviene toString y dónde un método propio?
• ¿Qué hace a dos ítems “el mismo ítem”? Fíjate bien: la identidad se decide antes de que ninguna colección la use.
• ¿Qué métodos exige la interfaz de lo consumible y quiénes la implementan?
• ¿Dónde vive ahora el estado del gremio (plantilla, forja, contadores)? ¿La clase del menú deja de tener variables sueltas? ¿Y el límite de plazas se sigue contando igual con objetos?

• Registrar un héroe deja un objeto completo: listar y buscar muestran sus datos juntos, y ninguna posición puede desincronizarse del resto.
• No se puede crear un héroe genérico: la superclase no lo permite, y las subclases sí. Registrar un héroe de cada clase y listar: cada uno con su habilidad y su poder distintos.
• Añadir una cuarta clase de juego no toca el listado ni la ficha: solo nace una subclase, y el poder de la ficha varía de clase en clase porque lo específico pesa.
• El identificador aparece en la ficha sin que nadie lo haya tecleado, y dos héroes no lo comparten.
• Un nivel sin sentido no se guarda ni se calla: el punto de control lo decide, aunque hoy la consecuencia sea solo un aviso.
• En el código ya no quedan números de clase sueltos que interpretar: un solo lugar hace la conversión entre lo que teclea el usuario y el enum.
• Dos ítems con mismo nombre y rareza se consideran iguales; si difieren en cualquiera de las dos cosas, no. Se comprueba a mano: la colección que lo exigirá llega en el 04.
• Consumir una poción aplica su efecto al héroe; equipar un arma o una armadura no pasa por el consumo, porque no lo ofrecen.
• La clase del menú ya no tiene variables sueltas del gremio: el objeto que tiene plantilla y forja las concentra.
• Las pruebas del paso 02 siguen pasando: menú, listado, búsqueda y variantes con la misma consola.

• El array de la plantilla y el de la forja siguen fijando techos artificiales → colecciones (04).
• Consumir una poción exige eliminar elementos mientras se recorre el inventario: ahí hace falta un iterador seguro → (04).
• equals/hashCode de Item espera su consumidor: un Set que rechace duplicados → (04).
• El usuario teclea letras en el nivel y la aplicación tumba, y el punto de control sigue avisando sin lanzar nada → excepciones (05).