Магазинът: кой шаблон къде в Python

Проблем

Магазин в един метод

Ето малък онлайн магазин. Методът за поръчка смята сумата по начина на плащане, пази поръчката, праща имейл и пише на склада:

class Shop:
    def __init__(self):
        self.orders = []

    def place_order(self, id, customer, amount, method):
        if method == "карта":
            total = amount
        elif method == "наложен платеж":
            total = amount + 2.50
        else:
            raise ValueError("Непознат начин на плащане: " + method)
        self.orders.append(f"{id};{customer};{total}")
        print(f"Имейл до {customer}: поръчка {id}, {total:.2f} €")
        print("Склад: подготви " + id)

    def count(self):
        return len(self.orders)

shop = Shop()
shop.place_order("A-1", "ana@example.com", 80, "карта")
shop.place_order("A-2", "ivan@example.com", 45, "наложен платеж")
print("Поръчки: " + str(shop.count()))

Имейл до ana@example.com: поръчка A-1, 80.00 €
Склад: подготви A-1
Имейл до ivan@example.com: поръчка A-2, 47.50 €
Склад: подготви A-2
Поръчки: 2

Работи. Но през следващия месец идват три промени: банков превод с 2% отстъпка, SMS след всяка поръчка и база вместо списък. И трите са в един и същ метод. Всяка от тях го пипа, а тест за сумата без да тръгне имейл не може да се напише.

В този урок няма нов шаблон. Той е упражнение: ти разпознаваш кой от шаблоните в модула подрежда всяко от тези неща и кой тук не трябва.

Идеята

Симптомът казва шаблона

Шаблон не се избира от списък. Избира се от това, което боли:

Симптом в кода	Шаблон
верига от `if` по вид, която расте с всеки нов вариант	Strategy, или Factory, ако веригата избира какво да създаде
след едно събитие кодът сам вика всеки, който трябва да разбере	Observer
съхранението е вътре в правилата и тест без база не става	Repository и подаване отвън
`switch` по текста на състоянието във всеки метод	State
конструктор с много незадължителни параметри	Builder
чужда библиотека с неудобен интерфейс	Adapter
пет подсистеми, които трябва да се викат в точен ред	Facade
поведение „около“ метод: логване, кеш, добавки към цената	Decorator
отмяна на последното действие	Command
дърво, в което част и цяло се ползват еднакво	Composite

Ако не намираш симптома, най-вероятно шаблон не ти трябва.

Пробвай

Разпознай

Погледни отново магазина от първата карта.

1. Веригата от if по текста на начина на плащане, която расте с всеки нов начин. Кой шаблон я подрежда?Strategy: всеки начин е отделно правило, а изборът е таблицаSingletonBuilder

2. След поръчката методът сам праща имейл и пише на склада. Утре идва и SMS. Кой шаблон?CommandObserver: магазинът казва „поръчката е направена“, а кой слуша, не го засягаDecorator

3. Поръчките се пазят в списък вътре в магазина. Утре трябва база, а за теста искаш нещо в паметта. Кой шаблон?Repository: съхранението зад интерфейс, подадено отвънAdapterComposite

4. Поръчката има три полета. Трябва ли ѝ Builder?Да, всеки обект с полета иска BuilderДа, иначе не може да е неизменнаНе: три задължителни полета са един конструктор (или record)

Виж го

Едно възможно подреждане

Три от симптомите са в магазина, затова и шаблоните са три.

Начините на плащане са стратегии: функции в речник. Поръчката е неизменен dataclass с три полета. Съхранението е клас с два метода, save и count:

from dataclasses import dataclass


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


class InMemoryOrders:
    def __init__(self):
        self._orders = []

    def save(self, order):
        self._orders.append(order)

    def count(self):
        return len(self._orders)

Магазинът получава хранилището и таблицата с начините отвън. Пази списък с абонати и казва на всеки, когато поръчката е направена:

