Vlákno názorů ke článku PHP Jet - Dependency Injection, továrny a tak dále od RS - Další problém který vnímám je ze autor si...
-
Další problém který vnímám je ze autor si zjednodusil praci myslenkovou operaci ze zmeny se aplikuji na cely projekt:
```
Na jednom z projektů potřebujete do vrstvy nahrání a ukládání instance entity přidat keš. Třeba Redis. A potřebujete to aplikovat na celý projekt.
```okud opravdu mame v projektu vzdy jen jeden pristup tak to funguje hezky ale co kdyz v pulce aplikace potrebuji naky pristup a v druhe jiny pristup? co kdyz pul aplikace potrebuje naky logger a druha pulka jiny? tam zacneme brutalne selhavat a jsme v rozporu s tim co autor pise:
```
Pokud netvoříme marketingovou landing page s životností pár týdnů, tak je třeba stále myslet na budoucnost. Myslet pouze „na teď“ je jeden z velkých programátorských hříchů.
```Ja to nemyslim konfrontacne je pravda ze autorovo reseni ma sve vyhody a za cenu jistych omezeni je schopen dosahnout vetsi produktivity ale jakmile na tyto omezeni narazi tak bude muset delat spoustu ustupku a kod se stane necitelnym... (coz nemusi byt nutne problem ne kazdy programuje alzu / heureku / amazon) nicmene je treba na tyto problemy upozornit a prezentovat je jako problemy a ne jak vyhodu.
-
Předváděl mi kamoš svůj "životní" projekt. Bylo to něco z podobného ranku - univerzální apka s administrací a vůbec brutálně vymazlená. Žásnul jsem, kolik funkcionality dokázal v jednom člověku vytvořit.
Celé to měl postavené na dost svérázných principech (ke všemu se choval jako k mysql databázi, i k souborům). Na druhou stranu to prezentoval jako svůj "styl" a navíc to měl všechno velmi dobře promyšlené. Má můj respekt.
php-jet je bohužel prezentován jako něco nového, vyzrálého, něco co netrpí neduhy stávajících řešení. Což ale autor nedokáže dobře obhájit. V případě toho článku se mu to dokonce nedaří vůbec.
-
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/service/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.
-
Ještě jsem kouknul na ten odkazovaný článek ohledně DI v Nette - musím souhlasit, že to taky není dobré řešení DI, bo přináší další řadu problémů, které souvisí s neoddělením dat od procesu a navíc postrádá abstrakci (což mohlo být jen zjednodušení). Motivaci vyřešit jinak tedy chápu, ale výsledek je diskutabilní. Běžným současným řešením je plná separace dat a repository a repository vkládaná přes DI jako závislost do relevantních (nedatových) komponent.
-
Nette článek mě příjemně překvapil. Jako popis problémů, které DI řeší, pro někoho, kdo ho vůbec nezná, je to super. Beru to tak, že diskuze o tom, jestli je Active Record špatný pattern, byla nad rámec toho, co chtěl článek ilustrovat.
Separace dat od věcí, co s nimi pracujou, zatím podle mě v PHP moc rozšířená není, částečně asi i díky jeho jednovláknovosti - v takovém prostředí člověku projdou horší zvěrstva než třeba v té Javě a ani někdy není poznat, že to vlastně není správně. S příchodem readonly tříd v PHP 8.2 by se to snad mohlo trochu zlepšit (bude jednodušší vytvořit ty třídy, co drží data).
