[2011–05–05] Finalizace Dependency Injection

HosipLan napsal(a):

Když je nějaké služba, která nepotřebuje (čti nesmí) vidět všechny služby, tak je vhodnější vytvořit novou instanci Containeru, předat do ní jen pár služeb a tu pak předat jako „kontext“ dané službě.

To je krásný antipattern, který je v Nette hojně využívaný. Samozřejmě hezčejší by bylo, kdyby ta služba měla do sebe předané přes konstruktor nebo settery už přímo potřebné služby nebo nějaké továrničky na ně (kdyby bylo potřeba línou inicializaci).

HosipLan napsal(a):

Když je nějaké služba, která nepotřebuje (čti nesmí) vidět všechny služby, tak je vhodnější vytvořit novou instanci Containeru, předat do ní jen pár služeb a tu pak předat jako „kontext“ dané službě.

„Tohle“ mi právě moc nejde do hlavy (vytvářet nový objekt jen proto, abych do něj zkopíroval odkazy na služby z nějakého globálního kontejneru). Protože jednak z obecného hlediska (zaměnitelnosti implementací) nevím, jaké všechny služby bude ten konkrétní objekt, co zrovna vytvářím, potřebovat; druhak, pokud si nějaká implementace bude chtít šáhnout na nějakou službu, o které jsem původně usoudil, že ji nepotřebuje/nesmí na ni šahat, tak toho stejně nakonec nějak dosáhne… jen trochu krkolomněji. Prostě izolace jednotlivých služeb je tak trochu dvousečná zbraň.
Další věc je, že většina služeb jsou typicky singletony (v rámci celé aplikace) a jejich jedinečnost se dost blbě hlídá ve chvíli, kdy začnu tvořit nové kontejnery pro jednotlivé služby.
Čímž rozhodně nechci tvrdit, že obecně více kontejnerů nemá smysl – rozhodně mě napadají místa, kde se skvěle uplatní: více různých připojení do databáze/kešování na různá místa, testování… jen moc nevidím ten zde tolik opěvovaný přínos.

Je to přesně tak. Pokud nějaká služba přijímá kontejner (svůj „kontext“), tak nevím, čím ho mám vlastně naplnit a musím jít zkoumat její zdrojáky. Vím, že jsme toto řešení do Nette s Mediem prosazovali, ale v té době se vše řešilo přes Environment, takže to byl krok kupředu. Je potřeba jít ale ještě dál :)

Správné řešení je explicitní vyjádření konkrétních závislostí tím, že je služba přijímá v konstruktoru, případně pro jednorázové použití v metodách.

(Setter injection je blbost a berlička pro případ, že konstruktor je už něčím obsazen. Tohle dělá špatně např. třída RobotLoader, která je závislá na CacheStorage, ale přijímá ho pomocí setteru a ne konstruktoru.)

Kontejner by měl být přístupný pouze na pár speciálních místech – napadají mě cron skripty, testy a PresenterFactory.

Doufám, že se na tohle David chystá.

Honza Marek napsal(a):

To je krásný antipattern, který je v Nette hojně využívaný.

Hojně = 1× v Nette\Application\Application?

Samozřejmě hezčejší by bylo … nebo nějaké továrničky na ně (kdyby bylo potřeba línou inicializaci).

A jak by taková implementace předávání továrniček místo služeb vypadala? Třeba jako současný DI\Container? ;-)

xificurk napsal(a):

Protože jednak z obecného hlediska (zaměnitelnosti implementací) nevím, jaké všechny služby bude ten konkrétní objekt, co zrovna vytvářím, potřebovat;

To právě vědět musíš. Ať už služby předáváš konstruktorem nebo přes settery, výčet služeb je jasný, jde o sumu všech parametrů.

Čímž rozhodně nechci tvrdit, že obecně více kontejnerů nemá smysl – rozhodně mě napadají místa, kde se skvěle uplatní: více různých připojení do databáze/kešování na různá místa, testování… jen moc nevidím ten zde tolik opěvovaný přínos.

Přínos to má pouze pro ty, kteří to chtějí využívat (a vidí v tom přínos). Z hlediska běžného a většinového uživatele se vůbec nic nemění. Pokud jsi dosud nad DI v Nette neuvažoval, nemusíš ani teď, ono pod kapotou běží zcela automaticky.

