Dependency Injection ve 2.1: Anotace @inject

Pod enumagův příspěvek bych se podepsal.

Já jsem pro a klidně bych z fleku začal přepisovat dokumentaci, ale zase mi někteří budou vyčítat, že chci psát dokumentaci pro nestabilní verzi, nebo dokonce, že bychom měli dokumentaci psát pro 2.0.0 a né pro 2.0.10 (nebo .11 ?).

Domnívám se, že ve chvíli, kdy 2.1 vstoupí do beta fáze, dokumentace by se měla rozdělit na verzi pro 2.0 a 2.1.

Idealne aby to bylo na gitu, to se pak bude delat jedna basen :)

Stále považuji za zásadní problém chybějící podporu use statementů. Mám zkusit připravit pull?

Urcite prosim :)

@Majkl578: +1 pro use!

@hrach:

Idealne aby to bylo na gitu, to se pak bude delat jedna basen :)

To by bylo skvělý! +1

Editoval enumag (23. 4. 2013 20:35)

Ohledně @inject, v současné době funguje @inject pouze u public proměnných tříd. Inject* metody umožňují injektování i do private či protected proměnných. Inject* metody tedy v tuto chvíli nelze zcela nahradit anotací @inject. Nebo mi něco uniklo?

Svůj příspěvek jsem nepsal proto, abych obhajoval @inject do private/protected metod, ale proto, abych se dozvědel, čím chce David nahradit aktuální použití inject* metod (kterým chce učinit přítrž) v případech, kdy tyto metody nastavují private či protected proměnné objektu. Navíc jeho poznámka, že @inject vnímá jako syntaktický cukr pro rutinní předání závislostí přes konstruktor naznačuje možnost, že hodlá podporovat i tuto formu injektáže (neboť konstruktor ji také umožňuje).

Odpověď „@inject do private/protected nemá nic společného s DI“ je pro mě v tomto ohledu naprosto k ničemu. Navíc s ní ani nelze souhlasit, protože to injektáž závislostí (tedy DI) nepochybně je (neříkám že se neprohřešuje proti určitým principům – jde o jakousi násilnou formu DI – a nijak ji nepropaguji), ale je tím, čím je.

Podle mě by možnost injectu do protected/private měla být přinejmenším konfigurovatelná. V Javě je to běžná, osvědčená, přímočará a jednoduchá praktika, jak do objektu dostat závislost.

@inject do private/protected nemá nic společného s DI.

Nesmysl. DI je to stejně tak jako injectování do public property. Jediný rozdíl je pouze ten, že třída explicitně neuvádí závislosti skrze své API. Dokážu si představit, že v aplikaci bez testů a/nebo v presenterech to kdekdo rád oželí.

Náhražkou inject metod je právě použití public property.

Ne plnohodnotná, jelikož s sebou přináší problémy.
Vyžadování public property je sice hezké z akademického hlediska, ale zároveň to (bez nativních property accessorů) porušuje zapouzdřenost objektu, poněvadž kdokoliv může kdykoliv za běhu (třeba i omylem) změnit hodnotu a objekt se o tom vůbec nedozví.

Já teda vnímám pečlivé zapouzdření jako jeden z klíčových aspektů robustního návrhu. Takže pokud by @inject vyžadovalo zrušit zapouzdření, sám bych to rozhodně nepoužíval (nabourání zapouzdření by pro mě byla až příliš vysoká oběť). Pokud by šlo injektovat do privátních proměnných, v např. presenterech bych to určitě používal (za cenu drobného hacku, oželení akademické čistoty a de facto vytvoření závislosti na konkrétním DI kontejneru si významně ušetřím psaní).

Kdykoliv přijdu ke kódu, kde je nějaká veřejná třídní proměnná, tak chvíli tápu, co si o ní mám myslet a co si s ní mohu dovolit dělat. U nějakých „value objektů“ se zorientuji rychle, ale pokud je to instance nějaké „normální třídy“, jak s tou proměnnou mohu pracovat? Mohu tam jen tak něco frknout? Rozbije se to nebo ne? Co když tam frknu null? Nebo úplně jiný typ, než to předpokládá? Poznám vůbec, že jsem to rozbil? Jsou na to testy?

Editoval Tharos (24. 4. 2013 10:41)

Public properties mi nepridu ako dobry napad.

Takisto metody inject*. 2–3 zavislosti a mam x riadkov kodu a to som este ani nezacal…

Skor by ma zaujimali moznosti pouzitia (use case-s):

• Komponenty (konstruktor)
• Presentery
• Sluzby (services, servants, …) (konstruktor)
• …

Majkl578 napsal(a):

@inject do private/protected nemá nic společného s DI.

Nesmysl. DI je to stejně tak jako injectování do public property. Jediný rozdíl je pouze ten, že třída explicitně neuvádí závislosti skrze své API. Dokážu si představit, že v aplikaci bez testů a/nebo v presenterech to kdekdo rád oželí.

