Návrhové vzory v praxi. Kedy pomáhajú a kedy komplikujú kód

Návrhový vzor pomáha, keď rieši problém, ktorý v kóde naozaj máte. Inak pridá súbory a rozhrania, ktoré musí ďalší vývojár pochopiť skôr, než začne pracovať. Samotný názov Strategy alebo Factory mu systém nevysvetlí.

Pri návrhu firemného softvéru sa preto nepýtam, ktorý vzor by sa dal použiť. Pýtam sa, ktorá časť sa bude meniť. Potom, kto tú zmenu objedná a čo musí popri nej zostať stabilné, lebo na druhú otázku nemá programátor odpoveď sám. Až odtiaľ vidno, či dáva zmysel Strategy alebo Adapter, prípadne Factory. Niekedy je odpoveďou obyčajná funkcia.

1. 01

   Jedno stabilné pravidlo

   Ponechajte priamu funkciu.

2. 02

   Meniteľný algoritmus

   Zvážte Strategy.

3. 03

   Cudzie rozhranie

   Izolujte ho Adapterom.

4. 04

   Viac spôsobov vytvorenia

   Factory môže skryť zostavenie.

Jednoduchý kód nie je primitívny kód

Predstavte si výpočet ceny dopravy. Prvá verzia podporuje osobný odber a jedného kuriéra. Dve podmienky v jednej funkcii sú v tejto chvíli čitateľnejšie než strom tried, pretože vstup, pravidlo a to, čo z nich vypadne, vidí človek naraz na jednej obrazovke, bez skákania medzi súbormi.

Problém vznikne až vtedy, keď sa pravidlá začnú meniť nezávisle od seba. Jeden kuriér počíta podľa hmotnosti. Druhý podľa regiónu. Firemní zákazníci majú k tomu vlastnú zmluvu. Tá istá funkcia zrazu pozná priveľa dôvodov na zmenu a úprava pre jedného dopravcu dokáže ticho pokaziť cenu ostatným, lebo nikto už nevie, ktorá vetva komu patrí.

Dobrý návrh nereaguje na počet riadkov. Reaguje na počet nezávislých dôvodov, pre ktoré sa kód mení. Stabilná funkcia môže byť jednoduchšia než kratší kód, do ktorého opakovane zasahujú rôzne tímy.

Strategy oddeľuje meniace sa pravidlo

Strategy sa hodí vtedy, keď máme jednu úlohu a viac zameniteľných spôsobov, ako ju vykonať. Výpočet dopravy zostáva tou istou úlohou aj potom, ako pribudne ďalší dopravca, pretože sa mení iba algoritmus a nie otázka, na ktorú odpovedá.

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

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

Strategy nemusí byť trieda. V TypeScripte často stačí typ a niekoľko čistých funkcií. Dôležité je, že objednávka nepozná cenník kuriéra. A cenník nemusí vedieť, odkiaľ objednávka prišla. Nové pravidlo pridáte ako novú funkciu a existujúcich algoritmov sa nedotknete, čo obmedzí dosah ďalšej úpravy.

Vzor sa neoplatí, ak existuje jeden stabilný výpočet. Ani vtedy, keď varianty zdieľajú väčšinu komplikovaného stavu, lebo malé stratégie potom iba presúvajú tie isté podmienky medzi súbormi a človek, ktorý ich číta, musí otvoriť všetky.

Najprv treba pomenovať skutočnú hranicu.

Adapter chráni doménu pred cudzím rozhraním

Integrácia ERP alebo platobnej brány prináša cudzie názvy a dátové typy, ktoré u Vás nikto nevymyslel. Prepravca k tomu pridá vlastné chybové stavy. Ak ich pustíme priamo do jadra aplikácie, doména začne hovoriť jazykom dodávateľa. Zmena API sa potom prejaví na objednávkach, chvíľu nato vo fakturácii, a nakoniec na obrazovkách, ktoré o žiadnom dodávateľovi nikdy nemali vedieť, hoci ich zákazník vidí každý deň.

Adapter preloží cudzie rozhranie do malého kontraktu, ktorému rozumie náš systém. Doména môže žiadať reserveStock aj vtedy, keď jedno ERP pracuje so skladovými pohybmi a druhé s rezerváciami položiek, pričom rozdiel medzi nimi zostane v integračnej vrstve.

Takáto hranica pomáha aj pri testovaní. Doménový test nepotrebuje sieť ani sandbox dodávateľa, lebo overuje správanie proti kontraktu, ktorý sme si napísali sami. Samostatný integračný test potom dokazuje, že adapter prekladá požiadavku aj odpoveď správne, pričom prípadný prístup do siete zostáva v integračných testoch.

