Postřehy ohledně architektury JavaScriptu

[Ivan Nový]

Inb4 vzory su cargokult, som zvedavy, kto to napise

Vzory jsou to cargo z cargocultu.

Vzor bez reálné funkce na úrovni modelovaného systému je samozřejmě taky cargo kult. Vypadá to dobře, ale nefunguje to, poznávací znak cargo kultu.

[Reklama]

[Ivan Nový]

Inb4 vzory su cargokult, som zvedavy, kto to napise

Vzory jsou to cargo z cargocultu.

Když můžete asociativním polem implementovat strukturu, můžete strukturu implementovat i objektem, na tom není nic mimořádného. Pokud vám šlo o toto.

[SB]

...takže i když potřebujeme vlastně jen obyčejný field, ke kterému ale potřebujeme hlídat přístup, tak nás to nutí vytvářet všude gettery a settery jen z toho důvodu, co kdybychom někdy v budoucnu potřebovali upravit vnitřní chování - což je samozřejně regulérní důvod...

To je samozřejmě regulerní důvod, např. já, když dělám přístupovou metodu pro zápis informace, tak tam skoro jistě bude uvědomění pozorovatelů o změně objektu (návrhový vzor Pozorovatel).

...Tedy jinak řečeno, gettery/settery jsou vynucenej syntaktickej cukr, který by nebyl potřeba, když by jazyk nebyl tak blbej...

Osobně si myslím, že vznikly jako vlezdop-r-d-e-lismus céčkařům, které bylo potřeba dostat na Javu, aby si mohli pořád psát to svoje rovnítko.

A do třetice, programátoři se prostě naučili používat gettery a settery a tak nějak to bez dalšího přemejšlení převzali, a považují to za vrchol OOP. Mám čerstvou zkušenost z aktuální práce, kde se prostě konstruktory nedělali. Na sdílení kódu používají jen dědičnost. Všechny objekty vytváří skrze settery...

Všimnul jsem si, že některé vlastnosti jazyků (v Javě serializace, v jiných frameworcích persistence) vyžadují, aby objekt měl konstruktor bez parametrů, kdy jej vytvoří a nějak nabouchají zvenku (když k tomu rovnou nechtějí "settery" pro všechny položky)  - osobně si myslím, že je to hodně špatně.

[SB]

To víš ty, to vím já, dokonce i Kit to ví, ale někteří si to nemyslí: https://forum.root.cz/index.php?topic=13741.msg176803#msg176803

Presne tak, nemyslim si to. Objekt by mal byt validny v case, ked je potrebne, aby bol validny.

Taky se to tak dá dělat, ale vyrábíte si problém navíc, který dřív nebo později neukočírujete. Máte v takových objektech mechanismus, který zajišťuje, že např. objekt neodpovídá, když má neplatný stav? 1. Nejspíše nemáte. 2. Máte - je to další aparát navíc. Oboje je špatně.

[SB]

no tak asi žádná metoda objektu by ho neměl uvést do nevalidního stavu, ne?

Může. Např u objektu osoba můžu mít požadavek na minimální délku jména ... tohle omezení / validace doménového modelu existuje vně objektu, takže za určitého kontextu je objekt v nevalidním stavu.

Buďto je to požadavek objektu - pak je ověření v objektu. Nebo je to obecnější požadavek jinde - pak musí osoba využít delegováním funkcionality jiného objektu. Nebo je to speciální požadavek jen v některých částech systému - pak se osoby netýká a řeší se až při použití jména jinde.
Nikde tady není důvod, proč mít v objektu dočasně chybný údaj.

[Reklama]

[SB]

takže metody, které vracejí hodnoty, které jsou funkcí stavu objektu jsou špatně?

Určitě a špatně jsou proto, že vrací vnitřní stav objektu, a nevrací obecný a mnohdy jen virtuální stav systému. Objekty jsou od toho aby modelovaly systém, tedy na veřejné úrovni mají implementovat jen vlastnosti systému a ne nějaké pomocné atributy a stavy, ty mají zůstat skryty v objektu. Proto se taky objekty vytváří, že.

Například, když máte objekt faktury, tak vás na tom objektu může zajímat adresa dodavatele a odběratele, ale už by neměl být zveřejněn model, či iterátor, kterým je získáváte.

...Ale to je chyba, protože pokud ho někde použijete, v jiném objektu, tak vytvoříte závislost, kterou budete muset udržovat. Navíc tuto závislost těžko odhalíte, když se projeví jen zápisem $invoice->getModel()->getDeliveryAddress($id)

Ještě horší případ nastane, když vám někde někdo pomocí setteru setModel, nastaví jiný model než jaký očekáváte.

Motáme se pořád dokola:

Objekt by neměl mít vlastnost (stav, ať tu nedojde k nedorozumění, každý zprasený jazyk si pod tím představuje něco jiného) public, protože tím zcela ztrácí kontrolu nad ním, už i jenom kvůli tomu blbému Pozorovateli. Na tomhle se určitě všichni shodneme. Smalltalk to řeší koncepčně a jednoduše - všechny stavy jsou zvenku neviditelné.

Pak přicházejí přístupové metody - je čistě na návrháři, co vytrousí ven a co ne!!! Určitě to neznamená, že každá vlastnost (stav) bude mít getter a setter!!!

Když použijete kopii (či např. jen popis) unikátní adresy, jak potom např. zjistíte, že 2 firmy mají stejnou adresu? Porovnáním hodnot??? No je trochu prasárna, ne? Proto mají objekty identity a s nimi se tak pracuje. Jejich vzájemné závislosti jsou v obchodním systému zcela běžné.
Co je to "$invoice->getModel()" Jaký model?

[SB]

Jedine immutable objekty su stale validne. Tzn, po kazdej zmene, stary zahodit a vytvorit novy...

Jo, to je supr, má to ale drobnou vadu - v systému s potřebou unikátních objektů je to k ničemu.

[Ivan Nový]

takže metody, které vracejí hodnoty, které jsou funkcí stavu objektu jsou špatně?

Určitě a špatně jsou proto, že vrací vnitřní stav objektu, a nevrací obecný a mnohdy jen virtuální stav systému. Objekty jsou od toho aby modelovaly systém, tedy na veřejné úrovni mají implementovat jen vlastnosti systému a ne nějaké pomocné atributy a stavy, ty mají zůstat skryty v objektu. Proto se taky objekty vytváří, že.

Například, když máte objekt faktury, tak vás na tom objektu může zajímat adresa dodavatele a odběratele, ale už by neměl být zveřejněn model, či iterátor, kterým je získáváte.

...Ale to je chyba, protože pokud ho někde použijete, v jiném objektu, tak vytvoříte závislost, kterou budete muset udržovat. Navíc tuto závislost těžko odhalíte, když se projeví jen zápisem $invoice->getModel()->getDeliveryAddress($id)

Ještě horší případ nastane, když vám někde někdo pomocí setteru setModel, nastaví jiný model než jaký očekáváte.

Motáme se pořád dokola:

Objekt by neměl mít vlastnost (stav, ať tu nedojde k nedorozumění, každý zprasený jazyk si pod tím představuje něco jiného) public, protože tím zcela ztrácí kontrolu nad ním, už i jenom kvůli tomu blbému Pozorovateli. Na tomhle se určitě všichni shodneme. Smalltalk to řeší koncepčně a jednoduše - všechny stavy jsou zvenku neviditelné.

Pak přicházejí přístupové metody - je čistě na návrháři, co vytrousí ven a co ne!!! Určitě to neznamená, že každá vlastnost (stav) bude mít getter a setter!!!

Když použijete kopii (či např. jen popis) unikátní adresy, jak potom např. zjistíte, že 2 firmy mají stejnou adresu? Porovnáním hodnot??? No je trochu prasárna, ne? Proto mají objekty identity a s nimi se tak pracuje. Jejich vzájemné závislosti jsou v obchodním systému zcela běžné.
Co je to "$invoice->getModel()" Jaký model?

Jaksi si nedovedu představit situaci, kdy by bylo třeba zjišťovat, že dvě firmy mají stejnou adresu. Pokud ji mít nemohou, otestuje se to zápisem do db a vyhozením výjimky při editaci adresy. Ovšem připustíte-li gettery a settery, pak jistě takovou situaci najdete a to je právě ta chyba. Budete prostě v tu ránu uvažovat jinak. Práci vám usnadní, ale objekt se stane zárodkem závislostí na jiných objektech a implementační detaily se přesunou na vyšší úroveň. Což v budoucnosti znesnadňuje modifikace.

[balki]

Inb4 vzory su cargokult, som zvedavy, kto to napise

Vzory jsou to cargo z cargocultu.

Vzor bez reálné funkce na úrovni modelovaného systému je samozřejmě taky cargo kult. Vypadá to dobře, ale nefunguje to, poznávací znak cargo kultu.

Preto su k tym vzorom kilometrove vysvetlenia v serioznej literature. Ked sa clovek so vzorom dostatocne zoznami, vie ho vhodne pouzit v kontexte a vytvorit si vlastnu implementaciu. Ale joudovia si radsej citaju prekrutene clanky na zdrojaku, ktore pisu manazeri  web developeri z firiem.

[SB]

Jaksi si nedovedu představit situaci, kdy by bylo třeba zjišťovat, že dvě firmy mají stejnou adresu...

