Návrhové vzory v praxi. Kdy pomáhají a kdy komplikují kód

Návrhový vzor není důkaz seniority. Je to pojmenování řešení, které se opakovaně osvědčilo u určitého typu problému. Pokud takový problém nemáme, vzor přidá soubory, rozhraní a pojmy, ale nesníží skutečné riziko.

Při návrhu firemního softwaru proto nezačínáme otázkou, který vzor lze použít. Nejprve hledáme část, která se bude měnit, vlastníka změny a okolí, které má zůstat stabilní. Odpověď může ukázat na Strategy, Adapter, Factory nebo obyčejnou funkci.

1. 01

   Jedno stabilní pravidlo

   Ponechte přímou funkci.

2. 02

   Měnící se algoritmus

   Zvažte Strategy.

3. 03

   Cizí rozhraní

   Oddělte ho Adapterem.

4. 04

   Více způsobů vytvoření

   Factory může skrýt sestavení.

Jednoduchý kód není primitivní

Představme si výpočet dopravy. První verze podporuje osobní odběr a jednoho dopravce. Dvě podmínky v jedné funkci jsou čitelnější než strom tříd. Vstup, pravidlo a výsledek vidíme pohromadě.

Tlak přichází, když se pravidla začnou měnit nezávisle. Jeden dopravce počítá cenu podle hmotnosti, jiný podle regionu. Smluvní zákazníci mají vlastní podmínky. Jedna funkce pak získá několik nesouvisejících důvodů ke změně a úprava jedné cesty může poškodit ostatní.

Dobrý návrh nereaguje na počet řádků. Reaguje na počet nezávislých důvodů ke změně. Padesát stabilních řádků může být jednodušších než deset řádků upravovaných každý týden z různých obchodních důvodů.

Strategy odděluje proměnlivé pravidlo

Strategy se hodí, když úkol zůstává stejný, ale algoritmus lze zaměnit. Stále počítáme cenu dopravy. Výpočet se mění podle dopravce nebo smlouvy.

type DeliveryQuote = (order: Order) => Money;

const quoteDelivery = (order: Order, quote: DeliveryQuote): Money =>
  quote(order);

Strategy nemusí být třída. V TypeScriptu často stačí typ a několik čistých funkcí. Objednávka nezná ceník dopravce a kalkulátor nemusí vědět, odkud objednávka přišla. Nové pravidlo přidáme bez zásahu do existujících algoritmů.

Vzor není vhodný, pokud máme jediný stabilní výpočet nebo varianty sdílejí mnoho měnitelného stavu. Malé strategie pak jen přesunou podmínky mezi soubory. Nejdřív musíme najít skutečnou hranici.

Adapter chrání doménu před cizím rozhraním

ERP, platební brána nebo dopravce přinášejí vlastní názvy, datové typy a chybové stavy. Když je pustíme do jádra aplikace, doména začne mluvit jazykem dodavatele. Další verze API pak zasáhne objednávky, faktury i uživatelské rozhraní.

Adapter překládá cizí model do malého kontraktu vlastněného naším systémem. Doména může žádat reserveStock, i když jedno ERP pracuje se skladovými pohyby a jiné s rezervacemi položek. Rozdíl zůstane na integrační hranici.

Hranice pomáhá při testování. Doménový test nepotřebuje síť ani sandbox dodavatele. Ověří chování proti vlastnímu kontraktu. Samostatný integrační test prokáže správný překlad požadavků, odpovědí a chyb.

Adapter není zásuvka na libovolný nepořádek. Pokud pouze přejmenuje každé pole a rozhraní dodavatele je stabilní, může mít malou hodnotu. Jeho přínos roste se sémantickou vzdáleností mezi cizím modelem a naší doménou.

Factory skrývá sestavení

Factory řeší vytvoření objektu nebo pracovního toku, když sestavení závisí na typu vstupu. Procesor PDF faktury může potřebovat OCR, validátor a účetní mapování. Smlouva použije jiný extraktor a jiné kontroly.

Volající nemusí znát pořadí všech závislostí. Požádá o procesor pro typ dokumentu. Factory jej sestaví a vrátí přes společný kontrakt.

Obchodní rozhodnutí nesmí zmizet ve velké Factory s desítkami větví. Výběr technických částí patří k vytvoření. Rozhodnutí, zda lze fakturu automaticky zaúčtovat, je doménové pravidlo. Musí zůstat viditelné a samostatně testovatelné.

1. 01

   Předtím

   Jedna služba zná ceny, dodavatele i formáty dokumentů.

2. 02

   Po rozdělení

   Doména volá malé rozhraní a detail změny zůstává za hranicí.

Vzor musí omezit dosah další změny

Při review pomáhají tři otázky. Umíme pojmenovat očekávanou změnu? Udrží ji vzor za jednou hranicí? Je výsledek čitelnější pro člověka, který nezná historii rozhodnutí?

Pokud ne, abstrakce patrně přišla brzy. Kód nemusí pokrývat každou představitelnou budoucnost. Má zvládat změny vyplývající z produktu, smluv a provozu.

Vzory mohou spolupracovat. Adapter poskytne doméně vlastní rozhraní, Strategy drží proměnlivé pravidlo a Factory sestaví závislosti. Kombinace dává smysl pouze tehdy, když každý prvek chrání jinou hranici. Pokud tři názvy popisují jednu podmínku, návrh je příliš velký.

Na co se má ptát zadavatel

Majitel firmy nemusí kontrolovat diagram tříd. Potřebuje vědět, zda nový způsob platby nebo výměna ERP zasáhne celý systém. Technický vedoucí potřebuje vidět umístění pravidla, jeho kontrakt a test, který chrání chování.

Při vývoji softwaru na míru spojujeme technické hranice s očekávanou změnou podnikání. Další článek přenáší stejné uvažování na volbu mezi modulárním monolitem a mikroslužbami. K vlivu AI na vývoj se vrací text o lidské kontrole při vývoji s AI.

Nejlepší vzor při běžné práci téměř nevnímáme. Příští změna má zřejmé místo, test má jasný účel a zbytek systému o změně nemusí vědět. Před zavedením abstrakce proto ještě ověřme, zda přímá funkce neudrží stejný prostor změny srozumitelněji. Známý název není přínos. Přínosem je menší riziko při další úpravě.

Rozhodnutí ověřujme na skutečné změně

Před zavedením vzoru lze levně napsat druhou variantu přímo a porovnat oba návrhy. Sledujeme počet míst, která musí změna zasáhnout, srozumitelnost testů a množství znalostí nutných pro bezpečnou úpravu. Pokud přímá verze zůstává přehledná, abstrakce zatím nemá práci.

Rozhodnutí stručně zapíšeme. Stačí problém, očekávaný druh změny, zvolená hranice a důvod odmítnutí jednodušší varianty. Nový člen týmu tak nevidí jen strukturu, ale také předpoklad, ze kterého vznikla. Když předpoklad přestane platit, může vzor bez obav odstranit.

Užitečný je také test změny. Zkusme přidat dalšího dopravce nebo vyměnit poskytovatele v malé větvi. Pokud úprava zůstane za zamýšleným rozhraním a existující testy se nemusí přepisovat, hranice funguje. Pokud nový případ vyžaduje zásah do Factory, každé Strategy i doménového modelu, názvy pouze zakryly silné propojení.

Vzory mají snižovat poznávací zátěž po celou dobu života systému. Počet tříd ani čistota diagramu nejsou cílem. Měřítkem je, zda člověk při další změně rychle najde správné místo, rozumí následkům a dostane přesnou zpětnou vazbu z testu.