Към съдържанието
wannacode

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

Накратко: Упражнение по шаблони за дизайн: магазин с плащане, известия и съхранение в един метод се подрежда със Strategy, Observer и Repository, а изходът остава същият.

Проблем

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

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

class Shop
{
    private readonly List<string> orders = new();


    public void PlaceOrder(string id, string customer, decimal amount, string method)
    {
        decimal total;
        if (method == "карта")
        {
            total = amount;
        }
        else if (method == "наложен платеж")
        {
            total = amount + 2.50m;
        }
        else
        {
            throw new ArgumentException("Непознат начин на плащане: " + method);
        }
        orders.Add($"{id};{customer};{total}");
        Console.WriteLine($"Имейл до {customer}: поръчка {id}, {total:F2} €");
        Console.WriteLine("Склад: подготви " + id);
    }


    public int Count => orders.Count;
}
var shop = new Shop();
shop.PlaceOrder("A-1", "ana@example.com", 80, "карта");
shop.PlaceOrder("A-2", "ivan@example.com", 45, "наложен платеж");
Console.WriteLine("Поръчки: " + 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 по текста на начина на плащане, която расте с всеки нов начин. Кой шаблон я подрежда?
2. След поръчката методът сам праща имейл и пише на склада. Утре идва и SMS. Кой шаблон?
3. Поръчките се пазят в списък вътре в магазина. Утре трябва база, а за теста искаш нещо в паметта. Кой шаблон?
4. Поръчката има три полета. Трябва ли ѝ Builder?

Виж го

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

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

Начините на плащане са стратегии. Всеки е една функция, затова таблицата е Dictionary<string, Func<decimal, decimal>>, без интерфейс (виж урока Strategy):Поръчката е record. Съхранението е зад интерфейс, а за паметта има една имплементация:
record Order(string Id, string Customer, decimal Total);


interface IOrderRepository
{
    void Save(Order order);
    int Count { get; }
}


class InMemoryOrders : IOrderRepository
{
    private readonly List<Order> orders = new();


    public void Save(Order order) => orders.Add(order);


    public int Count => orders.Count;
}
Магазинът получава хранилището и таблицата с начините отвън. Абонатите са събитието Placed, което той вдига, когато поръчката е направена:
class Shop
{
    private readonly IOrderRepository orders;
    private readonly Dictionary<string, Func<decimal, decimal>> methods;


    public event Action<Order>? Placed;


    public Shop(IOrderRepository orders, Dictionary<string, Func<decimal, decimal>> methods)
    {
        this.orders = orders;
        this.methods = methods;
    }


    public void PlaceOrder(string id, string customer, decimal amount, string method)
    {
        if (!methods.TryGetValue(method, out var payment))
        {
            throw new ArgumentException("Непознат начин на плащане: " + method);
        }
        var order = new Order(id, customer, payment(amount));
        orders.Save(order);
        Placed?.Invoke(order);
    }


    public int Count => orders.Count;
}

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

var methods = new Dictionary<string, Func<decimal, decimal>>
{
    ["карта"] = amount => amount,
    ["наложен платеж"] = amount => amount + 2.50m,
};
var shop = new Shop(new InMemoryOrders(), methods);
shop.Placed += o => Console.WriteLine($"Имейл до {o.Customer}: поръчка {o.Id}, {o.Total:F2} €");
shop.Placed += o => Console.WriteLine("Склад: подготви " + o.Id);


shop.PlaceOrder("A-1", "ana@example.com", 80, "карта");
shop.PlaceOrder("A-2", "ivan@example.com", 45, "наложен платеж");
Console.WriteLine("Поръчки: " + shop.Count);
Изход
Имейл до ana@example.com: поръчка A-1, 80.00 €
Склад: подготви A-1
Имейл до ivan@example.com: поръчка A-2, 47.50 €
Склад: подготви A-2
Поръчки: 2

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

Виж го

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

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

var methods = new Dictionary<string, Func<decimal, decimal>>
{
    ["карта"] = amount => amount,
    ["наложен платеж"] = amount => amount + 2.50m,
    ["банков превод"] = amount => amount * 0.98m,
};
var shop = new Shop(new InMemoryOrders(), methods);
shop.Placed += o => Console.WriteLine("SMS до " + o.Customer + ": " + o.Id);


shop.PlaceOrder("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. Какво пипаш в класа на магазина?

Създаден от Иво Гергов като част от кампанията на Evo Tech за достъпно обучение по програмиране ·