Por qué seguimos recomendando Design Patterns
El libro del Gang of Four no es un catálogo de clases para copiar. Es un vocabulario para hablar de responsabilidades, acoplamiento, variación y composición. Más de treinta años después, los lenguajes y frameworks hacen parte del trabajo automáticamente; el problema de decidir dónde debe vivir cada cambio sigue siendo el mismo.
De un cambio incierto a un diseño mantenible
- Cambio probableregla · proveedor · canal
- Responsabilidadquién decide · quién ejecuta
- Límitecontrato · dependencia · estado
- Composiciónpolítica · adaptador · middleware
- Pruebacasos · sustitución · aislamiento
- Evolucióncambio localizado · menos riesgo
Resumen corto
Design Patterns documenta soluciones recurrentes para diseñar objetos que colaboran sin quedar atados a una implementación concreta. Su valor no está en memorizar nombres, sino en reconocer fuerzas: qué cambia, qué debe permanecer estable, quién posee una decisión y dónde conviene poner una frontera.
- Un patrón describe una relación y un trade-off, no una receta universal.
- La composición suele permitir variar comportamiento sin crear jerarquías rígidas.
- Las interfaces protegen decisiones que probablemente cambiarán.
- El diseño debe seguir siendo más simple que el problema que resuelve.
Los patrones siguen siendo útiles
Los patrones siguen siendo útiles porque los sistemas todavía integran proveedores, reglas de negocio, estados y flujos que cambian a ritmos distintos. Lo que cambió es la forma de expresarlos: una función, un módulo, una interfaz TypeScript, una dependencia inyectada o un middleware pueden cumplir el papel que el libro muestra con jerarquías de clases.
- Strategy encapsula una política intercambiable: tarifas, validación o selección de rutas.
- Adapter traduce un contrato externo sin contaminar el dominio con su API.
- Decorator añade capacidades como logging, métricas, caché o autorización alrededor de una operación.
- Observer expresa notificaciones y eventos, pero necesita límites de estado, orden y entrega.
Cómo se aplica hoy
Aplicar el libro hoy empieza por encontrar el punto de cambio, no por elegir un patrón. En TypeScript puede ser una función de primera clase o una interfaz pequeña; en Java, una implementación inyectada; en un sistema web, un adaptador de infraestructura o una cadena de middleware. El nombre del patrón ayuda a discutir el diseño, pero el código debe usar el mecanismo más directo que mantenga el contrato claro.
- Separar políticas de negocio de SDKs, bases de datos y frameworks.
- Usar composición y dependency injection para sustituir implementaciones en pruebas y producción.
- Tratar eventos como contratos operativos: duplicados, orden, reintentos y fallos también forman parte del diseño.
- Dejar que el lenguaje haga el trabajo: closures, módulos, tipos algebraicos y pattern matching pueden ser mejores que una jerarquía de clases.
Cuándo no aplicarlos
Un patrón aplicado antes de entender el problema crea indirección, nombres y puntos de extensión que nadie necesita. Si solo existe una variante, una función simple puede ser mejor que Strategy. Si un framework ya ofrece un mecanismo estable, envolverlo con cinco clases puede ocultar la intención. El libro es una caja de herramientas, no una obligación arquitectónica.
- No introducir un patrón para demostrar conocimiento del catálogo.
- No abstraer una variación hipotética sin evidencia de que llegará.
- No confundir más interfaces con mejor diseño.
- Eliminar la abstracción si el código resulta más difícil de leer, probar o depurar.