Blog | Lazy Loading pomocí Factory vs Accessoru

Lazy Loading pomocí Factory vs Accessoru

Tento článek vznikl jako „dlouhý komentář“ na Davidovu analýzu Dependency Injection vs Lazy Loading. Článek si nejprv přečtete a pak se vraťte.

Obvykle je potřeba lazy-loadingu důkazem, že je třída moc velká. Ale zrovna u presenterů (který sis vybral ty) to neplatí. U nich (a platí to i o controllerech v libovolném jiném frameworku) je spousta závislostí, člověk si může šáhnout na response (ikdyž třeba posílá hlavičky a redirectuje v 1 z 5 contro­llerů), na view (ikdyž chce poslat JSON), na session (ikdyž nejčastější použití: flash messages a auth použiješ tak v půlce controllerů).

Co se těch dvou variant týká. Rozdíl mezi nimi je jen v tom, že „deleguješ“ ten getter dál – tedy to té „factory“, která se tím změní na „accessor + factory“ (nebo dokonce jen na „accessor“, který bude pracovat s původní „factory“, což by na mě bylo už hodně rozdrobené – jak mám malé třídy rád – a akceptoval bych takové řešení jen pokud „nemůžu do té factory sáhnout, je od 3. strany“). Není pravda, že by jedno z těch řešení bylo hůř testovatelné, se studenty na školení používáme tu formu „factory“ a při psaní pomocí TDD s tím není problém. Argument pro ten přesun musí být někde jinde.

Moje myšlenky se ubírají tím směrem, že přemýšlím: „je zodpovědností presenteru dělat lazy loading?“ a „je zodpovědností factory+accessoru dělat lazy loading?“. Vychází mi z toho, že náležitosti okolo vytváření objektu (pokud už objekt vyžaduje speciální zacházení) patří spíš do té factory+accessoru. Výhodou je i to, že pokud je ten objekt náročný na vytvoření v presenteru W, bude to platit i o jeho vytváření v presenteru X, modelu Y a helperu Z. Kód s getterem by mi zaváděl duplikaci, která pouhým přesunutím do factory+accessoru zmizí, takže myslím, že tohle řešení je i z pohledu DRY lepší.

Hlavně je skvělé, že PHP komunita už řeší takové věci, jako je lazy loading v dependency injection. :)

Celý problém by neexistoval, kdyby existoval operátor lazy, který by fungoval jako new, jen by vytvořil objekt při prvním použití.

// misto
$obj = new Obj;
// udelam
$obj = lazy Obj; // tady jeste nejsem
$presenter->setObj($obj); // tady porad jeste nejsem

// uvnitr presenteru:
$this->obj->bang("!!!"); // a tady objekt vznikne a zavola se metoda

Na druhou stranu, když tak přemýšlím, proč nemít v jazyku lazy všechno (defaultní chování new) a zavést operátor "now Obj", který vytvoří objekt ihned?

Programování

Předejte zkušenosti i dalším a sdílejte tento článek!



Jiří Knesl
Business & IT konzultant

Jiří Knesl poprvé začal programovat v roce 1993. Od té doby, díky skvělým učitelům a později zákazníkům, měl možnost neustále růst v oboru vývoje webových aplikací a informačních systémů. v roce 2002 se přidal zájem o ekonomii a v roce 2006 o organizaci práce. Vším tím se konstantně profesně zabývá jak ve svém podnikání, tak i u zákazníků. Za posledních 5 let vydal na tato témata přes 400 článků.

Prohlédněte si moje reference

Mám zkušenosti z rozsáhlých projektů pro korporace, velké podniky, střední i malé firmy, ale i pro startupy v cloudu. Zvyšoval jsem jejich know-how, pomáhal nastavovat jejich organizační strukturu, byl lektorem a mentorem v náročných situacích. Podívejte se, jak vidí můj přínos samotní klienti.

Sledujte mé postřehy na sociálních sítích