Vlákno názorů ke článku Dependency Injection ještě jednou :-) od BoneFlute - Děkuji za článek. Pokusím se uvést na pravou míru...

Děkuji za článek.

Pokusím se uvést na pravou míru pár mýtů.

V části: "K čemu je koncept DI dobrý?"

1/ DI nevznikl jako koncept pro vytváření kontainerů.

2/ Ve skutečnosti váš příklad s kontainerem je nesprávný. Kontainer jak ho popisujete vlastně neřeší vůbec žádný problém. Pokud potřebuju nějaký adapter, tak ho zařídím aby měl stejné rozhraní jako ho požaduje služba. Nebudu na to vytvářet nějaký kontainer, až který by mi vynucoval nějaké rozhraní. Pěkný příklad zbytečného kontaineru je váš příklad logování. Kontainer, dle významu toho slova, se obvykle používá ve významu kdy seskupíte několik "logik" a adaptujete je tak aby ve výsledku poskytovali požadované rozhraní. Je-li těch "logik" jen jedna, tak tomu obvykle říkáme Wraper.

3/ Píšete: "Komponenty aplikace vědí jak onu servisní komponentu / službu volat a jak ji použít." - toto je vzor Service Locator nikoliv Dependency Injection. Praxe nám ukazuje, že SL je antipattern. Bezpochyby existují extrémě výjimečné situace, kdy může SL dobře posloužit. Ale na žádnou si nevzpomínám.

4/ Tedy závěrečné shrnutí je nesprávné, protože nepopisuje DI ale SL, a protože popisujete zbytečné používání kontaineru.

V části: "K čemu koncept DI není dobrý?"

5/ Zde není co vytknout. Jedná se o obecné principy se kterými asi všichni souhlasíme. Zřejmě vám to dávalo smysl v nějakém konceptu. Jediné, co by se tomu dalo vytknout, že to vlastně neodpovídá na otázku.

V části: "Proč není dobré používat DI všude?"

6/ Píšete "Přináší to do aplikace další složitost, která však není k ničemu reálně užitečná.". Nepravda. Praxe nám ukázala, že DI je velice zdravý koncept, který zjednodušuje aplikaci a zčitelňuje ji.

7/ Píšete: "Zatěžuje to vývojáře a odvádí jej to od řešení podstaty věci.". Naopak. Tím, že vývojář nemusí řešit kde sebere závislosti může se více soustředit na gró svého problému.

8/ Píšete: "Pokud používáte framework s nějakými konfigurovatelnými kontejnery a ještě ke všemu v nějakém nestandardním datovém formátu, tak vám to objektivně sníží technickou efektivitu aplikace." - Praxe ukazuje opak.

9/ Píšete: "Přemýšleli jsme někdy nad tím kolik paměti, I/O operací a instrukcí procesoru „sežere“ to, že se načítá konfigurace?" Ano, přemýšleli. Pár drobných to jistě bude. Praxe nám ukazuje, kolik zbytečného kódu je vyhozeno po té, kdy architektura začne respektovat DI.

10/ Píšete: "A nedej bože když se musí nějak parsovat a případně řešit režijní operace s keší?" - Snažíte se vyvolat dojem, jako kdyby to bylo nějak strašně moc. Můžete to podložit nějakými čísly? Mé zkušenost je na hraně měřitelnosti.

11/ Píšete: "A používání různých DI kontejnerů a dalších věcí, kde s růstem velikosti aplikace úměrně narůstá i náročnost a spotřeba zdrojů systému, jde přímo proti tomu. A to je problém. V online aplikaci dosti podstatný až řekl bych zásadní problém." Můžete to něčím podložit? Má praxe ukazuje, že toto není ten problém. Má praxe ukazuje, že problém je používání překonaných konceptů. Ani logicky to není pravda. DI kontainery jsou relativné levná záležitest Není důvod si myslet, že když to napíše programátor bude to lepší, než když se vygeneruje kontainer.

