Názor ke článku PHP Jet - Dependency Injection, továrny a tak dále od kvr kvr - Ono to netrpí neduhy stávajících řešení, ale neduhy...

Ono to netrpí neduhy stávajících řešení, ale neduhy předchozích řešení. Někdo psal, že takhle se dělaly věci před deseti lety a neosvědčily se - to opravdu ne. První rozsáhle používané DI (EJB) je staré snad 25 let...

Ten přístup z článku defakto má DI, akorát jej řeší statickými metodami a proměnnými, místo, aby rozdělil objekty na data a factory/servi­ce/cokoliv. Což do jisté velikosti projektu bude fungovat a dokážu si představit, že může být skutečně i produktivnější (izolaci testů asi bude největší problém). Ale jakmile dojde na větší projekt nebo nedejbože dokonce projekty a myšlenky na reusability, různé proxy, interceptory, různé datasources, tak vítejte v pekle. Ano, v PHP to ještě možná bude trochu zvládnutelné s nějakými omezeními, ale v Java, kde jdou paralelně stovky až miliony requestů nebo v reactive frameworks střídají thready jak ponožky, to už opravdu nejde.

Trochu mi to připomíná, když jsem se před pár lety dohadoval v bývalé práci, jestli má být lokalizační framework postavený na statických metodách nebo na factory (bo DI znamená komplexitu v konstruktoru a field proměnné navíc). Nakonec vyhrál on, ale jenom dočasně - než tým nebyl schopen napsat ani unit testy (to šlo ještě částečně obejít přes PowerMockito) a použít řešení u prvního týmu, který měl potřebu customizace zdrojů dat. Takže jsme strávili další měsíc přepisováním na původní návrh postavený na factory a od té doby nasazení v mnoha specifických situacích bez jakéhokoliv zdržení.

Jako snaha pěkná, letmo jsem ten seriál sledoval. Asi každý jsme si tím vývojem prošli, ale tvrdit, že "já to dělám správně" je v tomto případě založeno na těžké neznalosti moderního software engineering.