Pokud máš aplikaci bez testů, nevidím problém v psaní pár public properties. To je jako umývat okna hořícího domu – nic to nezmění :)

Náhražkou inject metod je právě použití public property.

Ne plnohodnotná, jelikož s sebou přináší problémy.
Vyžadování public property je sice hezké z akademického hlediska, ale zároveň to (bez nativních property accessorů) porušuje zapouzdřenost objektu, poněvadž kdokoliv může kdykoliv za běhu (třeba i omylem) změnit hodnotu a objekt se o tom vůbec nedozví.

Krásně si tady protiřečíš.

• „třída explicitně neuvádí závislosti“
• „zároveň to porušuje zapouzdřenost objektu“

Injektování do private/protected zapouzdřenost neporušuje?

Stále mi přijde jako nejlepší řešení tohle.

Editoval Filip Procházka (24. 4. 2013 15:18)

Ad public property a porušení zapouzdření: nechci se opakovat, vše najdete tady.

Jen doplním: anotace @inject zapouzdřuje proměnnou na úrovni dohody. Stejně jako anotace @return nekontroluje, zda funkce vrací to, co má, ale věříme tomu. Nebo stejně, jako nekontrolujeme, zda někdo nepřepisuje závislosti uložené v privátních proměnných tím, že by nad objektem znovu zavolal metodu __construct a předal jiné závislosti. Nebo dokonce potlačil E_RECOVERABLE_ERROR a protlačil objekty jiného typu, než je typehint.

Samozřejmě pokud vám úroveň dohody nevyhovuje, použijte privátní proměnné a konstruktor injection.

Jen doplním: anotace @inject zapouzdřuje proměnnou na úrovni dohody.

Následujíc tuto myšlenku, můžeme všude a) zrušit gettery a settery ve prospěch public properties, b) zrušit non-public viditelnost metod a označit obojí za dohodu. To je ale přeci nesmysl.

Stejně jako anotace @return nekontroluje, zda funkce vrací to, co má, ale věříme tomu.

To je míchání jablek s hruškama. Nijak to totiž neovlivňuje stav/zapouzdřenost daného objektu – je jen a pouze na volajícím, zda tomu věří nebo ne, a ať se rozhodne jakkoliv, stav volaného objektu se tím nijak nezmění.

Nebo dokonce potlačil E_RECOVERABLE_ERROR a protlačil objekty jiného typu, než je typehint.

Tohle je za normálních okolností neproveditelné a pokud by to někdo dělal, je to jako střílet se do vlastní paty. (http://3v4l.org/UgLuj)
Rozhodně je to, narozdíl např. od neúmyslného zápisu do public property, naprosto okrajový případ (ještě krajnější, než aby si dotyčný upravil hodnotu property reflexí).

Samozřejmě pokud vám úroveň dohody nevyhovuje, použijte privátní proměnné a konstruktor injection.

Stále zapomínáš, že ještě lze použít, po vzoru Javy, kde se to velice osvědčilo, private property a property injection. To je totiž z hlediska napsání nejúspornější a zároveň z hlediska zapouzdřenosti nejbezpečnější cesta, která řeší všechny tebou zmínené problémy (a to i včetně hypotetického – ač nereálného – potlačení E_RECOVERABLE_ERROR nebo opakované volání konstruktoru). ;)

@duke: Vesměs souhlasím.

Editoval Majkl578 (25. 4. 2013 2:32)

Majkl578 napsal(a):

Stále zapomínáš, že ještě lze použít, po vzoru Javy, kde se to velice osvědčilo, private property a property injection.

Nezapomínám! Jen mi stále PHP při zápisu do private property vyhazuje fatal error. Nejspíš používáš nějakou jinou verzi.

Imho tenhle příspěvek je stále aktuální. @inject je línější varianta pro inject* metody. Méně psaní.

Každopádně, tahle debata je jenom o presenterech, v modelech a komponentách téměř nemá smysl používat cokoliv jiného, než constructor injection.

Když už, tak:

use Nette\Object;
use Nette\Caching\Cache;

class Foo extends Object
{
	private $bar;

	/** @inject */
	public function setBar(Cache $bar)
	{
		$this->bar = $bar;
	}
}

Inject metody jsou podle mě dobré řešení, ale vůbec by se nemusely psát, stačilo by je definovat v anotacích a volat je magicky. Sice na úrovni kodu jsou to skryté závislosti, ale každé IDE které umí napovídat si s tím poradí a pokud programátor dostane třídu, má hned nahoře seznam těchto magicky nastavovaných závislostí. Pro mě by to byl přijatelný kompromis.
Rovnou by to mohlo zvládat i obyčejné settery a gettery.

<?php
/**
* @method void injectFoo($foo)
* @method void setBar($bar)
* @method int  getBar()
*/
class FooBar extends Object
{
   /** @var classFoo */
   protected $foo; // proměnná bude přístupná pro zápis a navíc bude automaticky injectovaná
   protected $bar; // proměnná bude přístupná ke čtení i zápisu magicky
   protected $i;   // proměnná není přístupná
}
?>

