Observer

Код на:JavaC#PythonJavaScript

Накратко: Observer позволява на един обект да известява списък от абонати, когато нещо стане, без да знае кои са те и какво правят.

Проблем

Плащането, което вика всички

Клиентът плаща поръчка #1042 за 80 €. След това трябва да тръгне разписка по имейл и SMS, складът да резервира стоката, а счетоводството да издаде фактура. Класът за плащанията прави всичко сам:

class Payments:
    def __init__(self):
        self.email = EmailService()
        self.sms = SmsService()
        self.warehouse = Warehouse()
        self.invoices = InvoiceService()

    def mark_paid(self, order):
        self.email.send_receipt(order)
        self.sms.notify_paid(order)
        self.warehouse.reserve(order)
        self.invoices.issue(order)

Всяка услуга е малък клас, който печата какво е направил:

payments = Payments()
payments.mark_paid(Order(1042, 80))

Изход

Имейл: разписка за #1042
SMS: поръчка #1042 е платена
Склад: резервирай #1042
Фактура: 80.00 € за #1042

Работи. Но маркетингът иска точки за лоялност при всяко плащане. Това е още едно поле и още един ред в mark_paid. Утре идва push известие, вдругиден статистика. Кодът, през който минава всяко плащане, се пипа заради неща, които нямат нищо общо с плащането.

По-лошото е друго. Днес SMS шлюзът не отговаря:

class SmsService:
    def notify_paid(self, order):
        raise ConnectionError("SMS шлюзът не отговаря")

payments = Payments()
try:
    payments.mark_paid(Order(1042, 80))
except ConnectionError as e:
    print(f"Плащането се провали: {e}")

Изход

Имейл: разписка за #1042
Плащането се провали: SMS шлюзът не отговаря

Парите са взети, а страницата казва на клиента, че плащането се е провалило. Складът не е резервирал нищо, фактура няма. Една услуга, която никой не смята за важна, спря цялото плащане.

Идеята

Observer: който иска да знае, се абонира

Плащанията не трябва да знаят кой се интересува от тях. Трябва да знаят само, че някой иска да научи, когато поръчка е платена.

Затова плащанията пазят списък с абонати. Всеки абонат има една и съща форма: функция, която приема поръчката. Който иска да знае, се абонира отвън. При плащане обектът обикаля списъка и вика всеки абонат с поръчката.

Това е шаблонът Observer (наблюдател). Има три роли:

• субектът е този, при когото става нещо. Тук това са плащанията. В книгите се казва още издател (publisher);
• абонатите (наблюдателите) искат да научат. Те са имейлът, SMS-ът, складът;
• известяването е обиколката на списъка: на всеки абонат се дава какво е станало, тук платената поръчка.

Нов абонат е нов код отвън. Субектът не се пипа. Абонатът може и да се отпише, и тогава повече не научава.

Виж го

Абонатите научават сами

Плащанията пазят списък от функции:

from dataclasses import dataclass


@dataclass(frozen=True)
class Order:
    id: int
    total: float


class Payments:
    def __init__(self):
        self._listeners = []

    def subscribe(self, listener):
        self._listeners.append(listener)

    def unsubscribe(self, listener):
        self._listeners.remove(listener)

    def mark_paid(self, order):
        for listener in self._listeners:
            listener(order)

Всеки абонат е обикновена функция, която приема поръчката:

def email(order):
    print(f"Имейл: разписка за #{order.id}")


def sms(order):
    print(f"SMS: поръчка #{order.id} е платена")


def warehouse(order):
    print(f"Склад: резервирай #{order.id}")


def loyalty(order):
    print(f"Точки: +{int(order.total)} за #{order.id}")

Три абоната, плащане. После идват точките за лоялност, а клиентът изключва SMS-ите:

payments = Payments()
payments.subscribe(email)
payments.subscribe(sms)
payments.subscribe(warehouse)
payments.mark_paid(Order(1042, 80))

payments.subscribe(loyalty)
payments.unsubscribe(sms)
payments.mark_paid(Order(1043, 25))

Изход

Имейл: разписка за #1042
SMS: поръчка #1042 е платена
Склад: резервирай #1042
Имейл: разписка за #1043
Склад: резервирай #1043
Точки: +25 за #1043