V části: "Závěr"

12/ Píšete: "DI je super koncept, který má své nezastupitelné místo." Zde jen doplním, že je vhodné se s tímto konceptem dobře seznámit. Vy nepopisujete to, co si pod tím pojmem představují ostatní. Ne, DI není Service Locator a už vůbec nijak nesouvisí s kontainery.

Což má ve výsledku dopad na zvláštní zmatení, kdy vy slovy kritizujete DI, ve skutečnosti kritizujete SL (a DIC a asi něco dalšího co jsem úplně nepochopil), a v kódu používáte (a jste po právu kritizován) SL.

13/ Dogmata jsou bez pochyby zlo, v tom se shodnem. Já ale DI propaguju proto, protože to má měřitelné výsledky, a od SL odrazuji, protože to má měřitelné škody. A samozřejmě, někdy pomůže něco naprasit, jistě. Ale stejně jako to funguje v Jazzu, musíte se nejdřív naučit hrát čistě, abyste mohl hrát falešně.

Děkuji za reakci.

Teď bych mohl rozebírat Vaše "vyvracení mýtů".

Ale taková diskuze by nebyla efektivní.

Porosím Vás o jinou věc:
Prosím sepište mi případovou studii z reálné praxe, třeba formou blogu, na které dokážete v jaké situaci, na jakém projektu a za jakých podmínek byl/nebyl daný postup správný/špatný a kde to dokážete zcela konkrétně kvantifikovat a podložit testy. Tedy bude to chtít dva podobné projekty stejného charakteru realizované dvěma přístupy a ty pak porovnané na základě reportů odpracovaného času, výkonnostních testů a aplikace a pak také reportů času servisních prací během životního cyklu aplikace.

To mě zajímá.

A vraťme se na začátek. Já reaguji na to, že kolega David Grudl v Nette, ale i jiních a jinde šíří myšlenky, které považuji na základě reálných zkušeností za mylné a troufám si tvrdit škodlivé. Škodlivé: používat něco všude, protože "hezký kód".

Vraťme se tedy k tomu na co reaguji a co vyvracím a to sem:
https://doc.nette.org/cs/dependency-injection/introduction

Prosím fakt mi sepište příipadovku z praxe na které je možné jednoznačně pomocí tvrdých dat čísel a reálných zkušeností dokázat, že uvedené je pravda a že to zvyšuje jak efektivitu vývoje, tak technickou efektivitu aplikace samotné.

Když půjdu obhajovat projekt před někým, kdo mi jej zaplatí, tak toho zadavatele budou zajímat pouze čísla a čísla vyjádřená ve financích. Ne slovíčkaření.

Dokažte mi tímto "cifršpiínským" stylem, že uvedené myšlenky jsou správné a přinesou objektivní a měřitelný benefit. To jest kolik to ušetří peněz jak při vývoji tak při provozu a kolik to ušetří systémových prostředků.

Velice rád si takovou případovku přečtu. A pokud v nerozporovatelných faktech dokáže že se pletu, tak to rád uznám a změním celé mé uvažování,.
Ostatně jako jsem to již udělal v jiných věcech.

Ale fakt chci čísla a fakta. Děkuji.

Například jako já zde vysvětluji a na číslech ukazuji, proč Jet nemá žádný NEON, YAML, či něco takového:

https://www.php-jet.net/doc/proc/proc-jet-pouziva-php-soubory-jako-uloziste-dat-a-zdroj-konfigurace

Tak takový článek, který podporuje tvrzení kolegy Grudla bych prosil. Pokud se pletu, rád bych to věděl.

Těším se na Váš článek!

Máte to nějaké pomotané. To vy tvrdíte, že vývoj bez DI je efektivnější, takže důkazní břemeno ja na vaší straně. Nenapadá mě jediný důvod, proč by BoneFlute měl povinnost vám vypracovávat jakési případové studie.

