Dependency Injection Container: TODO

Nechtěl jsem zakládat flame, ale protože je to v diskuzi a né feature request…

V presenterech je potřeba být lazy co nejvíc, na tom se určitě shodneme. Implementace je tedy k diskuzi, jedna trošku prasácká cesta už je a zdá se být docela oblíbená. Další zajímavé se vynořují.

Když ale začnou lidé cpát tyhle zbytečnosti do modelu, začne vznikat cosi odporného a na každém druhém řádku bude něco ve stylu

$this->db->get()->query(...);

protože co kdyby se databáze nepoužila…

Navíc tím budeš nepřímo navádět lidi, aby vytvářeli god objekty, protože proč ne – celé je to lazy :) Ospravedlňuješ tím prasení.

Teď accessory nejsou a všichni se snažíme vést nettisty k psaní malých tříd s minimem závislostí a odpovědností. Když něco chceš v třídě, předej si to přes konstruktor, má třída hodně závislostí? Asi toho dělá víc než by měla.

Další problém je, že když bude v Nette @inject by default, tak se tahle metrika vypaří, protože napsat 10 závislostí pod sebe schovaných v třídě pere do očí daleko méně, než když si je musím explicitně předat přes konstruktor.

No a když už budeme mít inject na veřejné proměnné, proč ho rovnou nepovolit i na protected a private :) A to se blbě vysvětluje…

Prosím Davide, neustupuj – ty jsi strážce kvality proslulého Nette Frameworku a tohle není dobrá cesta :)

Mám nápad – vymyslíme jak to implementovat jako rozšíření a upravíme Nette\DI (a Nette\Application) tak, aby tyhle rozšíření hackovaly Nette co nejméně. Budeme mít rozšířitelnější Nette\DI a nebudeme by default navádět k tomuhle java-like prznění objektů :)

WIN – WIN

Ještě doplním jednoduché měření, co prováděl Majkl578 – mluví ve prospěch malých objektů s primitivním konstruktorem. Accessory jsou zbytečné. Vždy to jde řešit lépe a bez nich.

Editoval Filip Procházka (12. 3. 2013 20:09)

Filip Procházka napsal(a):

Když ale začnou lidé cpát tyhle zbytečnosti do modelu, začne vznikat cosi odporného a na každém druhém řádku bude něco ve stylu

$this->db->get()->query(...);

protože co kdyby se databáze nepoužila…

Toho se rozhodně neobávám. Vždy je jednodušší napsat /** @inject @var Nette\Database\Connection */ a pak přímo pracovat s databází, než vytvářet interface accessoru a pak všude používat $this->db->get().

Navíc tím budeš nepřímo navádět lidi, aby vytvářeli god objekty, protože proč ne – celé je to lazy :) Ospravedlňuješ tím prasení.

Nechápu… Co je lazy? A jak souvisí lazy s god objekty?

Teď accessory nejsou a všichni se snažíme vést nettisty k psaní malých tříd s minimem závislostí a odpovědností. Když něco chceš v třídě, předej si to přes konstruktor, má třída hodně závislostí? Asi toho dělá víc než by měla.

Na tomhle anotace @inject, accessory ani továrny absolutně nic nemění. Opět jde jen o objekt, který se předává.

Další problém je, že když bude v Nette @inject by default, tak se tahle metrika vypaří, protože napsat 10 závislostí pod sebe schovaných v třídě pere do očí daleko méně, než když si je musím explicitně předat přes konstruktor.

Ty, které tahle metrika nezajímá, si stejně žádné závislosti nepředávají a používají statiku. Ty, které zajímá, nepotřebují, aby je to pralo do očí. A psát zbytečný/rutinní kód navíc otravuje oba tábory.

No a když už budeme mít inject na veřejné proměnné, proč ho rovnou nepovolit i na protected a private :) A to se blbě vysvětluje…

To je stejný případ jako protected metoda inject().

