Observer

Reaccionar sin estar pendiente

Esta es la lectura de la sesión asincrónica S5 V. Cierra el Bloque B+C del curso: ya vimos Factory Method (cómo se crean los objetos) y Singleton (cuántas instancias hay). Observer responde una pregunta distinta: ¿cómo aviso a otros objetos cuando algo cambia —sin que el que avisa tenga que conocerlos a todos?

Es un patrón de comportamiento, y de los más presentes en el código que ya usás todos los días: los eventos de Eloquent en Laravel, las signals de Django, el EventEmitter de Node. Cuando termines esta lectura vas a reconocerlo en todos ellos.

Tip de lectura: tocá, enfocá o pasá el mouse sobre las líneas marcadas para ver por qué importan.

Conceptos rápidos

En las anotaciones aparecen algunos términos. Si no los tenés frescos, esta es la versión corta:

• Sujeto (subject / observable): el objeto cuyo cambio de estado dispara las reacciones. Mantiene la lista de observadores y los notifica.
• Observador (observer): el objeto que se suscribe al sujeto y reacciona cuando éste avisa. Conoce al sujeto; el sujeto no lo conoce a él.
• Suscribir / desuscribir: agregar o quitar un observador de la lista del sujeto, sin modificar al sujeto.
• Notificar: recorrer la lista de observadores y llamar al método de cada uno (update, onPriceChanged, etc.).
• Uno-a-muchos: un sujeto, muchos observadores. Es la relación que define el patrón.
• OCP (abierto/cerrado): el principio SOLID de S2 — abierto a extensión, cerrado a modificación. Observer es OCP aplicado a las reacciones.

No tenés que memorizarlos. Si una anotación menciona uno y no lo recordás, volvé acá un momento y seguís.

1 — El método que lo sabe todo

Empecemos por el dolor concreto. En el legacy, cuando un pedido cambia de estado, alguien tiene que reaccionar: mandar un email, un SMS, una notificación push. ¿Quién dispara todo eso? El propio Order, dentro de un método notify() que conoce a cada reaccionador por su nombre.

Mirá el método de abajo. Para avisar de un evento, Order instancia EmailService, SMSService, PushService y decide a mano quién reacciona a qué. La pregunta que duele: ¿qué pasa cuando el negocio quiere agregar notificaciones por WhatsApp?

// app/Models/Order.php — el notify() real del legacy
class Order
{
    public function notify(string $event): void
    {
        $email = new EmailService();
        $sms = new SMSService();
        $push = new PushService();

        if ($event === 'created') {
            $email->send(...); $sms->send(...);
        } elseif ($event === 'paid') {
            $email->send(...); $push->send(...);
        } // ... 7 eventos más ...
    }
}

// Order.java — el notify() real del legacy
class Order {
    public void notify(String event) {
        EmailService email = new EmailService();
        SMSService sms = new SMSService();
        PushService push = new PushService();

        if (event.equals("created")) {
            email.send(...); sms.send(...);
        } else if (event.equals("paid")) {
            email.send(...); push.send(...);
        } // ... 7 eventos más ...
    }
}

// order.ts — el notify() real del legacy
class Order {
    notify(event: string): void {
        const email = new EmailService();
        const sms = new SMSService();
        const push = new PushService();

        if (event === 'created') {
            email.send(...); sms.send(...);
        } else if (event === 'paid') {
            email.send(...); push.send(...);
        } // ... 7 eventos más ...
    }
}

# order.py — el notify() real del legacy
class Order:
    def notify(self, event):
        email = EmailService()
        sms = SMSService()
        push = PushService()

        if event == 'created':
            email.send(...); sms.send(...)
        elif event == 'paid':
            email.send(...); push.send(...)
        # ... 7 eventos más ...

Son tres problemas en un mismo método. Acoplamiento: Order importa e instancia cada servicio; cambiar cualquiera obliga a tocar Order. Crecimiento infinito: cada canal nuevo agrega líneas. Cerrado a la extensión: para sumar un reaccionador hay que editar el modelo de negocio central — justo lo que OCP nos dijo que evitáramos.

La pregunta de diseño, la misma que abrió Strategy en su momento: ¿qué debería saber Order sobre quién reacciona a sus eventos? La respuesta sana es: nada.

2 — El sujeto avisa, los observadores reaccionan

