Design Patterns

Pregunta de entrada

¿Qué colaboración necesito entender o cambiar, y cuándo merece una solución reconocida? Este MOC navega Software Design and Modeling / Patterns and Refactoring. design-pattern sigue siendo el canonical general; las familias orientan problemas y pattern-selection organiza la decisión.

El objetivo es combinar un marco de lectura con profundidad individual cuando resuelve una necesidad real. Reconocer un patrón puede explicar una solución existente. No exige rediseñar cada operación para que tenga un nombre ni convertir el catálogo GoF en una lista de implementación.

Cinco entradas

Pregunta	Documento	Foco
¿Qué es un Design Pattern?	design-pattern	Intención, contexto, colaboración y consecuencias.
¿La presión principal está en crear o configurar?	creational-patterns	Tipos concretos, ensamblaje, familias y lifecycle.
¿La presión principal está en componer o adaptar?	structural-patterns	Interfaz, wrapping, acceso y estructuras compartidas.
¿La presión principal está en comportamiento y coordinación?	behavioral-patterns	Algoritmos, solicitudes, estado y comunicación.
¿Cómo elegir sin sobre-diseñar?	pattern-selection	Fuerzas, alternativas, evidencia y costos.

Si la pregunta comienza por «¿qué patrón puedo usar?», entrar primero por selección. Si alguien ya nombró un patrón, recuperar la familia para entender su intención antes de copiar una estructura.

Problemas con profundidad individual

Pregunta de entrada	Pattern	Variación o problema principal
¿El algoritmo o comportamiento debe variar?	strategy-pattern	Comportamiento intercambiable.
¿Necesito conectar interfaces incompatibles?	adapter-pattern	Incompatibilidad de interfaces.
¿Quiero agregar comportamiento con wrappers componibles?	decorator-pattern	Responsabilidades adicionales combinables.
¿Múltiples dependientes deben reaccionar a cambios?	observer-pattern	Notificación uno-a-muchos.
¿Necesito representar una solicitud como entidad manipulable?	command-pattern	Solicitudes con ejecución y lifecycle propios.
¿Necesito coordinar colaboradores sin referencias directas entre todos?	mediator-pattern	Reglas de interacción entre participantes.
¿El comportamiento depende del estado interno y sus transiciones?	state-pattern	Comportamiento ligado al lifecycle.
¿Necesito construir un objeto complejo progresivamente?	builder-pattern	Proceso de construcción y representación.
¿Quiero simplificar el acceso a un subsistema?	facade-pattern	Entrada coherente de mayor nivel.
¿Necesito representar o controlar acceso a otro objeto?	proxy-pattern	Adquisición, permisos o acceso remoto.
¿La creación concreta debe variar en un protocolo anfitrión?	factory-method-pattern	Punto de creación especializado por extensiones.
¿Necesito crear familias de productos compatibles?	abstract-factory-pattern	Selección conjunta y compatibilidad de familia.

Las entradas orientan candidatos, no respuestas automáticas. La identidad de un patrón depende de intent, context, forces y consequences, no del UML: Strategy y State pueden parecer similares, igual que Decorator y Proxy. pattern-selection organiza esa evaluación.

Familias GoF, comparación compacta

Familia	Pregunta principal	Ejemplos representativos
Creational	¿Cómo crear y configurar objetos?	Abstract Factory, Builder.
Structural	¿Cómo componer o adaptar partes?	Adapter, Decorator.
Behavioral	¿Cómo distribuir comportamiento y colaboración?	Strategy, Observer.

La clasificación procede de Design Patterns, de Gamma, Helm, Johnson y Vlissides. Es una taxonomía influyente, no el universo completo de patrones. Las categorías orientan intención principal sin convertir todas las consecuencias en casillas exclusivas.

También existen catálogos de enterprise applications, concurrencia, integración, domain modeling, sistemas distribuidos, UI y arquitectura. El catálogo de Fowler ofrece un ejemplo de otro contexto. Aquí no se crean esos catálogos ni se trasladan automáticamente las garantías de uno a otro.

Mapa de decisión

Design Problem
     ↓
Understand forces
     ↓
Is recurring structure useful?
     ↓
Candidate pattern family
     ↓
Evaluate consequences
     ↓
Use / reject / simplify

Rechazar un patrón puede ser la decisión correcta. El recorrido no promete terminar con un nombre elegido. Puede confirmar que la función, constructor o colaboración directa actual explica mejor el problema.

