¿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, sino una heurística: una forma de razonar sobre la complejidad, la duplicación y el acoplamiento que suele producir mejores resultados, pero que depende del contexto. KISS, DRY, SOLID y el resto de los nombres que vas a ver en este tema no son leyes — son criterios para tomar decisiones de diseño, y aplicarlos mecánicamente 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 una observación de diseño completa 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, casi siempre hay un principio concreto que se está violando — y nombrarlo ayuda a encontrar la solución.
• Dan un criterio para decidir cuánto abstraer. La pregunta constante al diseñar no es “¿qué patrón le meto acá?” sino “¿qué problema concreto tengo, y qué principio describe mejor ese problema?”.

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. La complejidad accidental que resulta de aplicar SOLID a rajatabla en un proyecto chico es tan real como la complejidad accidental de 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 obviar.

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 código de este tema están en Java y varios giran alrededor de OrderService, Order y PaymentProcessor, dentro de un dominio de e-commerce recurrente en los ejemplos.