A k té konfiguraci v PHP: Ano, mít konfiguraci v PHP místo např. YAML je o něco efektivnější. Ale pokud nás až tolik zajímá rychlost, proč používáme tak neefektivní jazyk jako je PHP? Nebylo by lepší použít něco, kde se konfigurace načítá jednou za měsíc a ne stokrát za sekundu? Navíc tedy zcela opomíjíte nevýhodu konfigurace v PHP, a to, že se do takového souboru kromě konfigurace dá napsat naprosto cokoliv (a dřív nebo později to někdo udělá).

Tak ak mate konfiguraciu v PHP subore, tak je mozne ze sa bude nacitat aj menej casto ako raz za mesiac. Pretoze interpreter si ju ulozi do opcache a kedze bude volana pri kazdom starte scriptu (kazdy reqest sposobi novy start scriptu), takz tej opcache tak lahko nevypadne.

Ano mat v konfiguraciu v YAML je dobre koli prehladnosti, ale zaroven je dobre najneskor v pribehu CI vygenerovat prislusny PHP subor s konfiguraciou. Pretoze inak sa ten YAML parsuje stale dookola, miesto toho aby sa parsoval iba raz a tym klesa efektifita.

Schválně jsem nepsal "parsuje", ale "načítá", protože vím, že PHP kód se většinou cachuje. Tím "načítá" jsem myslel spíš třeba vyrábění instance a všechny ty ostatní věci, který cachovat nejdou.

Cachování naparsovanýho YAML configu za mě buď řeší framework (rozhodně by měl), nebo si to holt udělám ručně. Jasně, že parsovat YAML při každým requestu je sebevražda, ten formát je příšerně složitej. Ale generovat to už v průběhu CI je nějaký divný, zvlášť když ty konfigurační hodnoty jsou až v produkci (CI by produkční hesla do DB a podobný věci asi fakt znát neměl). V rámci deploye by to asi šlo.

Dělali jsme studii na jednom z nejvytíženějších webů v Čechách a bylo zajímavé že načítání konfigurace z ini souboru byli rychlejší než z php (navzdory opcache). Logiku to dávalo. Každopádně to jen dokazuje, že je třeba posoudit případ od případu.
S čímž samozřejmě souvisí, že potřebujete principy které vám půjdou na ruku - DI, a nebudou vás omezovat - SL.
Nic to nemění na skutečnosti, že vyměnit parsování čehokoliv na cokoliv jiného je banalita nestojící za zmíňku. Zajímá mě jak snadné nebo těžké je ti udělat. Ne zda je to v základním balení.

Víte, já si čtu vaši prezentaci a dělám si rešerši. UI máte vcelku pěkné. Vnitřnosti špatné.
Když by se mě někdo ptal, zda bych PHP-jet doporučil, tak nedoporučil. Mám svědomí.
Ale. Já vám nebudu dělat žádnou studii, protože by to bylo proti mému businessu. Živíme se tím, že dávám dohromady projekty postavené na špatných principech jako je právě PHP-jet a přepisuju je do těch správných. Dokavad mi budou platit mé hříšné peníze, dělám to dobře.
Takže za mě, jen tak dál :-)

Píšete “ Například jako já zde vysvětluji a na číslech ukazuji, proč Jet nemá žádný NEON, YAML, či něco takového:”
Chybí vám tam porovnání s ini. Zjistil by jste, ze je rychlejší jak PHP.
Chybí vám tam kolik stojí test na zjištění existence prekompilovaneho souboru neon do PHP a jak se to promítne do celkové ceny. Zjistil byste, ze je to nula nula prd.
Přebívá vám tam absolutně subjektivní porovnání výhod a nevýhod která nejsou vůbec ničím podložena.

Ta tvrdá data jsou ty tři čísla. Ale zbytek textu se opírá o velké množství dat které tam nejsou a tím pádem jsem nucen je označit za hrubě spekulativní.

Takže sečteno podrženo takhle se fakta a čísla nedělají. Nepoužitelné.