Ondřej Mirtes napsal(a):

Je to přesně tak. Pokud nějaká služba přijímá kontejner (svůj „kontext“), tak nevím, čím ho mám vlastně naplnit a musím jít zkoumat její zdrojáky.

V tom případě vytváříš služby špatně, co ti na to mám říct.

Vím, že jsme toto řešení do Nette s Mediem prosazovali, ale v té době se vše řešilo přes Environment, takže to byl krok kupředu. Je potřeba jít ale ještě dál :)

Ale kdepak, problém byl v $presenter = new $presenterClass v Application, což vyřešil Honzův PresenterFactory.

(Setter injection je blbost a berlička pro případ, že konstruktor je už něčím obsazen. Tohle dělá špatně např. třída RobotLoader, která je závislá na CacheStorage, ale přijímá ho pomocí setteru a ne konstruktoru.)

Naprostý nesmysl. Setter injection zčitelňuje kód.

Kontejner by měl být přístupný pouze na pár speciálních místech – napadají mě cron skripty, testy a PresenterFactory.

Tak konkrétně: kde všude v Nette vadí kontejner?

David Grudl napsal(a):

Ondřej Mirtes napsal(a):

Je to přesně tak. Pokud nějaká služba přijímá kontejner (svůj „kontext“), tak nevím, čím ho mám vlastně naplnit a musím jít zkoumat její zdrojáky.

V tom případě vytváříš služby špatně, co ti na to mám říct.

Jak mi tedy vysvětlíš, že když jsem chtěl zjistit, které služby potřebuje Nette\Http\User, musel jsem se podívat do zdrojáku? :)

Proč jsou vlastně ty authorizator a authenticator líný? Jaký je rozdíl mezi instanciací těchto dvou a nějakýho containeru?

David Grudl napsal(a):

Ve současné implementaci chybí jen jediné: chybějící volání checkServiceType v kontruktorech Application a User.

A tagy :-)

Cokoli má být lazy a uvnitř objektu, do kterého je to vstřikované, se nevyužije vždy, to bych řešil pomocí továrniček. Takže bych do usera předal AuthorizatorFactory a AuthenticatorFactory, které by volaly new Authorizator, resp. new Authenticator až při $factory->create().

Co se týče Usera, tak bych z něj autorizaci i autentizaci vyhodil úplně, protože mi tam nedává smysl. Musím si do něj předat autentikátor jenom kvůli tomu, aby na něm user zavolal nějakou metodu, kterou na něm mohu zavolat sám. Po Userovi požaduji jen to, aby mi zajistil přihlášení usera, tedy uložení jeho identity do session. Vše ostatní by měly zařizovat jiné objekty.

Porovnejte tyto dva kódy:

$user->setAuthenticationHandler($facebookAuthenticator);
$user->login($uid); // zde se zadem volá FacebookAuthenticator, je to nečitelné

a:

$identity = $facebookAuthenticator->authenticate($uid);
$user->login($identity); // zde se do session uloží to, co tam sám předám

Editoval Ondřej Mirtes (15. 5. 2011 22:20)

Ondřej Mirtes napsal(a):

Cokoli má být lazy a uvnitř objektu, do kterého je to vstřikované, se nevyužije vždy, to bych řešil pomocí továrniček. Takže bych do usera předal AuthorizatorFactory a AuthenticatorFactory, které by volaly new Authorizator, resp. new Authenticator až při $factory->create().

A jak bys zajistil, že takto vytvořený autorizátor bude singleton v nějakém scope, tj. budeš ho chtít předat ne do jednoho objektu User, ale do více objektů?

Špatně? Jak mám zvenku odhadnout, jaké má ty služba závislosti, když přijímá pouze DI kontejner? (který takhle zaujímá pozici ServiceLocatoru).

Pokud není možné předávat explicitně služby a trváš na předávání kontejneru (zdůrazňuji, že volba je na tobě) můžeš použít typehint a předat statický kontejner. V případě dynamického lze závislosti uvést v dokumentaci a kontrolovat pomocí checkServiceType.

Tohle je obecný problém jakéhokoli místa, kde je operátor new. Jakmile je někde v kódu natvrdo new, nijak na tom místě tu napevno vytvářenou implementaci ničím nenahradíš. Proto jsem navrhoval, že by celé Nette mělo vnitřně fungovat na konfigurovatelném DI kontejneru, což nyní částečně supluje pole $defaultServices.

