Heurísticas Prácticas para Aplicar estos Principios

Al diseñar o revisar un componente, estas preguntas ayudan a aplicar los principios generales y SOLID sin caer en la sobreingeniería.

Complejidad

• ¿Esta abstracción es realmente necesaria?
• ¿Podría implementar el requisito de forma más simple?
• ¿El patrón usado resuelve un problema real o solo hace que el diseño parezca más sofisticado?

Duplicación

• ¿El código duplicado representa realmente el mismo conocimiento?
• ¿Estas piezas deberían evolucionar juntas?
• ¿Eliminar la duplicación aumentaría el acoplamiento?

Requisitos futuros

• ¿Esta funcionalidad hace falta realmente?
• ¿Estamos resolviendo un problema conocido o uno hipotético?
• ¿El costo de prepararlo ahora es menor que el costo esperado de cambiarlo después?

Responsabilidades

• ¿Este componente tiene múltiples razones independientes para cambiar?
• ¿Separarlas mejora realmente la cohesión o solo agrega indirección?

Acoplamiento

• ¿Este componente depende de detalles internos de otro?
• ¿La composición podría hacer más explícita esa dependencia?
• ¿Estamos navegando un grafo de objetos que debería estar encapsulado?

Contratos y sustitución

• ¿Puedo reemplazar esta implementación por otra sin que el caller lo note?
• ¿Esta implementación exige más de lo que el contrato promete, o entrega menos?

Interfaces

• ¿Los consumidores de esta interfaz usan realmente todos sus métodos?
• ¿Existen implementaciones que lanzan excepciones en métodos que no les corresponden?

Dirección de dependencias

• ¿La lógica de negocio depende de un detalle de infraestructura concreto?
• ¿Podría invertir esa dependencia sin introducir una abstracción prematura?

Ninguna de estas preguntas tiene una respuesta universal — el objetivo no es marcar todos los casilleros, sino tener el vocabulario para justificar una decisión de diseño y reconocer cuándo una abstracción está resolviendo un problema real y cuándo solo está ahí porque “es lo que corresponde”.