Prosím Davide, neustupuj – ty jsi strážce kvality proslulého Nette Frameworku a tohle není dobrá cesta :)

Jsem přesvědčen, že je ;)

DG: +1, i luv property injection

David Grudl napsal(a):

Navíc tím budeš nepřímo navádět lidi, aby vytvářeli god objekty, protože proč ne – celé je to lazy :) Ospravedlňuješ tím prasení.

Nechápu… Co je lazy? A jak souvisí lazy s god objekty?

Myslel jsem tím accessory. Vsadím se o oběd v indické, že do roka a do dne, od momentu kdy bude ve stable Nette podpora accessorů, se nám tady na fóru objeví člověk, který bude mít na naprostou většinu služeb accessory a bude je používat na vše :) A ani se za to nebude stydět.

Jsem skálopevně přesvědčen, že generované accessory jsou zbytečné a pouze uživateli ospravedlňují god objekty.

Na tomhle anotace @inject, accessory ani továrny absolutně nic nemění. Opět jde jen o objekt, který se předává.

Tak jak jsi to implementoval teď, tak je to ok – protože je to čisté DI, předáváš do public proměnné.

Ovšem stačilo pár hodin a moje slova se plní

No a když už budeme mít inject na veřejné proměnné, proč ho rovnou nepovolit i na protected a private :) A to se blbě vysvětluje…

Honza Marek napsal(a):

Nechápu, kde se bere to přesvědčení, že vytvoření nějakého lazy bazmeku (což je obyčejný objekt) je levnější než vytvoření běžné service (což je obyčejný objekt).

+1

Editoval Filip Procházka (13. 3. 2013 10:02)

Honza Marek napsal(a):

Nechápu, kde se bere to přesvědčení, že vytvoření nějakého lazy bazmeku (což je obyčejný objekt) je levnější než vytvoření běžné service (což je obyčejný objekt).

A skutečně: new stdClass (obyčejný objekt) je levnější, než new PDO (obyčejný objekt).

Pochopitelně člověk se musí řídit rozumem, jinak režie lazy obálek výkon sníží.

Tharos napsal(a):

Nepřipadá vám (zastáncům „accessorů“), že těch objektů, pro které je vytvoření nějaké proxy třídy skutečně přínosné, je v typické aplikaci úplné minimum?

Pochopitelně. Tvrdí někdo opak?

Pokud ano (a já si to myslím), tak těch pár jednotek pomocných tříd přece nemá smysl generovat. To si každý napíše snadno sám ručně.

A pravděpodobně blbě, tj. napíše pomocnou třídu, ale už nenapíše interface, jehož je tato třída implementací. Bez interface vytvoří závislost na DI kontaineru.

Pokud mi napíše interface, rád mu tu implementaci vygeneruju: řešení pak bude čisté.

Skoro bych se vsadil, že zavedení automatického generování něčeho podobného povede k nadužívání a přinese to pouze negativní dopady (pomalejší a méně přehledné aplikace).

Jasně, už vidím, jak všichni píšou desítky rozhraní accessorů pro každou službu a poté k nim o něco složitěji přistupují.

Filip, prečo chceš aby každá cvičená opica, ktorá dostane do ruky nette, naprogramovala ukážkovú aplikáciu? Nemyslím si že je možné naprogramovať framework tak, aby toto dokázal. Zrušíme celý DIC len preto, lebo ho časť programátorov používa ako service locator? (blbý príklad? :D)

Nemůžu se než podivovat Hosiplanovu přístupu. Pořád bojuje za nějakou teoretickou čistotu v Nette, ale v praxi všichni víme, že je nepoužitelná. Prasit se bude vždy, Hosiplan to dělá, jen na to nemá koule to hodit do Kdyby. (hosiplan/nette-autowire-properties)

1. Je naprosto legitimní vyžadovat lazy přístup:
   1. Automatické proxy mi přijde jako totální blbost a magie.
   2. Accessory mi přijdou jako dobré řešení
      • jejich hnusná syntaxe (->get()) mě dostatečně odradí, abych je nepoužíval všude
      • v ostatní případech si nechám injectnout rovnou objekt
