GuíaIntermedio
Guía de Patrones de Diseño
Aprende a leer código ajeno y nombrar lo que ves —"esto es una Strategy", "aquí hay un God object"— y, sobre todo, a saber cuándo un patrón se gana su complejidad y cuándo NO abstraer, porque cada patrón agrega indirección y la indirección se paga. Esta guía no es un catálogo de los 23 patrones GoF para memorizar: cubre los que de verdad aparecen en código real y en revisiones, organizados por el problema que resuelven —comportamiento que varía (Strategy, Template Method, State), creación de objetos (Factory, Builder, por qué desconfiar del Singleton), estructura y adaptación (Adapter, Facade, Decorator, Composite) y comunicación entre partes (Observer, Command)—. También enseña la regla de tres, YAGNI y la abstracción prematura como el error más caro, y cómo usar los patrones como vocabulario de revisión: nombrar code smells (God object, feature envy, shotgun surgery) para que un problema sea accionable. Trabajas sobre Boletia, una plataforma de venta de boletos donde todo varía —canales de notificación, proveedores de pago, tipos de boleto— y que también tiene el otro extremo: una arquitectura de plugins metida para algo que solo va a tener una implementación. Cierra con un proyecto capstone donde quitas una abstracción que no se gana su lugar e introduces el patrón que de verdad emerge de un checkout de 300 líneas, en pasos pequeños y seguros.
- 64
- lecciones
- 8
- módulos
- Inglés · Español
- disponible en
- Sí
- certificado
- Gratis
- acceso
Resultados
Lo que vas a poder hacer
- Entender qué son de verdad los patrones: una solución con nombre a un problema que se repite, y el vocabulario compartido como su verdadero superpoder
- Reconocer cuándo NO abstraer: la regla de tres, YAGNI, y la abstracción prematura como el error más caro que puedes cometer
- Aplicar patrones para el comportamiento que varía: Strategy para intercambiar el "cómo", Template Method para un esqueleto compartido, y State cuando el comportamiento depende del estado
- Aplicar patrones de creación de objetos: Factory para decidir qué construir en un solo lugar, Builder para armar algo complicado por partes, y por qué desconfiar del Singleton
- Aplicar patrones de estructura y adaptación: Adapter para interfaces incompatibles, Facade para una puerta simple a algo complicado, Decorator y Composite
- Aplicar patrones de comunicación entre partes: Observer para avisar sin saber a quién, acoplar por evento en vez de por llamada directa, y Command
- Usar los patrones como vocabulario de revisión de código: nombrar code smells (God object, feature envy, shotgun surgery) y anti-patrones de forma accionable
- Ejecutar un proyecto capstone: refactorizar dos rincones de Boletia —uno sobre-patronado y uno sub-estructurado— y defender cada decisión con su trade-off
Antes de empezar
Qué necesitas traer
Es para ti si...
- Developers que ya programan sobre código de más de un archivo y sienten la fricción de tocar algo y romper algo lejano
- Devs que quieren pasar de "conozco 23 patrones de memoria" a saber leerlos, nombrarlos y juzgarlos en código real
- Personas que necesitan nombrar problemas de estructura en tres palabras dentro de una revisión de código
- Ideal (no obligatorio) para quien ya completó la Guía de Fundamentos del Desarrollo de Software
Requisitos y materiales
- Saber programar y haber trabajado sobre un código de más de un archivo: funciones, clases y objetos
- Recomendado (no obligatorio): Guía de Fundamentos del Desarrollo de Software completada (descomposición, acoplamiento, cohesión, trade-offs)
- No necesitas conocer ningún patrón de diseño previo
- Los ejemplos usan Python orientado a objetos
Contenido
El temario, módulo por módulo
Abre cualquiera para ver sus lecciones.
- 1. Presentación del módulo: patrones como lenguaje, no como recetas
- 2. Un patrón es una solución con nombre a un problema que se repite
- 3. El verdadero superpoder: vocabulario compartido
- 4. De dónde salen los patrones (y por qué no se inventan)
- 5. Leer un patrón en código ajeno
- 6. El mapa: los pocos patrones que de verdad importan
- 7. Cómo NO estudiar patrones
- 8. Proyecto: nombra los patrones de Boletia
- 1. Presentación del módulo: el patrón que no pusiste
- 2. Cada abstracción se paga
- 3. La regla de tres
- 4. Abstracción prematura: el error más caro
- 5. YAGNI: no lo vas a necesitar
- 6. El anti-patrón del plugin para una sola implementación
- 7. Acoplamiento contra indirección: elige tu veneno
- 8. Proyecto: quita una abstracción que sobra
- 1. Presentación del módulo: separa lo que cambia de lo que no
- 2. Strategy: intercambiar el cómo
- 3. Las reglas de precio de Boletia como Strategy
- 4. Template Method: el mismo esqueleto, pasos distintos
- 5. State: cuando el objeto se comporta según su estado
- 6. En un lenguaje con funciones de primera clase, ¿hace falta la clase?
- 7. La trampa: no todo condicional es una Strategy escondida
- 8. Proyecto: reemplaza un `if` gigante con criterio
- 1. Presentación del módulo: el problema de "cómo se construye esto"
- 2. Factory: decidir qué crear en un solo lugar
- 3. Los proveedores de pago de Boletia como Factory
- 4. Builder: armar algo complicado por partes
- 5. Singleton: el patrón del que más hay que desconfiar
- 6. Inyección de dependencias en palabras simples
- 7. Cuándo un constructor o una función alcanzan
- 8. Proyecto: ordena la creación de proveedores
- 1. Presentación del módulo: envolver, adaptar, simplificar
- 2. Adapter: hacer que dos interfaces incompatibles se entiendan
- 3. La API de pago desprolija de Boletia como Adapter
- 4. Facade: una puerta simple a algo complicado
- 5. Decorator: agregar comportamiento sin tocar el original
- 6. Composite: tratar el todo y la parte igual
- 7. La frontera con "solo escribe una función que envuelva"
- 8. Proyecto: aísla una dependencia externa
- 1. Presentación del módulo: quién le avisa a quién
- 2. Observer: avisar sin saber a quién
- 3. Las notificaciones de Boletia como Observer
- 4. Acoplar por evento en vez de por llamada directa
- 5. Command: empaquetar una acción como objeto
- 6. El costo escondido: el flujo que ya no puedes seguir con el dedo
- 7. Cuándo una llamada directa es más honesta
- 8. Proyecto: desacopla la notificación de la compra
- 1. Presentación del módulo: nombrar es la mitad de arreglar
- 2. El vocabulario de lo que está mal: code smells
- 3. God object, feature envy, shotgun surgery
- 4. Nombrar un problema en una revisión para que sea accionable
- 5. Anti-patrones: cuando un "patrón" es la trampa
- 6. Refactorizar hacia un patrón (y hacia afuera de uno)
- 7. El patrón como conversación, no como sentencia
- 8. Proyecto: escribe comentarios de revisión con vocabulario
- 1. Presentación del módulo: el patrón correcto en el momento correcto
- 2. Leer el código antes de tocarlo
- 3. Detectar el patrón que quiere emerger
- 4. Detectar el patrón que hay que quitar
- 5. Refactorizar en pasos pequeños y seguros
- 6. Justificar el cambio (el porqué, no el nombre)
- 7. Cuándo dejar el código feo en paz
- 8. Proyecto final: refactoriza un rincón de Boletia y defiéndelo
Dudas frecuentes
Lo que suele preguntarse
Sin límite. Es una guía gratuita: entras cuando quieras, las veces que quieras.
No. Los módulos están ordenados de menos a más, pero puedes saltar al que necesites. Tu progreso se guarda por lección.
Lo que haga falta está en «Qué necesitas traer», arriba. Si no aparece nada ahí, puedes empezar desde cero.
En el grupo de WhatsApp del Club, y cada quince días hay un live con un instructor donde se resuelven dudas en vivo.
Sí. Al terminar todas las lecciones se emite automáticamente, con un código verificable que puedes compartir en LinkedIn.
Empieza cuando quieras
Lo que dicen los estudiantes
Estas reseñas son de estudiantes inscritos que completaron al menos el 50% del curso. Moderamos las reseñas solo por motivos de contenido (spam, lenguaje ofensivo, datos personales), nunca por ser críticas o negativas.
Aún no hay reseñas aprobadas.
¡Sé el primero en compartir tu experiencia!