Vlákno názorů ke článku PHP Jet - Dependency Injection, továrny a tak dále od BoneFlute - Píšete: "Když už si nějaká třída / entita...

Píšete: "Když už si nějaká třída / entita řeší své závislosti, tak je rozhodně lepší, když si je řeší v momentě, kdy je opravdu potřebuje..."
Tento problém se neděje. Například Neťácký DIC dodá závislosti (díky továrničkám) až když jsou potřeba.

Píšete: "... a to jednoduše, transparentně, přímočaře a intuitivně."
Vaše řešení toto IMHO nesplňuje.

Píšete: "Kolega řeší adresář kam se bude logovat, mluví o konstantě, parametru konstruktoru … No jo, ale co když vůbec nechci logovat do souborů? " - To je z toho článku jasně patrné. Logger je vytvořen tak, aby logoval do souborů. Pokud chcete logovat do databáze, vytvoříte DatabaseLogger (jste-li pořádkumilovný původní přejmenujete na FilebasedLogger) a předáte tu závislost, kterou požadujete.
Dokonce si můžete všimnout, že David přísně řeší rozdělení zodpovědnosti. Tedy, že když vytváříte NewsletterDis­tributor, nepředáváte LogDir, protože ten není jeho starost.

Vy máte vytvořenou třídu Logger, "který je nutné "naplnit" a tedy předat backend". Což je sice formálně v pořádku, ale v přímém rozporu s vaší požadovanou jednoduchostí - protože je to zbytečné.

Na každý způsob logování (ve vaší terminologii backend) stačí prostě jen vytvořit implementaci (hrajete-li na typy, tak použijete implementaci rozhraní) a instanci této implementace předat.

I kdybyste z nějakého důvodu trval na svém řešení v podobě kontejneru tak nastavovat logger způsobem: Logger::setLogger( new Logger_Admin() ); je špatné, protože existuje okamžik, kdy je logger nejen v nepožadovaném, ale dokonce (pravděpodobně) v nevalidním stavu. Proto se u většiny moderních FW setkáte s doporučením nastavením pomocí konstruktoru. Nastavování pomocí setteru (či jeho ekvivalentu, jako je inject* v Nette) je považováno za úlitbu legaci kódu, nebo legaci vývojářům.

Ono cele to PHP a jeho komunita v tom ma gulas.

> "Když už si nějaká třída / entita řeší své závislosti, tak je rozhodně lepší, když si je řeší v momentě, kdy je opravdu potřebuje..."
Tento problém se neděje. Například Neťácký DIC dodá závislosti (díky továrničkám) až když jsou potřeba.

V tomto pripade nutnost pouzitia "tovarnicky" znamena, ze chyba je o uroven vyssie a objekt porusuje SRP. (zavislosti pri DI velmi dobre indikuju porusnie SRP)

Zas, tento clanok hovori o Factories - no v skutocnosti jke to service lokator.
Nette clanok, tiez hovori o factory no vskutocnosti to je repozitory.

Fakt, sa za tie roky nic nezmenilo.

Ano, autor php-jet používá "service locator" (to kdyby si chtěl přečíst kritiku tohoto vzoru).

Ne, článek od Davida nepopisuje ani nepoužívá vzor repository. Návrhový vzor repository řeší jak ukládat, případně načítat entity. Davidův článek popisuje jak poskládat instanci a jak jí dodat závislosti.

Ne, DI neporušuje SRP, naopak. Je důkladnou snahou o jeho dodržení. DI zajistí, že třída má jen svou zodpovědnost, a všechny požadované detaily nesouvisející s jeho prací jsou delegovány do závislostí. SL toto nesplňuje, protože třída ještě navíc musí řešit získání těch závislostí.

S továrnami na řešení on-demand vytváření závislostí v DIC jsem se setkal i v jiných jazycích (C#, Rust, Java). Nette je v tomto zajímavé spíš tím, že si umí ty továrny vymejšlet sám.

Každopádně pokud máte nějaký neotřelý způsob, jak dodat závislosti objektu, rád se nechám poučit.

> Ne, článek od Davida nepopisuje ani nepoužívá vzor repository. Návrhový vzor repository řeší jak ukládat, případně načítat entity. Davidův článek popisuje jak poskládat instanci a jak jí dodat závislosti.

Pouziva "faktory" na vytiahnutie veci z databazy. To je Repozitory. Ja factory povazujem za factory, ked jeho vystup zavisi len na vstupe alebo konstruktore.

>Ne, DI neporušuje SRP, naopak. Je důkladnou snahou o jeho dodržení. DI zajistí, že třída má jen svou zodpovědnost, a všechny požadované detaily nesouvisející s jeho prací jsou delegovány do závislostí. SL toto nesplňuje, protože třída ještě navíc musí řešit získání těch závislostí.

To ste ma nepochopil. Ja som vravel, ze velky pocet zavislosti pri pouziti DI je dobra indikacia, ze objekt porusuje SRP. Samotne DI pomaha dodrzaniu SRP, ved oba su sucastou SOLID.

Používá "factory" na on-demand vytvoření instance. Nenechte se zmást, on tam používá pojmenování NecoNecoFactory protože se to chová jako továrna. Jestli to odpovídá nebo neodpovídá definici vzoru factory pod GoF, je nesouvisející.

Kouknul jsem se znovu, a on tam nikde žádné věci z databáze nevytahuje. Ne, že by to snad nešlo, mohla by to být dobrá divočina, ale už by to šlo nad rámec definice "Továrna je třída, která vyrábí a konfiguruje objekty.". Takže to vaši definici repozitory nesplňuje.

> velky pocet zavislosti pri pouziti DI je dobra indikacia, ze objekt porusuje SRP. Samotne DI pomaha dodrzaniu SRP,
Ah, ano, napsal jste to do závorky. Já jsme reagoval na větu "V tomto pripade nutnost pouzitia "tovarnicky" znamena, ze chyba je o uroven vyssie a objekt porusuje SRP.". Továrničky neřeší problém mnoha závislostí. Takže tato výtka je lichá.

Ale určitě stojí za to zdůraznit, že v protikladu k SL, (který jak to vypadá propaguje php-jet) tak DI právě zčitelňuje, že ta třída má nějak podezřele mnoho závislostí. Programátor to má stále před očima a opakovaně může zhodnotit, zda jsou nutné.

Vypadá to, že vaše obvinění s toho, že PHP comunita v tom má guláš není tak horké, jak se to servírovalo :-)