Paradigmas de programación

Taller 1

En parejas o equipos de tres personas

Se les entrega un juego de Godot en C# que ya funciona, pero está mal organizado.

El taller no es hacer el juego. Es reorganizarlo aplicando correctamente los conceptos de POO, y extenderlo sin romper lo que ya anda.

⬇ Descargar el proyecto base

El juego base

Un vendedor de madera (Pawn) recorre el mapa. Hoy:

• Se mueve, se anima y tiene contador de madera y monedas
• El Lancer le compra: descuenta 1 madera, suma 1 moneda
• El Goblin está en el mapa y se anima, pero no tiene implementada la interacción de robo
• La tecla Z existe, dice "Z para resumir" y solo imprime un texto

El objetivo

⬇ Descargar el diagrama (Draw.io) — es el mínimo. Lo que haga falta para limpiar el código va por encima.

Parte 1 — Limpiar la base

Hoy Lancer.cs, Goblin.cs y Monk.cs tienen el mismo bloque de código copiado tres veces: el campo _animator, el _Ready() y un _Process() vacío.

• Extraer la clase base NPC con lo común
• Lancer, Goblin y Monk deben derivar de NPC
• Que no quede ni una línea duplicada entre los tres

Parte 2 — Las interfaces

Este es el corazón del taller. Hoy el vendedor pregunta por el tipo concreto:

// ANTES  (Seller.cs)
if (_npc is Lancer lancer)
    lancer.Buy(this);

// DESPUES
if (_npc is IBuyer buyer) buyer.Buy(this);
if (_npc is IThief thief) thief.Steal(this);
          

Crear IBuyer (Price, Buy) e IThief (Steal), y que el Seller deje de conocer clases concretas.

Parte 3 — El Monk

El proyecto ya trae el sprite, la escena monk.tscn y un Monk.cs vacío.

• Convertirlo en un segundo comprador: Monk : NPC, IBuyer
• Debe pagar un precio distinto al del Lancer
• Agregarlo a world.tscn, porque todavía no está en el mapa

Prueba de fuego: si el refactor está bien hecho, el Seller no se toca para que esto funcione.

Parte 4 — El Goblin roba

• Implementar Goblin : NPC, IThief con su método Steal
• Al intentar venderle, el vendedor pierde producto
• El robo se refleja en el HUD

Regla concreta: si el vendedor no tiene madera, el Goblin no puede robar y no se descuenta nada.

Parte 5 — Las transacciones

• Crear Transaction con NPC y TotalCounts como mínimo, y sus dos especializaciones: Sale y Theft
• El Seller compone la lista: las crea, las posee y mueren con él
• Cada venta y cada robo quedan registrados

Una transacción por NPC: venderle dos veces al mismo Lancer no crea dos instancias — incrementa el TotalCounts de la que ya existe.

Parte 5 — El historial

La tecla Z debe imprimir el historial de transacciones: qué NPC, qué tipo de transacción y cuánto acumula cada uno.

Ustedes deciden el formato y qué más guarda cada transacción. Justifíquenlo en la sustentación.

Reglas del refactor

• El juego debe seguir funcionando igual que antes, más lo nuevo
• Si rompieron el juego, el refactor falló — por más lindo que quedó el diagrama

Debe seguir andando: moverse, animarse, el contador de madera, el contador de monedas, el indicador de "X para vender" y la venta al Lancer.

Prohibido

La regla debe salir del diseño, no de un condicional:

• if (npc is Lancer) o cualquier chequeo de tipo concreto
• Comparar Name, strings o tags para decidir si vende o le roban
• Banderas tipo esComprador o esLadron
• Repetir el bloque _animator + _Ready() en cada NPC

Calidad del código

Esto se evalúa aparte:

• _Process() no lleva lógica de negocio: orquesta y delega a métodos con nombre
• Cero números mágicos: velocidad, madera inicial, precios y cantidad robada son constantes o [Export]
• Una clase por archivo, nombres significativos
• Encapsulamiento real: nadie modifica los contadores desde afuera a la fuerza

El diagrama final

El diagrama que entregan no es el que les di.

• Debe reflejar el refactor completo, no solo el mínimo
• Toda clase, atributo, método y relación que exista en el código debe estar en el diagrama
• Y al revés: nada en el diagrama que no exista en el código

Espejo exacto. Si crearon una clase extra para limpiar algo, va al diagrama.

Entregables

• El proyecto de Godot con el refactor completo
• El diagrama de clases final en Draw.io, espejo exacto del código
• Demostración en clase: vender al Lancer, vender al Monk a otro precio, que el Goblin robe, y Z mostrando el historial
• Sustentación individual

Criterios de evaluación

• (20%) Jerarquía NPC y eliminación de la duplicación
• (25%) Interfaces IBuyer / IThief y eliminación del chequeo de tipo concreto
• (10%) Monk como segundo comprador con precio propio
• (10%) Goblin.Steal funcionando
• (15%) Transacciones (Sale / Theft) e historial con Z
• (10%) Calidad del código
• (10%) Diagrama final completo y espejo del código

⚠️ Importante

El taller no será evaluado si:

• El proyecto no compila o no corre
• El diagrama final no corresponde con el código entregado
• El integrante no sustenta la entrega

No hay excepciones.