Si entras a portales especializados como Refactoring Guru, vas a ver que existen 22 patrones clásicos (los del famoso grupo Gang of Four). Aprenderse todos de memoria es una locura. La clave está en entender que se dividen en tres grandes categorías, según el "chicharrón" que vienen a resolver:
1. Patrones Creacionales: ¿Cómo creamos los objetos?
Estos patrones se encargan de definir el mecanismo para crear objetos en el sistema. Su meta es que tu código no dependa de cómo se crean, componen o representan esos objetos, evitando llenar todo de new Clase() de forma desordenada.
¿Cuándo se usan? Cuando la creación de un objeto es compleja, depende de configuraciones externas o necesitas controlar cuántas instancias se crean.
Los más famosos de este grupo:
Singleton: Una única instancia para toda la app (ej. la conexión a la base de datos).
Factory Method: Una fábrica que decide qué objeto crear por ti según la situación.
Abstract Factory: Una super-fábrica que crea otras fábricas (para cuando manejas familias de productos).
Builder: Ideal para crear objetos gigantes paso a paso (ej. un constructor de consultas SQL complejas).
2. Patrones Estructurales: ¿Cómo armamos el rompecabezas?
Estos patrones se enfocan en cómo se unen las clases y objetos para formar estructuras más grandes y eficientes, sin perder flexibilidad ni volverse una estructura rígida.
¿Cuándo se usan? Cuando tienes muchas clases que necesitan trabajar juntas, o cuando necesitas que código viejo (legacy) se entienda con código nuevo sin cambiarlo todo.
Los más famosos de este grupo:
Adapter: Funciona como un transformador de corriente. Permite que dos interfaces que no tienen nada que ver puedan trabajar juntas (ej. conectar una librería externa vieja a tu backend moderno).
Decorator: Te permite añadirle superpoderes o funciones a un objeto en tiempo de ejecución sin alterar su clase original.
Facade (Fachada): Te da una interfaz simple para esconder un sistema supercomplejo que hay detrás. El usuario solo ve un botón, pero por dentro se mueven mil engranajes.
3. Patrones de Comportamiento: ¿Cómo se hablan entre sí?
Aquí no nos importa tanto cómo se crean las clases o cómo se estructuran, sino cómo se comunican y qué responsabilidades tiene cada una al ejecutar algoritmos o procesos del negocio.
¿Cuándo se usan? Cuando necesitas gestionar flujos de datos complejos, eventos, estados o cadenas de decisiones entre muchos objetos.
Los más famosos de este grupo:
Observer: El sistema de suscripción/notificaciones que vimos antes.
Strategy: Te permite cambiar el algoritmo o la lógica que usa una clase en tiempo de ejecución (ej. cambiar la estrategia de envío de "Efecty" a "Nequi" con un solo clic).
State: Permite que un objeto cambie su comportamiento dependiendo del estado en el que esté (ej. un pedido no hace lo mismo si está en estado "Pendiente" que en estado "Enviado").
Tabla Resumen para Guardar en Favoritos
Para que tus lectores no se pierdan, les puedes dejar este "machete" (tarjeta de referencia rápida):
| Familia | ¿Cuál es su objetivo principal? | Ejemplo de la vida real |
| Creacionales | Controlar e independizar la creación de objetos. | El mesero que te trae la comida de la cocina sin que sepas la receta. |
| Estructurales | Organizar clases para que encajen de forma flexible. | El adaptador que usas para conectar tu celular en un avión. |
| De Comportamiento | Gestionar la comunicación y lógica entre objetos. | Un grupo de WhatsApp donde el administrador manda un mensaje y todos reaccionan. |
Comentarios
Publicar un comentario