2. Proč je nutné vyžadovat lazy přístup:
   1. cyklická závislost:
      • mějme dva objekty, které navzájem se občas využívají, typicky mějme dvě fasády. Třeba UsersFacade a ArticlesFacade. Dokážu si vcelku jednoduše představit jejich cyklickou závislost. A pokud se vám to nějak nezdá, představte si aplikaci, která ma 30 fasád, a z fleku mi tu odpřisáhněte, že nikdy nemůže nastat cyklická závislost. Jak by se korektně měli injektovat služby v DICu, např. přes constructor, když nebudou lazy?
   2. dominová závislost:
      • mějme opět fasády: jak správně už padlo, vytvoření jednoho objektu nic nestojí. Ale mám v aplikaci 30 fasád, kdy většina zavisí na jedné a více fasádách. Tady už vůbec není zanedbatelné vytvoření všech 30 tříd. Navíc, z principu DI já ani netuším, jak daleko mi domino dojede. Fasáda může být vyžadovat cache. A tato cache může při vytvoření něco invalidovat, připojovat se k memcache serveru, … Čím víc budu mít specializovaných malých tříd, tím více bude dominový efekt zřetelnější a méně předvídatelný. Prosím uvědomte si to.

Shrnutí: Aktuální stav JE a po implementování tohoto i BUDE horší méně pohodlný, než se statickým peklem. Když už jsme si celé aplikace přepsali to ->context->session a nic tím navíc nezískali, rád bych, aby cíl byl vysoký a nebyli spokojeni s aktuálním stavem injectSession(), ale byli ještě pohodlnější a přitom čistí. Občas se musí udělat kompromis. @inject na public property je naprosto čistý. Automatický accessor je naprosto čistý. To, že se něco může zneužít není důvod proti tomu samotnému. Já se ptám, jak udělat accessory pohodlnějšími? Co třeba přidat __invoke()? (Bohužel myslím nebude fungovat na property. $this->pdo()->...)

hrach napsal(a):

1. Automatické proxy mi přijde jako totální blbost a magie.

Co je na proxy magického? IMHO je to naprosto čistá aplikace programování proti rozhraní.

Mohl bys to prosím více rozvést? Nemyslím to vůbec ve zlém, fakt by mě zajímalo, co přesně Tě k takovému závěru vede.

Souhlasím s @Tharosem. Generování proxy proti rozhraní mi přijde daleko lepší než mít accessory. Když interface nebude, vyhodit výjimku. Naprosto dokonalé a neprůstřelné řešení, které navíc bude vést lidi (začátečníky) k programování proti rozhraní.

@inject nad public property OK. Nejspíš to používat nebudu, protože i já bych se z lenosti dokopal k prasení. Ale prosím accessory ne-e!

hrach napsal(a):

Nemůžu se než podivovat Hosiplanovu přístupu. Pořád bojuje za nějakou teoretickou čistotu v Nette, ale v praxi všichni víme, že je nepoužitelná. Prasit se bude vždy, Hosiplan to dělá, jen na to nemá koule to hodit do Kdyby. (hosiplan/nette-autowire-properties)

Tady bych se s dovolením důrazně ohradil!

1. Zpohodlnění presenterů mám v plánu dát do Kdyby – jen není čas
2. Teoretickou čistotu praktikuju dnes a denně a nepřekvapivě funguje i v praxi

Jak už jsem opakoval snad 100×

• V presenterech service locator, nebo nějaká forma autowire – proč ne.
• V modelech? Nikdy.

Je naprosto legitimní vyžadovat lazy přístup:

Souhlasím.

Automatické proxy mi přijde jako totální blbost a magie.

Pokud napíšeš třídu čistě, tak ne. Na druhou stranu, nejsem fanda proxy patternu, ale má svoje místo například v Doctrine. Tady bych si tím nebyl úplně jistý.

