Přijde mi, že vaše definice a představa DI je nějaká divná, a možná to je důvod veliké diskuze pod minulým článkem.
Dependency Injection znamená: Pokud třída potřebuje volat něco na jiné třídě/interfacu, musí si ho nechat předat v konstruktoru/parametru metody, místo toho aby si instanci vyráběla sama. Nic víc, nic míň. Nijak nesouvisí s tím, kolik má ta dependence implementací, jestli je to interface nebo třída, ani ničím jiným.
Díky tomu je na první pohled patrné, jaké dependence třída má. Nejsou v těle jejích metod schované žádně Něco::getInstance()
nebo jiná statická volání, která pokoutně získávají další dependence. Toto se velice hodí například v unit testech, ale pokud si dobře pamatuju jeden z prvních dílů seriálu, tak ty taky neuznáváte?
Například když z třídy vyřezávám část funkcionality do nové třídy v rámci refaktoringu, tak novou metodu neudělám static, i když bych třeba z pohodlnosti mohl. Rovnou novou dependenci "přiznám" a až ta nová třída sama začne potřebovat svoje dependence, nebudu muset přepisovat všechna místa, kde jsem volal NováTřída::nováMetoda
, ale jen jedno místo, kde se vytváří instance té nové i původní třídy. Což může být konfigurace nějakého DI kontejneru, ale taky naprosto obyčejný PHP kód plný new
- kód tzv. "dependency wiringu". Tohle místo může vypadat poměrně ošklivě a je to daň za použití DI, ale je to daň jediná a velice se to v dlouhodobém horizontu vyplatí. Je samozřejmě možné použít různé DI kontejnery, ale z mé zkušenosti to často ani není moc potřeba.
Přečteno 19 727×
Přečteno 17 665×
Přečteno 17 176×
Přečteno 16 701×
Přečteno 15 348×