Design Pattern
Qué es
Design Pattern es una solución reutilizable a un problema recurrente de diseño dentro de un contexto. Describe una organización de responsabilidades y colaboraciones que puede adaptarse a diferentes implementaciones, junto con las consecuencias de elegirla.
El libro de Gamma, Helm, Johnson y Vlissides, conocido como Gang of Four o GoF, constituye una referencia central sobre diseño orientado a objetos. Su catálogo presenta aplicabilidad, restricciones y trade-offs, además de soluciones e implementaciones ilustrativas. Design Patterns: Elements of Reusable Object-Oriented Software.
El concepto no se limita a «uno de los 23 patrones GoF». Ese catálogo reúne soluciones importantes dentro de un marco concreto. POSA también distingue patrones de diseño, patrones arquitectónicos e idioms. Pattern-Oriented Software Architecture, volumen 1. El criterio es capturar una respuesta recurrente con contexto y consecuencias, no aparecer en un único libro.
Qué debe permitir entender
Un patrón ayuda a recuperar intención y colaboración. El ejemplo de Abstract Factory publicado por los propios autores GoF presenta intención, aplicabilidad, participantes, colaboraciones y consecuencias, mostrando que no basta con un diagrama de clases. Extracto original: Abstract Factory.
Una lectura práctica puede organizarse así:
| Aspecto | Pregunta que conviene responder |
|---|---|
| Intent | ¿Qué necesidad de diseño intenta resolver? |
| Context | ¿En qué situación resulta pertinente? |
| Participants | ¿Qué responsabilidades participan en la solución? |
| Collaboration | ¿Cómo cooperan y qué presupone cada una? |
| Consequences | ¿Qué cambia en evolución, uso o comprensión? |
| Trade-offs | ¿Qué costo o restricción aceptamos a cambio? |
Estos aspectos no son un template obligatorio del Atlas. Un nombre facilita la conversación cuando los participantes conocen el razonamiento; si solo recuerdan una forma, la explicación puede seguir siendo incompleta.
La clasificación clásica GoF
El catálogo GoF organiza sus patrones en Creational, Structural y Behavioral: creación de objetos, composición de estructuras y distribución de comportamiento entre participantes. Esa clasificación pertenece a su marco y no define toda la taxonomía posible de soluciones de diseño.
Factory Method, Strategy, Observer y Decorator sirven como ejemplos conocidos de soluciones que normalmente afectan colaboraciones dentro de una parte del software. No se desarrollan aquí como documentos individuales ni se exige aplicar alguno en cada módulo.
Una categoría tampoco determina el efecto completo del patrón. Una colaboración que cambia creación de objetos puede modificar testabilidad; una que distribuye comportamiento puede introducir dependencia de un contrato compartido. La evaluación necesita observar las consecuencias reales.
Ejemplo: reglas variables de cálculo
Supongamos un módulo que calcula una tarifa y acumula condiciones para diferentes tipos de operación. Las reglas cambian con frecuencia, pero el resto de la aplicación necesita un contrato de cálculo estable.
Una organización tipo Strategy permite separar variantes detrás de una responsabilidad común y seleccionar la adecuada según contexto. Puede reducir modificaciones en el consumidor y permitir pruebas de cada variante. También añade indirection y exige definir cómo se selecciona y valida la regla aplicable.
Si solo existe una regla simple y no hay variabilidad real, introducir esa colaboración podría sumar trabajo sin beneficio. El ejemplo no recomienda una implementación particular: permite examinar intención, participantes y trade-offs antes de reconocer un patrón por su nombre.
El mismo propósito puede representarse de distintas formas según el lenguaje y las necesidades. Strategy puede expresarse mediante interfaces/classes, delegates/functions, lambdas, function objects o un mapa de comportamientos. Un patrón describe decisiones de diseño; no obliga a reproducir literalmente las clases de un ejemplo histórico.
Pattern, código y herramienta
Un Design Pattern no es una librería, una feature de framework ni un code snippet que resuelva cualquier caso. Es conocimiento reutilizable sobre una organización. Una biblioteca puede incorporar esa organización, pero usarla no demuestra que se haya comprendido su aplicabilidad.
Tampoco toda función auxiliar constituye un patrón. Una solución particular puede ser adecuada sin tener un nombre reconocido. Reconocer patrones ayuda a comunicar experiencia, no exige etiquetar cada colaboración ni inventar categorías para todo el código.
Conviene distinguir el problema que motiva la solución del mecanismo que la implementa. Adoptar una interfaz, delegación o herencia no permite identificar automáticamente intención, alcance y consecuencias.
Diferencia respecto de Architectural Pattern
architectural-pattern trata una respuesta que condiciona una porción arquitectónicamente significativa del sistema. Design Pattern suele centrarse en colaboraciones locales o dentro de un módulo, sin determinar por sí solo deployment, propiedad de datos o responsabilidades entre organizaciones.
La diferencia principal es scope e impacto, no «pocas clases frente a muchas cajas». Strategy en un cálculo encapsulado suele ser local. Si esa selección define un contrato de extensiones que todos los equipos deben respetar, necesita examinar consecuencias arquitectónicas.
presentation-patterns organiza una colaboración de presentación normalmente más amplia que un Strategy o Decorator local, pero distinta de un Architecture Profile completo. Esa ubicación editorial no impone una escalera universal de tamaños ni exige clasificar igual todas las variantes históricas.
Layered Architecture, Microkernel y Ports and Adapters suelen abordar organización y dependencias de un alcance significativo. No son simplemente una versión más grande de Factory Method. architecture-vs-design explica por qué la frontera depende de compromisos y costos de cambio; architectural-significance ofrece criterios para reconocerlos.
Composición entre alcances
Un sistema puede adoptar un perfil Microservices, organizar un servicio con Hexagonal Architecture y emplear una Strategy dentro de su lógica. La solución local no decide por sí sola cómo se distribuyen datos entre servicios; la organización global no decide cada colaboración interna.
También pueden combinarse distintos patrones locales cuando sus responsabilidades y supuestos son compatibles. Sumarlos sin revisar interacción puede producir abstractions difíciles de comprender o responsabilidades duplicadas.
architecture-profile explica el paquete de decisiones global; architecture-pattern-terminology compara categorías y muestra cómo preservar los usos de cada fuente. Ninguna composición resulta recomendable solamente porque sus nombres sean conocidos.
Selección y consecuencias
pattern-selection desarrolla la práctica de comenzar por el problema y la variación que existe. Comparar la solución directa con alternativas y preguntar qué cambios será necesario soportar. Un patrón puede facilitar evolución y aumentar complejidad actual.
Las consecuencias incluyen comprensión, pruebas, dependencia entre participantes y esfuerzo para introducir nuevas variantes. No todo desacoplamiento útil necesita otra abstracción; no toda abstracción mejora flexibilidad en el escenario que importa.
Evitar pattern hunting, donde se busca encajar un nombre en una necesidad inexistente. También evitar presentar una colaboración como garantía de escalabilidad o mantenibilidad sin especificar condiciones.
Ubicación y navegación
El canonical vive en Software Design and Modeling / Patterns and Refactoring, siguiendo el Knowledge Map V0.3. Su tema es el concepto de patrón; por eso utiliza kind: concept, sin crear anticipadamente una ficha para cada solución concreta.
La convención editorial prioriza patrones con valor práctico y explicaciones suficientes. design-patterns conecta las familias y la práctica de selección. No exige atomizar todo catálogo GoF en microdocumentos. architecture-patterns permite navegar hacia los conceptos vecinos, manteniendo diferencias de alcance y relaciones de composición.