Ale tak to přece funguje odjakživa, celé Nette je konfigurovatelné pomocí systémového kontejneru, ten je konfigurovatelný pomocí config.neon.

A pokud tím celé Nette myslíš jako odstranit úplně všechny new, tak sorry, ale předávat v konstruktoru seznam tříd výjimek, abych měl full-DI i třeba na výjimku InvalidArgumentException, tak to je nesmyslná úchylárna.

Pokud jsi narazil na konkrétní případ, kde by bylo vhodné nahradit new za DI, tak ho konkrétně zmiň, jinak je to prázdné třepání.

Do počtu 3–4 parametrů v konstruktoru je to v pohodě.

Jasně, $obj = new Object($argX, $argB, $arg7, $argXy) je úžasně srozumitelné, jasné jak facka, zatímco $obj->setTemplateFilter($argX)->setCacheStorage($argB)... je bad smell, fuj, špatně, ostuda, Miško Hevery se obrací v posteli ;)

Tak konkrétně: kde všude v Nette vadí kontejner?

Ptám se znovu, kde ti vadí? Našel jsi 1 případ, třídu User? Hrůza, tak to je celý framework na odpis! :-)

Davide asi chápu kam tím míříš – nechceš asi nikomu nařizovat jak má kdo svůj kód přesně psát (vynucení constructor injection, použití kontextu jako Service Locator), chápu to správně? Jestli ano, tak s tím jednoznačně souhlasím, ale zároveň si taky myslím, že Nette samotné by mělo být napsáno tak, aby reprezentovalo ty nejčistší možné volby. – Constructor Injection a důkladné vyjmenovávání služeb (ne kontext/container/w/e).

Dobrým příkladem je právě RobotLoader, jak uváděl Ondra, s tím mám osobní zkušenosti.

Pokud chci nějaký objekt mít vytvořený lazy a zároveň singleton, tak ta továrnička může vytvářet/vracet jedinou instanci.

class SingletonAuthenticatorFactory
{

	private $instance;

	public function create()
	{
		if ($this->instance == NULL) {
			$this->instance = new Authenticator();
		}
		return $this->instance;
	}
}

Konstruktor vs. setter:

Jak mám vědět, že po konstruktoru musím volat ještě setTemplateFilter a setCacheStorage? Navíc bych čitelně napsal new Object($cacheStorage, $templateFilter) a nešifroval bych to do $argX proměnných :)

config.neon:

Tady jsem navrhoval jen to, že by se mi líbilo, kdyby $defaultServices bylo nahrazeno nějakým nette.neon přímo ve frameworku, aby pro tu samou věc neexistovala dvojí syntaxe. Do tohoto configu by se pak mergovaly uživatelské configy, ve kterých by se mohla ta nastavení překrýt.

new:

To samozřejmě nemůžeš aplikovat na výjimky, ty nahrazovat nechceš :)

Já vůbec neříkám, že je Nette na odpis, ale že ten mnou prezentovaný přístup mi přijde správný a univerzální, tak bych ho rád sjednotil napříč celým frameworkem. Proč Template nedostává celý kontejner, ale jen Translator setterem? Proč jiné objekty dostávají celý kontejner? Chci zabránit těmto situacím, ke kterým, jakmile si něco z jádra Nette sestavuji ručně (Application, Presenter, Control), dochází často.

Ondřej Mirtes napsal(a):

Pokud chci nějaký objekt mít vytvořený lazy a zároveň singleton, tak ta továrnička může vytvářet/vracet jedinou instanci.

Teď ji ještě uprav tak, aby byla konfigurovatelná a dostupná ze systémového kontextu (např. přes Environment::getContext()->getService('authenticator')).

Tady jsem navrhoval jen to, že by se mi líbilo, kdyby $defaultServices bylo nahrazeno nějakým nette.neon přímo ve frameworku, aby pro tu samou věc neexistovala dvojí syntaxe.

Neumím si představit, jak by se zapisoval kód některých továrniček v neonu.