Accessory mi přijdou jako dobré řešení

Accessory jsou zbytečné. Tam kde objekt bude „heavy“ (například PDO), tak ho owrapuju do třídy, které předám například jen pár stringů s údaji pro připojení do databáze (pro PDO) a vytvořím ho až když je potřeba. To že se PDO dědí je prostě chyba návrhu, která v prvopočátku nikoho nenapadla, nebo mu nijak extra nevadila. Na druhou stranu, reálně stránek, které databázi nepotřebují je naprosté minimum.

Vzor dekorátor určitě znáš.

cyklická závislost:
… třeba UsersFacade a ArticlesFacade. …

Co místo cyklické závislosti vytvořit třetí objekt, který bude řešit věci, u kterých jsi se nedokázal rozhodnout, kam je dát? Závislost ti zmizí. Klidně vytvářej tisíce tříd, já to tak dělám a funguje to ;)

Reálné příklady, kdy se tomu nejde vyhnout (narazil jsem na ně), řeším pak service locatorem. Ale těch je minimum. Navíc to vždy napíšu tak, aby se to konfigurovalo, jako by se žádný service locator nepoužíval, ale je pouze optimalizací, která mimo jiné vyřešila i cyklickou závislost.

Čím víc budu mít specializovaných malých tříd, tím více bude dominový efekt zřetelnější a méně předvídatelný. Prosím uvědomte si to.

No a ono je to přesně naopak, když si umíš graf objektů navrhnout.

@inject na public property je naprosto čistý.

Souhlasím.

Automatický accessor je naprosto čistý.

Tomuhle bohužel též nejde nic vytknout. Na druhou stranu, jeho použití se jde vždy vyhnout a proto ho nepovažuji za best practice ani za fallback practise :P

Editoval Filip Procházka (13. 3. 2013 16:30)

No když už budu chtít lazy nad PDO, tak si ten accessor můžu napsat sám. Přijde mi, že tu obhajuješ accessor jen kvůli PDO a ničemu jinému, protože PDO je prostě fuj a dlouho se vytváří.

Kdybych přece jen chtěl mít rozhraní pro PDO je nejjednoduší podědit nebo udělat kompozici do vlastní třídy a udělat vlastní interface. Beng! a můžu mít proxy. A zas tolik práce to nedá.

EDIT: @Hosiplan to napsal dřív a lépe.

Editoval redhead (13. 3. 2013 15:21)

Další case, který mluví proti accessorům: nějaká závislost se nyní vytváří dlouho nebo je jinak náročná. Po pár měsících refaktoruji vnitřní kód nebo použiji jinou implementaci a vytváření se stane zanedbatelně náročné – v tuto chvíli už je tedy lazy inicializace pomocí accessorů zbytečná. Jenže všude, kde teď třídu používám budu mít kód $depAccessor->get()->do(); a budu muset přepisovat mnohem víc kódu (odstranit všechny get() volání, měnit type hinty, přejmenovávat proměnné – všude, VŠUDE). Hell!

Jistě, proč by to měl vědět? Presenteru to má bejt naprosto fuk. On totiž sám neví, co je a co není potřeba inicializovat lazy, co je a co není náročné. Stejně tak i modelové třídy. To ví přece někdo jiný a jsme zpátky u poučky DI, tak jak ji trefně napsal ve svém článku David.

Pokud se něco změní a lazy inicializace nebude potřeba, nastává stejný hell (vlastně o dost větší) jako u ne-DI aplikace, kde je všude nadrátované new Class a my potřebujeme najednou použít Class2.

A pokud chcete konkrétní příklad, tak třeba Latte se načítá, instancuje a konfiguruje až ve chvíli, kdy se při vykreslování šablon zjistí, že některá z nich není zkompilovaná v cache. Což je třeba v jednom případě z milionu požadavků.