Pensá en un newsletter. Un medio no llama a cada suscriptor uno por uno cuando publica. Publica — y los que se registraron reciben la notificación. El medio no sabe quiénes son ni cuántos; solo sabe que publicó. O un semáforo: no llama a cada auto, cambia de color y cada auto que está mirando reacciona a su manera.

Esa es la idea de Observer. Hay un sujeto (lo observable) que emite un cambio, y varios observadores que se suscribieron y reaccionan. El sujeto no conoce a los observadores concretos: solo sabe que existe una lista de "alguien que implementa la interfaz observadora" a quien avisar.

// Las dos abstracciones de Observer (estructura conceptual)
interface OrderObserver
{
    public function update(Order $order, string $event): void;
}

abstract class Subject
{
    protected array $observers = [];
    public function subscribe(OrderObserver $o): void { ... }
    public function unsubscribe(OrderObserver $o): void { ... }
    protected function notifyObservers(string $event): void { ... }
}

// Las dos abstracciones de Observer (estructura conceptual)
interface OrderObserver {
    void update(Order order, String event);
}

abstract class Subject {
    protected List<OrderObserver> observers = new ArrayList<>();
    public void subscribe(OrderObserver o) { ... }
    public void unsubscribe(OrderObserver o) { ... }
    protected void notifyObservers(String event) { ... }
}

// Las dos abstracciones de Observer (estructura conceptual)
interface OrderObserver {
    update(order: Order, event: string): void;
}

abstract class Subject {
    protected observers: OrderObserver[] = [];
    subscribe(o: OrderObserver): void { ... }
    unsubscribe(o: OrderObserver): void { ... }
    protected notifyObservers(event: string): void { ... }
}

# Las dos abstracciones de Observer (estructura conceptual)
class OrderObserver(Protocol):
    def update(self, order: Order, event: str) -> None: ...

class Subject:
    def __init__(self): self._observers = []
    def subscribe(self, o): ...
    def unsubscribe(self, o): ...
    def _notify_observers(self, event): ...

La definición canónica (GoF): "Observer define una dependencia uno-a-muchos entre objetos, de modo que cuando uno cambia de estado, todos los que dependen de él son notificados automáticamente." Uno-a-muchos: un sujeto, muchos observadores. Y la flecha de conocimiento va en un solo sentido — el observador conoce al sujeto, pero el sujeto no conoce a los observadores concretos.

3 — Las tres piezas en código

Observer se arma con tres piezas, y conviene escribirlas en este orden: primero el contrato (la interfaz observadora), después las implementaciones concretas, y al final el refactor del sujeto para que mantenga la lista y notifique. El "aha" llega en el tercer paso.

Acá está el sujeto ya refactorizado. Fijate lo que desapareció: ya no hay new EmailService() dentro de recalculate. En su lugar, una lista de observadores y un foreach. El sujeto perdió todo conocimiento de quién reacciona.

// Paso 1 — el contrato
interface PriceObserver {
    public function onPriceChanged(string $product, float $newPrice): void;
}

// Paso 3 — el sujeto refactorizado (el "aha")
class PriceEngine {
    private array $observers = [];

    public function subscribe(PriceObserver $o): void {
        $this->observers[] = $o;
    }

    public function recalculate(string $product, float $newPrice): void {
        foreach ($this->observers as $o) {
            $o->onPriceChanged($product, $newPrice);
        }
    }
}

// así se usa — el wiring vive afuera del sujeto
$engine = new PriceEngine();
$engine->subscribe(new CacheObserver());
$engine->subscribe(new AuditObserver());
$engine->recalculate('laptop', 899.99);

// Paso 1 — el contrato
interface PriceObserver {
    void onPriceChanged(String product, double newPrice);
}

// Paso 3 — el sujeto refactorizado (el "aha")
class PriceEngine {
    private List<PriceObserver> observers = new ArrayList<>();

    public void subscribe(PriceObserver o) {
        observers.add(o);
    }

    public void recalculate(String product, double newPrice) {
        for (PriceObserver o : observers) {
            o.onPriceChanged(product, newPrice);
        }
    }
}

// así se usa — el wiring vive afuera del sujeto
PriceEngine engine = new PriceEngine();
engine.subscribe(new CacheObserver());
engine.subscribe(new AuditObserver());
engine.recalculate("laptop", 899.99);

// Paso 1 — el contrato
interface PriceObserver {
    onPriceChanged(product: string, newPrice: number): void;
}