payments = Payments()
payments.subscribe(email)
payments.subscribe(sms)
payments.subscribe(warehouse)
payments.mark_paid(Order(1042, 80))

payments.subscribe(loyalty)
payments.unsubscribe(sms)
payments.mark_paid(Order(1043, 25))

Стъпка по стъпка, с думи

1. Payments започва с празен списък _listeners.
2. email се абонира: влиза в списъка _listeners.
3. sms и warehouse също. Payments не знае кои са, само че приемат поръчка.
4. Поръчка #1042 е платена. Известието тръгва към всеки абонат, по реда на абонирането.
5. Един след друг, в същото извикване: разписка, SMS, резервация. Всеки абонат прави своето.
6. Идват точките за лоялност: loyalty се абонира отвън. В Payments не се пипа нито ред.
7. Клиентът изключва SMS-ите: sms се отписва и излиза от списъка.
8. Поръчка #1043: известието стига до email, warehouse и loyalty. sms вече не е в списъка и не научава нищо.

Payments е един и същ код от началото до края. Точките се появиха, без да се пипне ред в него, а SMS-ът спря, без плащанията да разберат.

По-точно, за любопитните

• Абонат може да е всичко, което се вика: функция, ламбда, метод на обект. payments.subscribe(mailer.send_receipt) абонира метода на един конкретен обект. Два пъти написан, mailer.send_receipt дава равни стойности, затова unsubscribe(mailer.send_receipt) го намира и маха. Плащането след това не печата нищо:

payments = Payments()
mailer = EmailService()
payments.subscribe(mailer.send_receipt)
payments.unsubscribe(mailer.send_receipt)
payments.mark_paid(Order(1042, 80))

• Вграден Observer в Python няма. Списък с функции е обичайният начин. Името _listeners с долна черта казва „отвън не пипай, ползвай subscribe“.
• Абонатите се викат един след друг, в същото извикване на mark_paid. Бавен SMS шлюз бави и плащането. Големите магазини пращат събитието в опашка (message broker), а услугите го взимат оттам, когато са готови.

Виж го

Един абонат пада, другите не трябва

Observer махна връзката между плащането и SMS-а, но не и грешката. SMS абонатът хвърля:

def sms(order):
    raise ConnectionError("SMS шлюзът не отговаря")

payments = Payments()
payments.subscribe(email)
payments.subscribe(sms)
payments.subscribe(warehouse)
try:
    payments.mark_paid(Order(1042, 80))
except ConnectionError as e:
    print(f"Плащането се провали: {e}")

Изход

Имейл: разписка за #1042
Плащането се провали: SMS шлюзът не отговаря

Абонатите се викат в цикъл, и изключението от SMS-а излиза от цикъла. Складът пак не резервира, а грешката пак стига до плащането. Субектът трябва да пази всяко извикване поотделно:

def mark_paid(self, order):
    for listener in self._listeners:
        try:
            listener(order)
        except Exception as e:
            print(f"Абонат се провали: {e}")

Със същата програма:

payments = Payments()
payments.subscribe(email)
payments.subscribe(sms)
payments.subscribe(warehouse)
try:
    payments.mark_paid(Order(1042, 80))
except ConnectionError as e:
    print(f"Плащането се провали: {e}")

Изход

Имейл: разписка за #1042
Абонат се провали: SMS шлюзът не отговаря
Склад: резервирай #1042

Плащането мина, складът резервира, а провалът е записан. В истински магазин този ред отива в лога, а SMS-ът се пробва пак по-късно.

Пробвай

Предвиди изхода

Абонатите са от картата „Абонатите научават сами“. Какво печата програмата?

payments = Payments()
payments.subscribe(email)
payments.subscribe(warehouse)
payments.subscribe(email)
payments.mark_paid(Order(7, 10))

payments.unsubscribe(warehouse)
payments.mark_paid(Order(8, 10))

Отговор

Имейл: разписка за #7
Склад: резервирай #7
Имейл: разписка за #8

Имейл: разписка за #7
Имейл: разписка за #7
Склад: резервирай #7
Имейл: разписка за #8
Имейл: разписка за #8

Имейл: разписка за #7
Склад: резервирай #7
Имейл: разписка за #7
Имейл: разписка за #8
Имейл: разписка за #8

Провери

Пробвай

Намери грешката

