Ajaja, tohle se četlo fakt špatně. Předem se omlouvám za tentokrát trochu konfrontačnější tón, ale pokud je článek psaný stylem "všichni ostatní to dělají blbě, správně je to takhle po mém", a přitom obsahuje tolik nesmyslů, polopravd a nelogičností, tak to bohužel jinak nejde.
První část nedává smysl vůbec. Tváří se, že vysvětluje, proč je DI špatně, ale pak místo toho popisuje, proč je dobré používat jasně definovaný interface bez nutnosti vědět, jaká je za ním implementace. Což je samozřejmě pravda, ale taky je to přesně to, s čím DI pomáhá. Námitka, že dependence se použije jenom někdy a tudíž nemá smysl ji předávat v konstruktoru, souvisí s velmi častým antipatternem, který se hojně vyskytuje nejen v Jetu, ale i ve všech ostatních programech používajícíh ORM na bázi Active Record, a tím je God Object (a s tím spojené nedodržování SRP, jak už bylo zmíněno v jiném komentáři). Představa, že pokud něco v e-shopu souvisí s produktem, tak to musí být v třídě Product, je zhoubná, ústí v třídu Product s několika tisíci řádky, která dělá úplně všechno (viz např. https://github.com/redmine/redmine/blob/master/app/models/issue.rb - bohužel je to Ruby). Ano, v takové třídě se pak DI používá špatně, ale není to chyba DI, je to chyba špatně navržené třídy Product.
Zbytek článku už jen popisuje DI "po Laravelovsku", kde se místo zřejmého předání závislostí volají statické settery a gettery, což je věc, kterou na něm kritizuje spousta lidí (a právem). V jednoduchém jazyce jako je PHP, který nemusí řešit věci jako souběžné zpracování více requestů, to jakž takž funguje. Zkuste si ale něco takového napsat třeba v Javě a začnete potřebovat další rovnáky na ohýbáky jako ThreadLocal. Tudy prostě cesta nevede.
Přečteno 20 803×
Přečteno 18 653×
Přečteno 17 848×
Přečteno 17 602×
Přečteno 16 329×