// Paso 3 — el sujeto refactorizado (el "aha")
class PriceEngine {
    private observers: PriceObserver[] = [];

    subscribe(o: PriceObserver): void {
        this.observers.push(o);
    }

    recalculate(product: string, newPrice: number): void {
        for (const o of this.observers) {
            o.onPriceChanged(product, newPrice);
        }
    }
}

// así se usa — el wiring vive afuera del sujeto
const engine = new PriceEngine();
engine.subscribe(new CacheObserver());
engine.subscribe(new AuditObserver());
engine.recalculate('laptop', 899.99);

# Paso 1 — el contrato
class PriceObserver(Protocol):
    def on_price_changed(self, product: str, new_price: float) -> None: ...

# Paso 3 — el sujeto refactorizado (el "aha")
class PriceEngine:
    def __init__(self): self._observers = []

    def subscribe(self, o): self._observers.append(o)

    def recalculate(self, product, new_price):
        for o in self._observers:
            o.on_price_changed(product, new_price)

# así se usa — el wiring vive afuera del sujeto
engine = PriceEngine()
engine.subscribe(CacheObserver())
engine.subscribe(AuditObserver())
engine.recalculate('laptop', 899.99)

¿Y si querés desuscribir un observador? Una línea con array_filter (o splice, o remove) y PriceEngine sigue sin cambiar. Ese es el termómetro de que el patrón está bien aplicado: agregar o quitar reaccionadores nunca toca al sujeto.

4 — Observer ya estaba en el framework

Acá enlazamos con un hilo que venimos arrastrando: "¿de qué está hecho el framework por dentro?". Observer es el primer ingrediente visible de MVC que ya usaban sin saberlo. En Laravel, cada vez que un modelo dispara un evento (created, updated, deleted) y un listener reacciona, eso es Observer: el modelo es el sujeto, los listeners son observadores suscritos.

No tenés que escribir la maquinaria de subscribe()/notify() a mano: el framework ya la trae. Pero ahora sabés qué patrón hay debajo — y por qué te deja agregar reacciones a un modelo sin tocar el modelo.

// Laravel: el modelo es el sujeto, el Observer reacciona a sus eventos
Order::observe(OrderObserver::class);

class OrderObserver
{
    public function created(Order $order): void { /* email */ }
    public function paid(Order $order): void { /* sms */ }
}

// ⚠ Cuándo NO usar Observer
$mailer->send($order); // un solo reaccionador → llamada directa

// Spring: eventos de aplicación = Observer provisto por el framework
publisher.publishEvent(new OrderPaidEvent(order));

@EventListener
void onPaid(OrderPaidEvent e) { /* email */ }

// ⚠ Cuándo NO usar Observer
mailer.send(order); // un solo reaccionador → llamada directa

// Node: EventEmitter es Observer integrado en el runtime
emitter.emit('paid', order);

emitter.on('paid', (order) => { /* email */ });

// ⚠ Cuándo NO usar Observer
mailer.send(order); // un solo reaccionador → llamada directa

# Django: las signals son Observer provisto por el framework
post_save.send(sender=Order, instance=order)

@receiver(post_save, sender=Order)
def on_saved(sender, instance, **kw): ...  # email

# ⚠ Cuándo NO usar Observer
mailer.send(order)  # un solo reaccionador → llamada directa

El costo de Observer es real: el flujo se vuelve indirecto. Disparás un evento y no ves, leyendo el sujeto, qué va a pasar — eso vive en los observadores suscritos. Por eso no lo apliques cuando hay un solo reaccionador fijo, ni cuando necesitás un orden estricto y garantizado entre reacciones (Observer no promete orden). Para uno-a-uno, la llamada directa es más honesta.

Esto cierra el Bloque B+C. Ya tenés Factory (cómo se crea), Singleton (cuántas instancias) y Observer (cómo se avisa sin acoplar). En S9 M volvemos: Observer + Composite + Strategy juntos son, literalmente, de qué está hecho el framework.

Para ir más lejos

La fuente y material para seguir:

• Refactoring.guru. Observer — el patrón con diagramas y ejemplos paso a paso.
• Gamma, Helm, Johnson, Vlissides (1994). Design Patterns. El capítulo de Observer, para la formulación original GoF.
• Laravel. Eloquent: Observers — Observer provisto por el framework, el que vas a usar en el legacy.