Např. v aplikaci pro pošťáka, který potřebuje vyhledat nejvýhodnější trasu pro doručení zásilek. Ale to je úplně jedno, unikátní objekty a test na identitu se používá běžně, je to objektový systém!

...Pokud ji mít nemohou, otestuje se to zápisem do db a vyhozením výjimky při editaci adresy...

Tohle prasečí řešení jste určitě nemyslel vážně, budu dělat, že jsem to neviděl.

...Ovšem připustíte-li gettery a settery, pak jistě takovou situaci najdete a to je právě ta chyba. Budete prostě v tu ránu uvažovat jinak...

Ano, objektově.

...objekt se stane zárodkem závislostí na jiných objektech...

Opět: Objekty jsou na sobě závislé, je to objektový systém!

...a implementační detaily se přesunou na vyšší úroveň. Což v budoucnosti znesnadňuje modifikace.

Naopak, adresa bude uvnitř objektu, aniž by mě vůbec zajímalo, jak to vypadá vevnitř, stačí mi vědět, že to prostě je adresa. Test identity je pak triviální a neomylný, další výstupy (např. tisk) řeší objekt na požadavek sám (např. asPrintable ap.).

[v]

Jaksi si nedovedu představit situaci, kdy by bylo třeba zjišťovat, že dvě firmy mají stejnou adresu...

Např. v aplikaci pro pošťáka, který potřebuje vyhledat nejvýhodnější trasu pro doručení zásilek. Ale to je úplně jedno, unikátní objekty a test na identitu se používá běžně, je to objektový systém!

takže při změně adresy firmy zjišťujete jestli ji nemá i jiná firma? to nezní dvakrát prakticky a pro pošťáka taky moc ne, úplně stejná adresa IMHO nehraje takovou roli jako geografická blízkost, třeba sousední barák

[Wavelet]

no tak asi žádná metoda objektu by ho neměl uvést do nevalidního stavu, ne?

Může. Např u objektu osoba můžu mít požadavek na minimální délku jména ... tohle omezení / validace doménového modelu existuje vně objektu, takže za určitého kontextu je objekt v nevalidním stavu.

Buďto je to požadavek objektu - pak je ověření v objektu. Nebo je to obecnější požadavek jinde - pak musí osoba využít delegováním funkcionality jiného objektu. Nebo je to speciální požadavek jen v některých částech systému - pak se osoby netýká a řeší se až při použití jména jinde.
Nikde tady není důvod, proč mít v objektu dočasně chybný údaj.

V Ui vrstvě může být objekt v nevalidním stavu, jen uživatele nepustím dál pracovat s doménovým modelem.

[balki]

Jedine immutable objekty su stale validne. Tzn, po kazdej zmene, stary zahodit a vytvorit novy...

Jo, to je supr, má to ale drobnou vadu - v systému s potřebou unikátních objektů je to k ničemu.

Neviem posudit, dajte prosim priklad Urcite vymyslim/najdem  best practice  zhovadilost, ako sa to da obist.

[BoneFlute]

Java není tak blbá, ale absence properties má nutit k více objektovému myšlení, kdy objekty mezi sebou komunikují jen a výhradně pomocí zpráv.

Getter/setter jako degenerovaná zpráva (protože je ve své podstatě servisní, souvisí s objeketem, nikoliv s tím, co objekt modeluje) je pak pronikání procedurálního přístupu do OOP.

Hodně častý je prostě jednoduchý objekt Person {name: String, surname: String}. Na tom toho moc nevymyslíš.

K čemu takový objekt potřebujete? To není OOP přístup, ale procedurální. Pochopil bych objekt Point(x,y) s metodami move, rotate, colorize, increase, decrease, hide. Ale jakou činnost chcete provádět se jménem? V realitě jedině print.

Hmm, to zní zajímavě.

Předpokládejme hru, ve které figuruje panáček a pomeranč a pomerančovník. Úkolem hráče je pravidelně krmit panáčka pomerančem. Přičemž pomeranč může panáček sníst, nebo jej uložit do batohu na pozdějc.

Jak by se to řešilo čistě OOP?

Já bych to čistě naivně řešil tak, že by se panáčkově metodě "jez", předal objekt "pomeranč". Ale nedaří se mi se naladit na tvůj způsob. Páč si nedovedu představit u pomeranče metodu být jezen. Vždycky se mi to roypane na něco jako: "extrahuj cukr".

Poznámka: toto není ironie

[BoneFlute]

Pokud ji mít nemohou, otestuje se to zápisem do db a vyhozením výjimky při editaci adresy.

Si děláš srandu? To jako kůli tomu, abych mohl programovat objektově potřebuji databázi?!