Antes de adoptar, poder describir qué cambio queda contenido, quién selecciona la variante y qué costo agrega. La práctica de selección desarrolla ese análisis; el esquema sirve como recordatorio de lectura, no como motor de decisiones.

Recorridos por confusión

Para «¿todo servicio necesita Singleton?», revisar Creational: control de instancias y acceso global son decisiones separables, y el alcance local no prueba unicidad distribuida. Si la duda es solamente quién ensambla colaboradores, examinar esa responsabilidad antes de seleccionar el patrón.

Para «¿adapter significa siempre lo mismo?», revisar adapter-pattern y ports-and-adapters. La adaptación GoF de una interfaz y el rol arquitectónico de frontera pueden coexistir, pero no son identidades obligatorias. internal-structure recupera el alcance de las reglas interiores.

Para «¿dos wrappers son el mismo patrón?», comparar adapter-pattern, decorator-pattern, facade-pattern y proxy-pattern por intención; la tabla de Structural conserva las cuatro preguntas. Para «¿Facade implica un API Gateway?», revisar la frontera de diseño y el alcance distribuido en Facade. Para «¿delegar algoritmo y delegar por estado es lo mismo?», contrastar strategy-pattern y state-pattern, incluyendo quién gobierna selección y transición.

Para «¿Observer ya me da messaging?», ir a observer-pattern y después a reliable-messaging. Revisar primero lifecycle, retirada y ejecución síncrona antes de atribuir garantías de entrega. Para «¿un Command demuestra CQRS?», entrar por command-pattern. Para «¿usar una mediator library prueba el patrón?», entrar por mediator-pattern. Conservar contexto y distinguir mecanismos de responsabilidades.

Para «¿todo Create es Factory Method?», ir a factory-method-pattern y distinguir constructor, static factory y Simple Factory. Para «¿necesito una familia o un proceso de construcción?», contrastar abstract-factory-pattern y builder-pattern; Creational ofrece la comparación compacta.

Para «¿una API fluent ya es Builder?», entrar por builder-pattern y comparar proceso, representación e invariantes. Para «¿State ya me da una State Machine o un workflow engine?», revisar el scope y los límites en state-pattern.

Relación con el Atlas existente

architecture-patterns y architecture-pattern-terminology ayudan a distinguir usos y alcances. Una colaboración local no decide el profile completo. Puede existir una Strategy dentro de un servicio con Ports and Adapters, sin que ninguna de esas decisiones sustituya a las otras.

presentation-patterns organiza MVC, MVP y MVVM en su contexto de UI. Sus notificaciones, comandos o colaboración interna pueden emplear mecanismos relacionados con Design Patterns, pero usar esos nombres no demuestra equivalencia completa.

plugin-architecture aborda contratos de extensión, compatibilidad y lifecycle. Su implementación puede usar factories o estrategias; una factory local no crea por sí sola un sistema de plugins. Seguir esos enlaces cuando la presión cruza el límite de una colaboración.

Lectura y revisión de una propuesta

Una primera lectura útil es concepto general → selección → familia relevante. Después comparar dos soluciones que podrían tener apariencia similar. Evitar leer las tres familias como requisitos simultáneos para toda feature.

Para revisar código existente, reconstruir comportamiento antes de etiquetarlo: qué datos entran, quién decide, quién posee recursos y cómo se comunica un fallo. El patrón reconocido sirve para explicar esa reconstrucción, no para reemplazarla.

Las fuentes históricas y académicas están junto a las afirmaciones de cada canonical. Los ejemplos propios ilustran decisiones y riesgos; no deben confundirse con recetas ejecutables ni con código de los libros.

Cobertura y continuación

La cobertura actual incluye las tres familias, la práctica de selección y doce canonicals individuales: Strategy, Adapter, Decorator, Observer, Command, Mediator, State, Builder, Facade, Proxy, Factory Method y Abstract Factory. Las familias siguen siendo síntesis y los documentos individuales concentran profundidad. Los demás patrones conservan tratamiento representativo, sin exigir materializar un catálogo completo. Code Smells, Anti-Patterns, Refactoring Techniques y SOLID siguen pendientes.

Una futura página individual se justifica cuando aporta profundidad, resuelve una confusión frecuente o conecta conocimiento útil que ya no cabe claramente en la familia. Frecuencia sola no obliga a crearla. La selección editorial debe priorizar valor y mantener los enlaces por ID hacia documentos reales. Completar GoF no tiene prioridad automática frente a huecos del Atlas como Quality Attributes, Data o Security.