Parte 4: Patrones de Diseño

En los capítulos anteriores dominamos los fundamentos de OOP (Fundamentos de la Programación Orientada a Objetos), las relaciones entre objetos (Encapsulamiento y Relaciones entre Objetos), herencia y polimorfismo (Herencia y Polimorfismo Conceptual y Herencia y Polimorfismo en Java), y el diseño por contratos (Diseño por Contratos).

Ahora aplicamos todo ese conocimiento en patrones de diseño: soluciones elegantes y probadas a problemas que aparecen una y otra vez en el desarrollo de software.

Navegación por Familias¶

Esta portada funciona como mapa general. Para entrar a cada familia y navegar sus patrones individuales:

Práctica de cursada¶

Parte 4 ya funciona como referencia. Para usarla como tramo de cursada, conviene trabajarla así:

Orden sugerido de lectura¶

Capítulos nucleares¶

Estos capítulos conviene dominarlos sí o sí para construir un criterio de diseño reutilizable:

Repaso y ampliación¶

Estas páginas cumplen mejor un rol de navegación, consolidación o profundización:

Índice exhaustivo¶

Creacionales¶

• Familia Creacional

• Singleton

• Factory Method

• Abstract Factory

• Builder

• Prototype

• Ejercicios integradores de patrones creacionales

Estructurales¶

• Familia Estructural

• Adapter

• Bridge

• Composite

• Decorator

• Facade

• Flyweight

• Proxy

• Ejercicios integradores de patrones estructurales

Comportamiento¶

• Familia de Comportamiento

• Chain of Responsibility

• Command

• Interpreter

• Iterator

• Mediator

• Memento

• Observer

• State

• Strategy

• Template Method

• Visitor

• Ejercicios integradores de patrones de comportamiento

¿Qué son los Patrones de Diseño?¶

Definición¶

Un patrón de diseño es una solución general y reutilizable a un problema común en el diseño de software. No es código listo para usar, sino una plantilla o receta que describe cómo resolver un problema en diferentes contextos.

Los patrones de diseño, establecen un lenguaje, y aunque no se utilice exactamente como se lo describe aquí, facilita la comunicación entre desarrolladores, introduciendo conceptos reutilizables de alto nivel.

Origen e Historia¶

Los patrones de diseño en software se popularizaron con el libro de los “Gang of Four” (GoF) en 1994:

• Erich Gamma

• Richard Helm

• Ralph Johnson

• John Vlissides

Documentaron 23 patrones clasificados en tres categorías:

Anatomía de un Patrón¶

Cada patrón se describe con:

1. Nombre: Identificador conciso y memorable

2. Problema: Cuándo aplicar el patrón

3. Solución: Estructura de clases y objetos

4. Consecuencias: Trade-offs y resultados

Beneficios¶

1. Vocabulario común: “Usemos un Observer aquí” es más claro que explicar toda la estructura

2. Soluciones probadas: No reinventar la rueda

3. Diseños flexibles: Anticipan cambios futuros

4. Documentación implícita: El nombre del patrón comunica la intención

Patrones Creacionales¶

Los patrones creacionales abstraen el proceso de instanciación de objetos, haciendo el sistema independiente de cómo se crean, componen y representan los objetos.

Para un análisis profundo de patrones creacionales, incluidos Singleton, Factory Method, Abstract Factory, Builder y Prototype, consultá la sección dedicada: índice de patrones creacionales.

Resumen Rápido¶

Patrones Estructurales¶

Los patrones estructurales se ocupan de cómo se componen las clases y objetos para formar estructuras más grandes, facilitando la comunicación entre entidades.

Para un análisis profundo de patrones estructurales, incluidos Adapter, Bridge, Composite, Decorator, Facade, Flyweight y Proxy, consultá la sección dedicada: índice de patrones estructurales.

Resumen Rápido¶

Patrones de Comportamiento¶

Los patrones de comportamiento se ocupan de algoritmos y la asignación de responsabilidades entre objetos.

Para un análisis profundo de patrones de comportamiento, incluidos Strategy, Observer, Template Method, State, Command y otros, consultá la sección dedicada: índice de patrones de comportamiento.

Resumen Rápido¶

¿Cuándo Usar (y No Usar) Patrones?¶

Señales de que Necesitás un Patrón¶

Señales de que NO Necesitás un Patrón¶

• El código es simple y funciona bien

• Solo hay una implementación posible

• No hay necesidad de extensibilidad

• El patrón agrega complejidad sin beneficio claro

• “Por si acaso lo necesite en el futuro”

Ejemplo: Combinando Patrones¶

Un sistema real suele combinar varios patrones:

// FACTORY: crea procesadores según el tipo
ProcesadorFactory factory = new ProcesadorFactory();
Procesador proc = factory.crear(tipoArchivo);

// STRATEGY: diferentes algoritmos de compresión
proc.setCompresion(new CompresionZIP());

// DECORATOR: agrega funcionalidades
proc = new ProcesadorConLog(proc);
proc = new ProcesadorConCache(proc);

// OBSERVER: notifica progreso
proc.agregarObservador(new BarraProgreso());
proc.agregarObservador(new Logger());

// TEMPLATE METHOD (interno al procesador)
proc.procesar(archivo);

Resumen¶

Patrones Creacionales¶

Patrones Estructurales¶

Patrones de Comportamiento¶

Principios Clave¶

1. Identificá el problema primero: No busques patrones, buscá soluciones

2. Preferí composición sobre herencia: Más flexible

3. Programá hacia interfaces: Más desacoplado

4. Evitá la complejidad innecesaria: YAGNI (You Aren’t Gonna Need It)

Próximo paso¶

Para seguir, conviene entrar a una familia concreta de patrones: creacionales, estructurales o de comportamiento.