¿Qué son los Principios de Diseño de Software?

Un principio de diseño de software no es una regla que haya que cumplir siempre. Es una heurística: una forma de razonar sobre complejidad, duplicación y acoplamiento que suele producir mejores resultados, según el contexto.

KISS, DRY, SOLID y el resto de los nombres de este tema no son leyes. Son criterios para tomar decisiones de diseño. Aplicarlos de forma mecánica, sin pensar en el problema concreto, puede producir un diseño peor que no aplicarlos.

Por qué vale la pena conocerlos

• Dan vocabulario común. Decir “esto viola Single Responsibility” o “esto es una violación de DRY” comunica en pocas palabras un diagnóstico de diseño a otro developer que conozca los principios.
• Explican por qué un cambio chico sale caro. Cuando modificar una sola regla de negocio obliga a tocar diez archivos, o agregar un proveedor nuevo obliga a reescribir un if gigante, el síntoma suele apuntar a un principio concreto. Nombrarlo no resuelve el problema, pero acota dónde buscar.
• Dan un criterio para decidir cuánto abstraer. La pregunta al diseñar no es “¿qué patrón le meto acá?” sino “¿qué problema concreto tengo, y qué principio lo describe mejor?”. El patrón, si hace falta, aparece después.

Los principios no son reglas absolutas

Aplicar un principio donde no hace falta agrega indirección, capas y abstracciones que después alguien tiene que entender y mantener. Aplicar SOLID a rajatabla en un proyecto chico produce complejidad accidental tan real como no aplicarlo donde sí hace falta. Cada principio de este tema incluye la contracara — qué significa aplicarlo mal, o cuándo directamente no conviene — porque esa es la parte que más se suele pasar por alto.

Cómo se organiza este tema

• Principios generales de diseño — las seis heurísticas que aparecen antes que nada, sea cual sea el paradigma: cuándo algo es innecesariamente complejo, cuándo duplicar es peor que abstraer (y al revés), y cuánto necesita saber un objeto sobre otro.
• SOLID — los cinco principios específicos del diseño orientado a objetos, con el criterio para no aplicarlos donde no aportan valor.
• Heurísticas prácticas — el checklist de preguntas para usar al diseñar o revisar un componente.

Los ejemplos de este tema están en Java. Varios giran alrededor de OrderService, Order y PaymentProcessor, en un dominio de e-commerce que se repite a lo largo de las entradas.