Já vůbec neříkám, že je Nette na odpis, ale že ten mnou prezentovaný přístup mi přijde správný a univerzální, tak bych ho rád sjednotil napříč celým frameworkem. Proč Template nedostává celý kontejner, ale jen Translator setterem? Proč jiné objekty dostávají celý kontejner?

Chování je jednotné.

Nevim jestli se teď Davidovi bude chtít takovým plantážníkům něco vytvářet :)

Já tak rád slovíčkařím :) https://github.com/…tte/pull/242 Něco takového jsem myslel… Ale tohle je asi ta poslední věc a dá se bez toho žít

Zajímalo by mě, k čemu konkrétně v praxi potřebuješ použít vlastní Configurator. (kvůli zamýšlené úpravě)

Jelikož Configurator má prakticky za jediný úkol vyrobit systémový context (tj Environment::getContext(), přesouvat tento úkol jinam nedává moc smysl.

Místo výměny konfigurátorů se mi zdá pružnější umožňit použití vlastního kontextu (tj. přidat Environment::setContext()).

ContainerBuilder je obecná třída pro práci nad obecným kontejnerem. Zřejmě ji do frameworku přidám, aby uměla načíst třídy z pole a případně vygenerovat PHP cache.

Jasně, setContext(). Prostě nemusíš vůbec Configurator dědit. Obecně vzato, vůbec nemusíš používat ani třídu Environment, ani třídu Configurator a rovnou pracovat s vlastním DI kontejnerem.

Trochu odbočím /respektive vrátím se k jádru tématu ;)/. Všiml jsem si, že kontextu předávanému Application se z „globálního“ kontextu předává služeb vcelku poskrovnu. Pokud jich chci předat více /například cacheStorage, abych nemusel pro přístup ke cache všude volat Environment::getCache() a měl vše hezky cool DI a mohl se v hospodě chvástat, jak nikde v aplikaci nepoužívám třídu Environment ;)/, plus bych si rád do contextu Appliction předal i například službičku config (mám v neonu i řadu nastavení, se kterými pracují komponenty a podobně), tak mi nezbývá, než si nadefinovat úplně vlastní createApplication:„https://api.nette.org/2.0/source-common.Configurator.php.html#299“ (a skoro shodnou s původní, jen doplněnou o předání těch několika dalších služeb z globálního kontextu) a používat tu. Chápu to správně?

A zároveň, jestli to tedy dobře chápu, je toto v podstatě nejsnazší způsob, jak v duchu DI používat něco z config.neon (jak se tu na fóru teď někdo někde ptal). Je to významný krok kupředu, dobrá práce!

Jo a upozorňuji, že svůj dotaz nezamýšlím jako nějakou skrytou kritiku nebo tak :), nový koncept nemám problém přijmout za svůj a chápu jeho výhody.

Pokud zrovna nevytváříš potomka třídy Application, tak žádné další služby by sis do něj přidávat neměl. On je nepotřebuje. Je to totéž, jako zavolat funkci s více parametry, než očekává / přijímá. Nemá to žádný efekt.

Služby si tedy předávej přímo tam, kde je budeš potřebovat. Do presenteru například pomocí PresenterFactory.

navrhuji public Application::getContext() na protected nebo úplně zrušit

Editoval Patrik Votoček (17. 5. 2011 0:39)

Ještě mě tak napadá je v plánu aby Environment::

• setVariable
• getVariable
• getVariables
• expand
• getService
• getHttpRequest
• getHttpResponse
• getHttpContext
• getApplication (tady si nejsem úplně jistý)
• getUser
• getRobotLoader
• getCache
• getSession
• getConfig

vyhazovaly deprecated nebo byly rovnou odstraněny?

Doplnil jsem do prvního příspěvku informaci o používání tagů.

Tharos napsal(a):

Díky moc vám oběma za nakopnutí, konečně mi to všechno secvaklo a zapadlo hezky dohromady.

---

A zvažte lock tohoto vlákna, protože když už to secvaklo i mně, tak to už asi opravdu musely být všechny smysluplné otázky položeny a zodpovězeny ;).

Jeste ne, protoze me to porad jeste tak uplne do sebe nezapadlo :-) Ale predpokladam, ze po vydani finalni verze k tomu bude podrobna dokumentace (?) :-)

Coz o to, k tomu jsem dospel uz relativne davno, spis mam problem pochopit jeho fungovani v nette :-)