Купонът за добре дошъл се дава само на първата платена поръчка. Затова абонатът за купона се отписва сам, щом го изпрати:

def welcome_coupon(order):
    print(f"Купон за добре дошъл: #{order.id}")
    payments.unsubscribe(welcome_coupon)

payments = Payments()
payments.subscribe(welcome_coupon)
payments.subscribe(email)
payments.subscribe(warehouse)
payments.mark_paid(Order(1042, 80))
payments.mark_paid(Order(1043, 25))

Изход

Купон за добре дошъл: #1042
Склад: резервирай #1042
Имейл: разписка за #1043
Склад: резервирай #1043

Поръчка #1042 не получи разписка по имейл. На кой ред в Payments е грешката?

Избери реда с грешката.

1class Payments:2 def __init__(self):3 self._listeners = []45 def subscribe(self, listener):6 self._listeners.append(listener)78 def unsubscribe(self, listener):9 self._listeners.remove(listener)1011 def mark_paid(self, order):12 for listener in self._listeners:13 listener(order)

Провери

По-точно, за любопитните

В C# и JavaScript тази грешка я няма, ако ползваш вградените средства. Делегатът на събитието в C# не се променя: -= прави нов списък, а текущото известяване продължава по стария. emit на EventEmitter копира списъка, преди да вика слушателите. Собствен списък трябва да се пази ръчно.

Идеята

Кога не ти трябва

Observer има цена. Кодът не казва кой ще реагира на плащането: за да разбереш, търсиш всички места, които абонират. Абонат, когото никой не отписва, живее в паметта, докато живее субектът. Не си струва, когато:

• реакцията е една и винаги същата. Едно извикване е по-ясно от списък с един абонат;
• стъпката е част от самото действие. Ако без фактура плащането е невалидно, фактурата не е абонат: вика се направо, а провалът ѝ спира плащането;
• редът има значение и стъпките зависят една от друга (първо склад, после плащане, после фактура). Това е последователност, не събитие. Как се събира на едно място, е в урока „Adapter и Facade“.

Струва си, когато реакциите са много, растат и субектът не трябва да зависи от тях: известия, точки, статистика, логове.

Упражнение

Фактурата като абонат

Реши задачата в редактора си.

Фактура. Направи фактурата абонат: функция invoice, която печата сумата с две цифри след точката. Абонирай имейла, склада и фактурата и плати поръчка #1042 за 80 €. Плащанията не се пипат.

Изход

Имейл: разписка за #1042
Склад: резервирай #1042
Фактура: 80.00 € за #1042

Още задачи

• Подарък над 100 €. Абонат, който печата „Подарък: безплатна доставка за #…“ само за поръчки над 100 €. Плати една за 80 € и една за 120 €.
• Купонът, който се отписва сам. Напиши абоната за купона от „Намери грешката“ и плащания, които го понасят. Обикаляй копие на списъка.
• Две събития. Добави и връщане на пари. Речник име на събитие → списък с абонати. Имейлът слуша и двете, складът само плащането.

Тест

Провери се

1. Магазинът добавя точки за лоялност при всяко плащане. Какво пишеш при Observer?

Нов абонат, който се абонира отвън; плащанията не се пипатНов клас, който наследява плащаниятаНов ред в метода, който маркира поръчката като платена

2. Абонатът за SMS хвърля изключение, а известяването не е защитено. Какво става?

Програмата пропуска грешкатаАбонатите след него не се викат, а грешката стига до този, който е маркирал поръчката като платенаСамо SMS-ът не тръгва, другите абонати си работят

3. Един и същ абонат е абониран два пъти. Колко пъти научава за едно плащане?

Два пътиВеднъж: списъкът пази всеки абонат по веднъжНито веднъж: второто абониране отменя първото

4. Фактурата трябва да е издадена, иначе плащането не се брои. Подходящ ли е тук Observer?

Да, всичко след плащането е абонатНе: стъпка, без която плащането е невалидно, се вика направо и грешката ѝ спира плащанетоДа, но само ако абонатът е първи в списъка

Провери

Започни урока отначало

Свързани уроци

• Нужно отпреди: Ламбди · dataclass, match и шаблони · Шаблони за дизайн · Strategy
• Продължава в: Магазинът: кой шаблон къде · Събития и опашки · Transactional outbox
• Задачи по темата: Шаблони за дизайн