Jet v akci - mezinárodní e-shop za 4 hodiny - 5. díl

Když se dívám na ten kód, nechtěl bych být zákazníkem, který si to koupí.

Bohužel musím souhlasit, Jet jsem si stáhl k sobě a prošel zběžně kód, protože mne zajímaly hlavně jak se řeší závislosti mezi komponenty. Na první pohled mne zaujal velký výskyt traits, tak jsem je začal blíže zkoumat. No, možná se pletu (doufám, že ano), ale autor traity používá jako virtuální dělení tříd na menší celky. Viz. např. https://github.com/mirekmarek/php-jet/blob/master/library/Jet/MVC/Page.php - zde je třída MVC_Page, která je složenina 13 (!) traits. Aha, takže pak opravdu nemusím řešit žadné DI apod., protože to prostě napíšu jako traity a ty pak všechny "naperu" do jedné třídy. Takže pokud by PHP traity nemělo (a to až do verze 5.4), ta třída by měla nekolik tisíc řádek. Sry, ale tohle na mne nepůsobí jako moderní PHP8 FW.

A k čemu podle Vás traity jsou?
Jedno z jejich určení je právě to, aby bylo možné potenciálně velkou třídu rozdělit ma menší celky.

Závislosti se řeší tak jak se v OOP řešit mají. Tedy jsou definována rozhraní (v podobě rozhraní a abstraktních tříd - tam kde je to vhodné) a dále pomocí využití konceptu DI, tak kde je to vhodné a tak jak se to dělat má.

Přemýšlím, jak by jste navrhl třídy Vy.
Patrně by jste rozdělil jednu entity na dejme tomu 14 tříd.
Ona teda zrovna tato entita již několika třídami tvořena je, ale by by jste to porcoval dál na další skutečné třídy ...
Místo traitu (tedy neúplné třídy, ale také třídy) by jste měl pouze jinou, samostatnou, která by se musela nějak instancovat. To znamená další běhovou režii, další složitost v systému.
Máte potucha co přesně se děje, když se v PHP instancuje třída, respektive jako technickou režii by mělo to vše okolo?
Teď myslím co se děje na úrovni paměti, procestoru, ... Prostě jakou to má běhovou režii.
Byl by jste spokojený že máte X tříd a ukojilo by to něčí obsedantní myšlení.

Ale faktický přínos? Veškerý žádný. Ba naopak by to zbytečně spotřebovávalo prostředky.

Jako vše v technicke, tak i při vývoji SW platí, že se stanoví kritéria, kterých má SW dosáhnout.

Zrovna tato třída tvoří extrémně důležitou a exponovanou věc. Musí to být především maximálně efektivní technicky.
To je vedle jasně daného rozhraní třídy jasné kritérium. Základní a nejdůležitější.
Další velice důležité kritérium je, aby si danou entitu mohl někdo upravit.
To lze díky OOP - máme dědičnost a přetěžování.
A dále mechanismus továren,. které zrovna na tomto místě Jet využívá.

Tedy mám základní entitu, která je optimalizovaná (protože to je u webové aplikace sakra důležité), má jasně dané rozhraní, které je jednoduché na použití. Dělá co má. A mám možnost si implementaci nabízenou FW nahradit svou implementací s tím, že díky dědičnosti mohu přetížit třeba jen pouze jednu metodu.
Dále mám řešené externí závislosti pomocí správného použití konceptu DI řešené opravu přes vkládání závislostí. Tedy např. cache je implementována jinde a pouze je do k tomu určeného kontejneru vkládán backend.

Ano, stejně by šlo vyřešit například i ukládání a čtení definic stránek. Ale návrh SW není o psaní kódu. Jsou to neustálá manažerská rozhodování, kdy se ptáte zda to má cenu.
No a například v otázce práce s čtením a zápisem definic jsem na základě testů dospěl k závěru, že nemá smysl tento přístup volit, protože by to znamenalo sice malou, ale přece jen technickou režii, která se kumuluje.
Ovšem pokročilý vývojář samozřejmě chápe koncepty OOP, tedy i dědičnost a přetěžování a má tak snadno možnost si v rámci entity dělat vlastně co potřebuje.

Tak se přemýšlí o návrhu SW:
- stanovování kritérií a cílů
- jejich řešení
- neustále porovnávání nákladů a přínosů

Obsedantní potřeby, či posedlosti kohokoliv nejsou žádné měřitelné kritérium.

Prostě a jednoduše: Nikdo vám za nějaké subjektivní dojmologie neplatí. Vůbec nikdo.
Zákazníka znajímá:
- Kdy to dostane
- Kolik zaplatí
- Jestli to bude fungovat dlouho a spolehlivě
- Jestli bude možné dlouhodobě dál realizovat co potřebuje

A to splňuji naprosto perfektně. Tím jsem si jistý :-)
Toho kdo nás platí nezajímají žádné řeči a "dojmologie".
Zákazníka zajímá a bude čím dál více zajímat zda uspokojíme jeho potřeby. Našim řečem nikdo z nich stejně nerozumí a nezajímá je to.
Čísla, čísla a peníze. To svět zajímá.

A dohadovat se o subjektivních věcech jde přímo proti tomu. Dokažte mi objektivně a měřitelně že to jde udělat lépe.
Udělejte rozvahu, která obstojí před tím kdo sedí na penězích a která zároveň plně všechna daná technická kritéria.
Dokažte mi to a já Jet předělám :-)

Můžu někde vidět váš kód? Ukážete mi jak efektivně pracujete vy? Rád se poučím.