Jiný pohled na accessor je, že je to vlastně service lokátor – pro jednu konkrétní službu. A to je moc šikovné (protože x-krát mám chuť si ten container poslat :-P )

Pokud mám problém, že se mi nelíbí $this->myServiceAccessor->get(), obalím si přístup do `

function getMyService()
{
    return $this->myServiceAccessor->get();
}

Což *stejně obyčejně dělám*. Rozdíl proti factory a Accessor je ten, že nemusím psát:

function getMyLazyService() {
  if ($this->myLazyService === NULL) {
     $this->myLazyService = $this->myLazyServiceFactory->create();
  }
  return $this->myLazyService;
}

Já jsem pro.

Editoval jasir (13. 3. 2013 20:24)

jasir napsal(a):
Ano. A pak můžu mít závislost na service lokátoru (čti – accessoru) – protože lazy, protože to není továrna (objekt se vytvoří jen jednou). Zcela ok.

Já ale nechci mít třídu závislou na service lokátoru, ten já pro běh mého objektu nepotřebuji. Třídu chci mít závislou na objektu, se kterým potřebuju pracovat. Service lokátor je další (viditelný) middle-man stejně tak jako je teď context.

Anotace @inject pro public atributy určitě.

Jsem pro Accessory za následujících podmínek:

• Accessor mi znatelně ušetří psaní kódu oproti proxy nebo vlastní implementaci.
• Někde v dokumentaci bude jediná stránka, na které bude srozumitelně popsáno jejich použití a použití i dalších zde uvedených postupů, včetně rozlišení, kdy a jak má být který použit. I kdyby jen v Planette. To by začátečníkům mohlo pomoci.

Navíc začátečník bude mít podle mě mnohem více jiných věcí, které bude a může prasit.

@redhead: David pomocí „triku“ docílil, že se použije jiná service jako factory a vždy se proto vrací stejná instance (protože ta service už ji má vytvořenou a DIC si ji drží).

Editoval Filip Procházka (13. 3. 2013 21:00)

redhead napsal(a):

Pořád čekám, až vypadne nějaký pádný argument.

Už jsem všechno sepsal, víc toho ode mě nebude. Snad jen dodám, že „obalit do proxy“ se lehce napíše, ale lze toho dosáhnout jen za cenu značných kompromisů a prakticky vůbec ne ručně.

A to nestačí?

Pokud tím chceš ospravedlnit špatný návrh, tak prosím. Mělo by to napravovat automaticky Nette? Neřekl bych. (mimochodem, přidat interface pro třídu, na kterou nemůžu šáhnout, je prkotina)

Stejně si myslím, že takových případů, kdy je potřeba ať už proxy nebo accessor má být (a zpravidla taky je, pokud neprasím presenter) minimum a tedy, že i automatické generování (proxy nebo accessoru) je zbytečná feature. Já ani accessor ani proxy v Nette ještě nepoužil a žádný bottle-neck se mi nikde nevyskytl. Po optimalizaci výkonu bych pátral jinde, protože tady problém není, nebo není tak závažný. A když už bude jó potřeba, tak si proxy vyrobím ručně.

Takže chceš nahradit divnost bez interface, kterou by napsal ručně uživatel, za jinou divnost, kterou vygeneruje Nette. Nehledě na to, že případů, kdy je to potřeba, je minimum. Nějak mi nedochází, proč je tohle v Nette potřeba. A pokud uživatel nedokáže navrhnout aplikaci správně nebo nemá znalosti, tak nejspíš i accessory bude používat blbě (viz co psal Filip na začátku). Snaha byla, máš svou hlavu.

David Grudl napsal(a):

Ano, takových případů je naprosté marginální minimum.

tady jsem se nějak zacyklil. zdá se mi, že debata jde stále dokola…

Diskuse je o tom, že předat si továrnu, která vrací pokaždé nový objekt, je ok, ale předat si továrnu, která vrací stále tentýž objekt, je čiré zvěrstvo ;)