¿Qué busca el principio DRY principalmente?

• Escribir más rápido

• Evitar duplicar lógica y centralizarla

• Usar más patrones de diseño

• Aumentar el número de clases

Beneficio directo de aplicar DRY:

• Menor cantidad de puntos de cambio

• Compila más rápido

• Usa menos RAM

• Evita null pointers automáticamente

¿Qué situación viola DRY?

• Extraer un método común y reutilizarlo

• Copiar/pegar el mismo cálculo en 4 métodos

• Centralizar constantes en una clase

• Usar una librería ya probada

Tienes varias clases calculando IVA con la misma fórmula. ¿Qué opción sigue DRY?

• Dejar cada clase con su cálculo

• Crear CalculosImpuestos.calcularIVA() y llamarlo

• Escribir una interfaz IVAable sin implementación

• Añadir el cálculo a cada constructor

KISS se resume mejor como:

• “Entre más capas, mejor”

• “Mantén lo más simple que funcione”

• “Refactoriza solo al final”

• “Primero optimiza, luego escribe”

¿Qué versión refleja KISS para decidir entre dos textos?

• if/else con logs, métricas y validaciones

• Un switch con dos casos

• Operador ternario simple

• Una estrategia con tres clases

¿Qué práctica rompe KISS?

• Nombres de variables claros

• Funciones cortas con una responsabilidad

• Condicionales profundamente anidadas sin necesidad

• Retornos tempranos (guard clauses)

¿Cuál enuncia mejor YAGNI?

• “Implementa todo lo que podría pedirse después”

• “Primero abstrae, luego pregunta”

• “No construyas lo que hoy no necesitas”

• “Siempre diseña para 10 años”

¿Qué decisión sigue YAGNI?

• Crear 3 capas de repositorio aunque solo haya una lista en memoria

• Definir 5 DTOs por si crece el sistema

• Agregar campos “futuros” a entidades

• Implementar solo los campos requeridos hoy

Caso típico de violar YAGNI:

• Añadir un parámetro que nadie usa aún

• Escribir pruebas de lo que existe

• Refactorizar código duplicado

• Encapsular una constante común