// edit: doplněna třída, která se má injectovat, díky @castamir
On by ten typ proměnné měl být uveden všude, ale u injectované být musí

// edit2: Viditelnost změněná na protected kvůli nastavování v předkovi. Stejně private nepoužívám kvůli prolémům s děděním, jen jsem použil příklad výše..

Editoval Šaman (27. 4. 2013 10:21)

@Šaman: To by ale vyžadovalo podporu DI ze strany Nette\Object.

David Grudl napsal(a):

Nezapomínám! Jen mi stále PHP při zápisu do private property vyhazuje fatal error. Nejspíš používáš nějakou jinou verzi.

Stačí přeci použít reflexi. ;)

stekycz napsal(a):

Osobně nevidím důvod, proč by pro Presentery měl být problém porušení zapouzdřenosti použitím public property.

Tahle diskuze nicméně není pouze o Presenterech, ale o DI obecně.

Zapouzdřenost potřebuji pouze pokud pracuji s danou třídou jako uživatel zvenčí. Pokud ji zvenčí používá jen framework …

Opravdu? A co například použití presenteru v komponentě nebo šabloně?

Navíc jsem líný a chci psát co nejúsporněji to lze, tedy anotace je asi to nejjednodušší.

Souhlasím. Jako nejúspornější a zároveň nejbezpečnější vychází property injection do non-public property, že? :)

Osobně teď používám na jednom projektu od @Hosiplana úpravený BasePresenter pro použití anotace @autowire a jsem spokojen. Jediný rozdíl (alespoň co vím) oproti @inject je v tom, že Filip používá protected property a injektace se provádí až při přístupu k dané službě/property.

Je krásné vidět, že vlastně i HosipLan, který private property injection odmítá, sám používá její obdobu, dokonce zkombinovanou se zatracovaným service locatorem. ;)

@Šaman: Nemyslím si, že podobné přespříliš magické věci by měly být přímo součástí Nette a už vůbec ne Objectu. Shodou náhod je to jedno z řešení, které jsem i já už dříve navrhoval.

Nicméně jak property injection, tak setter injection (pro nutné závislosti) mají jeden zásadní drawback – inicializují objekt dvoukrokově, tudíž v určitou chvíli se nachází v ne-plně-inicializovaném stavu. Co když například někdo bude vyžadovat závislosti pouze skrze properties a v konstruktoru bude mít nějakou (ač jakkoliv jednoduchou) logiku? S constructor injection by tenhle problém řešit nemusel. Kdysi jsme se o tom s někým bavili a jako možné řešení padlo vytvoření instance bez volání konstruktoru, nasetování vlastností / zavolání inject setterů a až následně zavolání konstruktoru.

Editoval Majkl578 (26. 4. 2013 0:47)

Asi by bylo záhodno povolit metody inject jen pro presentery.

Šaman napsal(a):

Rovnou by to mohlo zvládat i obyčejné settery a gettery.

Tohle už v Nette existuje, viz třeba tady https://github.com/…r/Method.php (ale pravda, je to ve formě konceptu, commitnu full verzi).

DI umí všechny myslitelné druhy injektáže, viz setup.

@pekelnik: Ve většině s tebou souhlasím, jen ten argument nemůžete mít všechno je irelevantní. Proč se teda pachtit s nějakou DI a teoretickou čistotou, když ji nemůžeme mít komplet?

<?php
private $cache;
public function __construct()
{
  $this->cache = ServiceManager::getCache();
}
?>

Nemůžu mít všechno, ale mám to krásně zapouzdřeno.

Jinak injector chápu jako setter, ale přeci jen v tom cítím rozdíl. Injector voláš typicky jen jednou ihned po vytvoření nové instance, settit můžeš častěji. Nevadí mi, že jsou tyto metody odlišeny i názvem. Ale je fakt, že většinou je lepší používat konstruktor.

Aha, já to myslel tak, že nemůžeme mít DI i zapouzdřeno :) Ten kód byl trošku provokačka, přiznávám.

Jinak o kontejneru nebyla řeč, jen mi nevadí mít některé settery pojmenované inject a vím, že pokud tuto metodu používám jindy než při vytváření nové instance, asi dělám něco špatně. Dále setter chápu trochu jako nepovinný parametr, zatímco injector bych nastavit měl (teda nenastavuji injector, ale jeho pomocí nastavuji property, ale snad si rozumíme).

@pekelnik: To by se dalo řešit takhle. Osobně ale závislosti které chci injectovat mám jako write-once, tzn. pouze inject* metoda a žádný getter natož setter.

Editoval enumag (26. 4. 2013 23:59)

@Šaman musíš takto vylepšit __call()

Majkl578 napsal(a):

Tahle diskuze nicméně není pouze o Presenterech, ale o DI obecně.

Pleteš se, tahle diskuze je jen a pouze o presenterech, protože všude jinde se standardně používá constructor injection a na tom se shodneme i s lidmi co používají v presenteru $this->context.

Editoval Filip Procházka (28. 4. 2013 17:16)