class Shop:
    def __init__(self, orders, methods):
        self.orders = orders
        self.methods = methods
        self.listeners = []

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

    def place_order(self, id, customer, amount, method):
        payment = self.methods.get(method)
        if payment is None:
            raise ValueError("Непознат начин на плащане: " + method)
        order = Order(id, customer, payment(amount))
        self.orders.save(order)
        for listener in self.listeners:
            listener(order)

    def count(self):
        return self.orders.count()

Какво хранилище, кои начини и кои абонати, се решава на едно място, там, където магазинът се сглобява:

methods = {
    "карта": lambda amount: amount,
    "наложен платеж": lambda amount: amount + 2.50,
}
shop = Shop(InMemoryOrders(), methods)
shop.subscribe(lambda o: print(f"Имейл до {o.customer}: поръчка {o.id}, {o.total:.2f} €"))
shop.subscribe(lambda o: print("Склад: подготви " + o.id))

shop.place_order("A-1", "ana@example.com", 80, "карта")
shop.place_order("A-2", "ivan@example.com", 45, "наложен платеж")
print("Поръчки: " + str(shop.count()))

Имейл до ana@example.com: поръчка A-1, 80.00 €
Склад: подготви A-1
Имейл до ivan@example.com: поръчка A-2, 47.50 €
Склад: подготви A-2
Поръчки: 2

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

Виж го

Трите промени сега

Банковият превод е нов ред в таблицата. SMS е нов абонат. Базата ще е нова имплементация на хранилището (методи save и count). В класа на магазина не се пипа нито ред:

methods = {
    "карта": lambda amount: amount,
    "наложен платеж": lambda amount: amount + 2.50,
    "банков превод": lambda amount: amount * 0.98,
}
shop = Shop(InMemoryOrders(), methods)
shop.subscribe(lambda o: print("SMS до " + o.customer + ": " + o.id))

shop.place_order("A-3", "ana@example.com", 100, "банков превод")

SMS до ana@example.com: A-3

Сега и тест за сумата е лесен: подаваш хранилище в паметта и не абонираш имейла.

Идеята

Къде да спреш

В модула има повече от десет шаблона, а тук са ползвани три. Останалите не са забравени, просто тук не помагат:

Builder: поръчката има три задължителни полета. Конструкторът (record) стига;
Singleton: нищо не трябва да е единствено. Хранилището се подава отвън, затова тестът и магазинът могат да имат свое;
Factory: начините на плащане са функции в таблица, а таблицата вече е мястото, където се избира;
State: поръчката още няма състояния. Когато дойдат „платена“ и „изпратена“, ще дойде и той (виж задачите).

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

Упражнение

Подреди магазина нататък

Реши задачите в редактора си, като тръгнеш от подредения магазин. След всяка стъпка пусни програмата от картата „Едно възможно подреждане“: изходът ѝ трябва да остане същият.

1. Състоянията на поръчката. Поръчката става нова → платена → изпратена и може да е отказана, но не и след като е изпратена. Направи го с State (или с изброим тип и таблица на преходите, ако състоянията нямат свое поведение) и покажи грешката при отказ на изпратена поръчка.

2. Отстъпка над 100 €. Поръчка над 100 € получава 5% отстъпка, каквото и да е плащането. Помисли къде е мястото ѝ: в стратегия, в Decorator около стратегията или в магазина. Защо?

3. Хранилище, което помни. Направи второ хранилище, което записва поръчките във файл (по една на ред), и го подай на магазина вместо това в паметта. Класът на магазина не се пипа.

4. Чужд куриер. Складът вече се вика през библиотека на куриер с метод createShipment(reference, weightGrams). Абонатът за склада става Adapter към нея.

Тест

Провери се

1. Подреди кода с шаблони. Как разбираш, че не си счупил нищо?Има повече класовеКодът изглежда по-чистСъщият вход дава същия изход, проверено с пускане преди и след

2. Кое НЕ е добра причина да добавиш шаблон?Искаш да тестваш правилото без базаШаблонът е модерен и ще потрябва някой денВариантите растат всеки месец

3. След подреждането добавяш банков превод и SMS. Какво пипаш в класа на магазина?Веригата от if и метода за известияКонструктораНищо: новият начин е ред в таблицата, а SMS е нов абонат

Магазинът: кой шаблон къде

Бисквитки