Vlákno názorů ke článku PHP Jet - Dependency Injection, továrny a tak dále od Jan Judas - Ajaja, tohle se četlo fakt špatně. Předem se...

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.

Ked uz ten konfrontacny ton, nie je ziadne tajomstvo ze programatorov ktory su schopny dekompozice problemu a jeho optimalneho riesenia v ramci OOP je tak 5 az 10%, ostatok su lopaty. Teda ziadne ja to robim spravne a vy ostatny to robite blbo. A naopak to ze sa pravidelne niektore veci riesia v rozpore OOP, neznamena ze je to spravne, len je to lacne a pricetneho architekta to ani nevidelo. OOP ma totiz aj jednu zaludnost, analyza a navrh musi byt hotovy este pred tym nez sa to zacne realizovat.