Postřehy ohledně architektury JavaScriptu

[BoneFlute]

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.

To se mi nestává. U mě UI okno přebírá data od uživatele, validuje je, a snaží se z nich vytvořit objekt pro doménovou vrstvu. To UI okno se může do nevalidního stavu dostat leda tak, že bych se ho pokusil vytvořit bez odkazu na rodiče (což mu nedovolím konstruktorem). Ale kůli tomu, že user jako věk napíše "hodně" rozhodně nezpanikaří. Naopak. Přepne se do zcela validního stavu: "zadal jste chybnou hodnotu...".

[Reklama]

[SB]

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.

A není to pak extra objekt pro editaci v UI, pro který platí jiné podmínky?

[balki]

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

Vzor visitor nejak podobne funguje.  Nepouzivam ho, lebo mu uplne dobre nerozumiem, dokazil by som appku, kde by som to pouzil   "jezen" je trpny rod to sa mi nepaci. Skor "navstiv(dutinaUstni)".

[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.

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

2 smlouvy mají tutéž fyzickou osobu, v případě duplikátu osoby při změně jednoho z nich dojde okamžitě k nekonzistenci dat.

[balki]

To se mi nestává. U mě UI okno přebírá data od uživatele, validuje je, a snaží se z nich vytvořit objekt pro doménovou vrstvu. To UI okno se může do nevalidního stavu dostat leda tak, že bych se ho pokusil vytvořit bez odkazu na rodiče (což mu nedovolím konstruktorem). Ale kůli tomu, že user jako věk napíše "hodně" rozhodně nezpanikaří. Naopak. Přepne se do zcela validního stavu: "zadal jste chybnou hodnotu...".

Aha, takze existuje predsa okno v nevalidom stave. A potom zrazu sa prepne do validneho. Ale to je zle !!!11!!!! To se stat nesmi! To je pro lyny programatori. Gui cargo kult.

[Reklama]

[BoneFlute]

To se mi nestává. U mě UI okno přebírá data od uživatele, validuje je, a snaží se z nich vytvořit objekt pro doménovou vrstvu. To UI okno se může do nevalidního stavu dostat leda tak, že bych se ho pokusil vytvořit bez odkazu na rodiče (což mu nedovolím konstruktorem). Ale kůli tomu, že user jako věk napíše "hodně" rozhodně nezpanikaří. Naopak. Přepne se do zcela validního stavu: "zadal jste chybnou hodnotu...".

Aha, takze existuje predsa okno v nevalidom stave. A potom zrazu sa prepne do validneho. Ale to je zle !!!11!!!! To se stat nesmi! To je pro lyny programatori. Gui cargo kult.

Kdes' to vyčet'?

[Ivan Nový]

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

Kód: [Vybrat]


class Panacek
{
     function snez(pomeranc)
     {
           do {
              sousto = pomeranc.ukousni(rand(12))
           } while(sousto > 0)
     }
}

class Pomeranc
{
      private hmotnost = 1;

      function ukousni(apetit)
      {
            sousto = 0.9*(hmotnost/apetit);

            if (hmotnost > 0)
            {
                 hmotnost = hmotnost - sousto;
                 return sousto;
             }
            else
                 return 0;
      }
}


[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.

2 smlouvy mají tutéž fyzickou osobu, v případě duplikátu osoby při změně jednoho z nich dojde okamžitě k nekonzistenci dat.

Odhliadnem od toho, ze toto robi databaza.

Tak potom je nutne updatovat vsetky zmluvy, kde sa fyzicka osoba nachadza. (Samozrejme, treba si aj spravit snapshot zmluvy po podpisani aby sa na nej nemenil text)  To je snadne.

[Wavelet]

To se mi nestává. U mě UI okno přebírá data od uživatele, validuje je, a snaží se z nich vytvořit objekt pro doménovou vrstvu. To UI okno se může do nevalidního stavu dostat leda tak, že bych se ho pokusil vytvořit bez odkazu na rodiče (což mu nedovolím konstruktorem). Ale kůli tomu, že user jako věk napíše "hodně" rozhodně nezpanikaří. Naopak. Přepne se do zcela validního stavu: "zadal jste chybnou hodnotu...".

Aha, takze existuje predsa okno v nevalidom stave. A potom zrazu sa prepne do validneho. Ale to je zle !!!11!!!! To se stat nesmi! To je pro lyny programatori. Gui cargo kult.

Myslím že tak to nebylo myšleno. Prostě nevalidní objekty vůbec nevytvoří, protože má view napojen na doménový model a ten nemůže být v nevalidním stavu (ale i tom se občas diskutuje). View nemá v nevalidním stavu! View jen ukazuje co nevalidního si tam chtěl vložit.

[balki]

To se mi nestává. U mě UI okno přebírá data od uživatele, validuje je, a snaží se z nich vytvořit objekt pro doménovou vrstvu. To UI okno se může do nevalidního stavu dostat leda tak, že bych se ho pokusil vytvořit bez odkazu na rodiče (což mu nedovolím konstruktorem). Ale kůli tomu, že user jako věk napíše "hodně" rozhodně nezpanikaří. Naopak. Přepne se do zcela validního stavu: "zadal jste chybnou hodnotu...".

Aha, takze existuje predsa okno v nevalidom stave. A potom zrazu sa prepne do validneho. Ale to je zle !!!11!!!! To se stat nesmi! To je pro lyny programatori. Gui cargo kult.

Kdes' to vyčet'?

No jednoduche, je tam prehlaseny nevalidny stav za validny.  Sposobom "ved tam user nieco setne  a potom sa to zvaliduje". Za nieco podobne ste sa mi vysmievali.

[SB]

2 smlouvy mají tutéž fyzickou osobu, v případě duplikátu osoby při změně jednoho z nich dojde okamžitě k nekonzistenci dat.

Odhliadnem od toho, ze toto robi databaza.

Tak potom je nutne updatovat vsetky zmluvy, kde sa fyzicka osoba nachadza. (Samozrejme, treba si aj spravit snapshot zmluvy po podpisani aby sa na nej nemenil text)  To je snadne.

Databázi do toho nepleťte, to je vrstva řešící persistenci, ne výpočet, nehledě na to, že databázi ani mít nemusíte.

Takže byste musel dohledat (a nesplést se) všechny osoby nejen ve smlouvách, ale celkově v systému, a přepsat je. Zabere to místa a času jak kráva, přijdete o možnost sledovat změny osoby, ...  To asi nebude dobře.

[Wavelet]

To se mi nestává. U mě UI okno přebírá data od uživatele, validuje je, a snaží se z nich vytvořit objekt pro doménovou vrstvu. To UI okno se může do nevalidního stavu dostat leda tak, že bych se ho pokusil vytvořit bez odkazu na rodiče (což mu nedovolím konstruktorem). Ale kůli tomu, že user jako věk napíše "hodně" rozhodně nezpanikaří. Naopak. Přepne se do zcela validního stavu: "zadal jste chybnou hodnotu...".

Aha, takze existuje predsa okno v nevalidom stave. A potom zrazu sa prepne do validneho. Ale to je zle !!!11!!!! To se stat nesmi! To je pro lyny programatori. Gui cargo kult.

Kdes' to vyčet'?

No jednoduche, je tam prehlaseny nevalidny stav za validny.  Sposobom "ved tam user nieco setne  a potom sa to zvaliduje". Za nieco podobne ste sa mi vysmievali.

Nevím jestli tomu zcela rozumím... některý vstup se dá validovat až po tom, co to tam uživatel "setne" a potvrdí to. Pole s emailem umožňuje zapsat jakýkoliv text, nevím kdy tam uživatel zapíše zavináč a doménu. Jestli je vstup validní zjistím až po změně stavu -- odeslání, výstup z pole na jiný prvek... Ve view jsou potencionálně nevalidní data, ale view je v naprosto validním stavu.

[balki]

2 smlouvy mají tutéž fyzickou osobu, v případě duplikátu osoby při změně jednoho z nich dojde okamžitě k nekonzistenci dat.

Odhliadnem od toho, ze toto robi databaza.

Tak potom je nutne updatovat vsetky zmluvy, kde sa fyzicka osoba nachadza. (Samozrejme, treba si aj spravit snapshot zmluvy po podpisani aby sa na nej nemenil text)  To je snadne.

Databázi do toho nepleťte, to je vrstva řešící persistenci, ne výpočet, nehledě na to, že databázi ani mít nemusíte.

Takže byste musel dohledat (a nesplést se) všechny osoby nejen ve smlouvách, ale celkově v systému, a přepsat je. Zabere to místa a času jak kráva, přijdete o možnost sledovat změny osoby, ...  To asi nebude dobře.

Databázi do toho nepleťte, to je vrstva řešící persistenci, ne výpočet, nehledě na to, že databázi ani mít nemusíte.


Vsak som ani databazu to toho neplietol. "Odhliadnem od toho" - znamena, ze ten fakt nepouzijem. Koniec slovenskeho okienka.



Takže byste musel dohledat (a nesplést se) všechny osoby nejen ve smlouvách, ale celkově v systému, a přepsat je. Zabere to místa a času jak kráva, přijdete o možnost sledovat změny osoby, ...  To asi nebude dobře.


Uskutocnitelne to vsak je, aj ked je to "zabere mista a casu jak krava" . Nie je nutne prist o zmeny osoby. Osoba sa v systeme moze nachadzat v roznych verziach. Pricom ta s najnovsim identifikatorom (timestampom) bude aktualna.

[balki]

To se mi nestává. U mě UI okno přebírá data od uživatele, validuje je, a snaží se z nich vytvořit objekt pro doménovou vrstvu. To UI okno se může do nevalidního stavu dostat leda tak, že bych se ho pokusil vytvořit bez odkazu na rodiče (což mu nedovolím konstruktorem). Ale kůli tomu, že user jako věk napíše "hodně" rozhodně nezpanikaří. Naopak. Přepne se do zcela validního stavu: "zadal jste chybnou hodnotu...".

Aha, takze existuje predsa okno v nevalidom stave. A potom zrazu sa prepne do validneho. Ale to je zle !!!11!!!! To se stat nesmi! To je pro lyny programatori. Gui cargo kult.

Kdes' to vyčet'?

No jednoduche, je tam prehlaseny nevalidny stav za validny.  Sposobom "ved tam user nieco setne  a potom sa to zvaliduje". Za nieco podobne ste sa mi vysmievali.

Nevím jestli tomu zcela rozumím... některý vstup se dá validovat až po tom, co to tam uživatel "setne" a potvrdí to. Pole s emailem umožňuje zapsat jakýkoliv text, nevím kdy tam uživatel zapíše zavináč a doménu. Jestli je vstup validní zjistím až po změně stavu -- odeslání, výstup z pole na jiný prvek... Ve view jsou potencionálně nevalidní data, ale view je v naprosto validním stavu.

Oby som obcerstvil mne bolo vycitane, ze injektujem zavislosti cez settre a potom zavolam init metodu. Taky objekt sa nachadza potom vo validnom stave "nenainicializovany". Az potom, ako je korektne "inicializovany", poskytne sa systemu na pracu.  Teraz som to povedal po boneflutovsky. So ziadnymi nevalidnymi objektami sa v systeme nepracuje, ale aj tak mu to dalo mandat ma zosmiesnovat.

[BoneFlute]

To se mi nestává. U mě UI okno přebírá data od uživatele, validuje je, a snaží se z nich vytvořit objekt pro doménovou vrstvu. To UI okno se může do nevalidního stavu dostat leda tak, že bych se ho pokusil vytvořit bez odkazu na rodiče (což mu nedovolím konstruktorem). Ale kůli tomu, že user jako věk napíše "hodně" rozhodně nezpanikaří. Naopak. Přepne se do zcela validního stavu: "zadal jste chybnou hodnotu...".

Aha, takze existuje predsa okno v nevalidom stave. A potom zrazu sa prepne do validneho. Ale to je zle !!!11!!!! To se stat nesmi! To je pro lyny programatori. Gui cargo kult.

Kdes' to vyčet'?

No jednoduche, je tam prehlaseny nevalidny stav za validny.  Sposobom "ved tam user nieco setne  a potom sa to zvaliduje". Za nieco podobne ste sa mi vysmievali.

Nevím jestli tomu zcela rozumím... některý vstup se dá validovat až po tom, co to tam uživatel "setne" a potvrdí to. Pole s emailem umožňuje zapsat jakýkoliv text, nevím kdy tam uživatel zapíše zavináč a doménu. Jestli je vstup validní zjistím až po změně stavu -- odeslání, výstup z pole na jiný prvek... Ve view jsou potencionálně nevalidní data, ale view je v naprosto validním stavu.

Oby som obcerstvil mne bolo vycitane, ze injektujem zavislosti cez settre a potom zavolam init metodu. Taky objekt sa nachadza potom vo validnom stave "nenainicializovany". Az potom, ako je korektne "inicializovany", poskytne sa systemu na pracu.  Teraz som to povedal po boneflutovsky. So ziadnymi nevalidnymi objektami sa v systeme nepracuje, ale aj tak mu to dalo mandat ma zosmiesnovat.

Nepleteš si tak trochu věc, kdy je objekt v nevalidním stavu se situací, kdy objekt validuje nějakou hodnotu a výsledek si uchovává v sobě? To druhé není jen prohlášení nevalidního stavu za validní. To je zkrátka a dobře dost něco jiného.