Odpověď na názor

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ě.