Observer: El Sistema de Suscripciones
Permite que los objetos se suscriban a eventos y sean notificados automáticamente — desacopla los productores de eventos de los consumidores sin que ninguno sepa del otro.
Por qué importa
Cuando colocas un pedido, el sistema debe enviar un correo de confirmación, reservar inventario y registrar un evento de analytics. El enfoque ingenuo pone las tres llamadas dentro de place_order(). Añadir una cuarta reacción — digamos, una notificación de Slack — requiere editar el servicio de pedidos. El patrón Observer invierte esto: el servicio de pedidos emite un evento, y cualquier número de suscriptores reacciona de forma independiente. El servicio permanece estable mientras las capacidades crecen por suscripción.
Formas del mundo real
Los eventos del DOM del navegador, EventEmitter de Node.js, los eventos de dominio en DDD, los brokers de mensajes (RabbitMQ, Kafka) y los streams reactivos (RxJS, asyncio subjects de Python) son todos Observer en esencia. El patrón escala desde callbacks en proceso hasta buses de eventos distribuidos — la idea central permanece igual: productores y consumidores comparten solo un contrato (el tipo de evento), no una implementación.
💡Conclusión clave
Cuando un evento desencadena múltiples reacciones no relacionadas, Observer evita que la fuente conozca todas sus consecuencias — las nuevas reacciones se añaden como nuevos suscriptores, nunca como ediciones a la fuente.
🔧 Algunos ejercicios pueden tener errores. Si algo parece incorrecto, usa el botón Feedback (abajo a la derecha) para reportarlo — nos ayuda a corregirlo rápido.
Pista: Cuando un evento desencadena múltiples reacciones no relacionadas, Observer evita que la fuente conozca todas sus consecuencias.
✗ Tu versión