Adapter nie je miesto, kam schováme ľubovoľný neporiadok. Ak iba premenúva každé pole jedna k jednej a dodávateľské API je roky stabilné, môže byť zbytočný. Jeho hodnota rastie s odstupom medzi cudzím modelom a našou doménou, teda presne vtedy, keď dodávateľ pomenúva veci inak, než ako o nich hovorí Váš obchod.

Factory ukrýva zostavenie, nie rozhodovanie firmy

Factory rieši vytváranie objektu alebo pracovného toku vtedy, keď zostavenie závisí od typu vstupu. Spracovanie PDF faktúry si vyžiada OCR, potom validátor fakturačných údajov, potom účtovný mapper, kým zmluva prejde iným extraktorom a inou sadou kontrol, hoci pre zvyšok systému ide stále o ten istý dokument.

Volajúci nemá dôvod poznať poradie závislostí. Požiada o procesor pre konkrétny typ dokumentu, dostane ho cez spoločný kontrakt a o tom, z čoho je zostavený, sa nedozvie nič.

Obchodné rozhodnutie však nemá zmiznúť v obrovskej Factory s desiatkami vetiev. Výber komponentov podľa typu dokumentu patrí k vytvoreniu. Rozhodnutie, či sa faktúra smie automaticky zaúčtovať, je doménové pravidlo. To musí zostať viditeľné a musí mať vlastný test, lebo v deň, keď sa niekto spýta, prečo systém zaúčtoval faktúru sám, je to jediná odpoveď, ktorú viete doložiť.

1. 01

   Predtým

   Jedna služba pozná ceny, dodávateľov aj formáty dokumentov.

2. 02

   Po rozdelení

   Doména volá malé rozhranie a detail zmeny zostáva za hranicou.

Vzor musí zmenšiť dosah ďalšej úpravy

Pri review si kladieme tri otázky. Vieme pomenovať konkrétnu očakávanú zmenu? Zostane po zavedení vzoru za jednou hranicou, alebo sa tá istá podmienka o pol roka rozsype do troch súborov pod tromi novými názvami, ktoré si nikto nezapamätá? A je výsledok čitateľnejší pre človeka, ktorý pri tom rozhodnutí nebol?

Ak je odpoveď nie, abstrakcia prišla priskoro. Kód nemusí byť pripravený na každú predstaviteľnú budúcnosť. Má byť pripravený na zmeny, ktoré vyplývajú z produktu, zo zmlúv a z toho, ako firma reálne funguje v deň, keď niekto podpíše zmluvu s novým dopravcom.

Vzory sa dajú skladať.

Adapter dodá doméne jednotné rozhranie. Strategy vyberie pravidlo, Factory zostaví závislosti, ktoré k nemu patria. Kombinácia dáva zmysel iba vtedy, keď každá časť chráni inú hranicu, teda keď viete pri každej z nich ukázať konkrétnu zmenu, ktorá sa o ňu zastaví. Ak tri názvy opisujú jednu podmienku, návrh je priveľký.

Ako o tom hovoriť s dodávateľom

Majiteľ firmy nepotrebuje kontrolovať diagram tried. Potrebuje vedieť, či nový spôsob platby znamená zásah do celého systému, alebo či sa všetko zmestí do jedného súboru. CTO potrebuje vidieť, kde pravidlo žije, aký má kontrakt a ktorý test spadne v deň, keď ho niekto zmení bez toho, aby vedel, prečo tam vzniklo.

Pri návrhu softvéru na mieru preto spájame technickú hranicu s reálnou zmenou v podnikaní. Vždy s konkrétnou. Ďalší diel ukazuje ten istý princíp vo väčšom meradle pri rozhodovaní medzi modulárnym monolitom a mikroslužbami. Ak Vás zaujíma, čo robí AI so samotnou vývojárskou prácou, pozrite si náš článok o človeku v slučke pri AI vývoji, kde je rovnaká otázka položená o generovanom kóde.

Najlepší vzor je ten, ktorý po zavedení prestanete vnímať. Ďalšia zmena má jasné miesto. Test má jasný dôvod. A zvyšok systému sa o nej nikdy nedozvie, čím sa znižuje riziko vedľajšieho zásahu.

Pred zavedením abstrakcie sa oplatí urobiť malý experiment. Skúste druhý variant napísať priamo a porovnajte dosah zmien v teste aj v produkčnom kóde. Ak priama verzia zostane čitateľná, je priskoro pridávať nový pojem. Ak sa rovnaké rozhodovanie opakuje na viacerých miestach, hranica už má merateľný dôvod existovať a vzor si miesto zaslúži výsledkom, nie tým, že ho poznáte z knihy.

Rozhodnutie stručne zapíšte. Stačí problém, očakávaná zmena a dôvod, prečo zvolená hranica pomôže pri ďalšej úprave, aby vedel ďalší človek vzor odstrániť v deň, keď predpoklad prestane platiť.