Příspěvky

1681

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 31. 08. 2016, 13:31:18 »

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.

1682

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 31. 08. 2016, 12:24:37 »

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'?

1683

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 31. 08. 2016, 12:12:15 »

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

1684

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 31. 08. 2016, 12:02:24 »

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?!

1685

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 31. 08. 2016, 11:51:19 »

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

1686

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 30. 08. 2016, 22:59:08 »

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íš.

1687

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 30. 08. 2016, 22:44:50 »

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.

Hmm, můžeš uvést jiný příklad? V případě minimální délky jména si zrovna dovedu snadno představit jak to validovat. Buď budu kontrolovat fixně, nebo si jako závislost vyžádám validátor, kterej to bude kontrolovat podle konfigurace. To mi přijde snadný.

1688

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 30. 08. 2016, 22:23:54 »

Liší se tím, že zveřejňují vnitřní stav objektu, což je špatně. Ovšem je to ale příjemné a zjednodušuje to práci, asi jako příkaz GOTO :-)))

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

To nutně ne. Ale když si ty metody (settery) nejsou schopny ani zvalidovat vstupní hodnoty - správný formát mailu například? To už by špatně být mohlo, ne?

Nebo když si nejsou schopny, ty settery, zajistit, že když objektu reprezentující fakturu nastavím typ `firma`, tak že musí mět vyplněný IČO? (Narážím na nevalidní stav objektu.)

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

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

1689

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 30. 08. 2016, 21:49:35 »

Liší se tím, že zveřejňují vnitřní stav objektu, což je špatně. Ovšem je to ale příjemné a zjednodušuje to práci, asi jako příkaz GOTO :-)))

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

To nutně ne. Ale když si ty metody (settery) nejsou schopny ani zvalidovat vstupní hodnoty - správný formát mailu například? To už by špatně být mohlo, ne?

Nebo když si nejsou schopny, ty settery, zajistit, že když objektu reprezentující fakturu nastavím typ `firma`, tak že musí mět vyplněný IČO? (Narážím na nevalidní stav objektu.)

1690

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 30. 08. 2016, 21:24:16 »

Dobře víš, o co se jedná, ale chceš rozpoutat další flame na téma C++ (Java, C#, Python...) nejsou objektové jazyky, správně je to jedině ve Smalltalku a vy všichni, co nepoužíváte Smalltalk, jste jen pojídači koláčů. Promiň, ale toho se nehodlám účastnit.

Já vím, o co se jedná, ale nevím, co myslíte vy všichni. Takže jednodušeji: Čím se liší gettery/settery od metod (vynechte pojednání o způsobu zápisu, jde mi o funkcionalitu, neboli co to má dělat).

Řekl bych, že problém může být něco takového:

Jednak gettery a settery vytváří tak plochou strukturu, že je k nerozeznání od struct. Což není tak úplně vončo. Krom doménových objektů se pak vytvářejí obludné fasády, a podobné nepohodlné věci. No, to asi nemusím vysvětlovat.

Spousta jazyků, jako je Java nemá properties, 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. Tedy jinak řečeno, gettery/settery jsou vynucenej syntaktickej cukr, který by nebyl potřeba, když by jazyk nebyl tak blbej.

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. A tak podobně. A důvod, proč to tak dělali je ten, že to tak dělali ti před nimi, a ti přece nejsou blbí. No, nejsou, ale zkušenost se získává, s tou se nerodíš.

1691

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 30. 08. 2016, 17:38:36 »

Supr. A metody to samé nezvládnou?

To byla ironie...

...a mně to přišlo nějaký podezřele vlezdozadekezecký... 

No, ten přístpěvek asi nebyl z nejužitečnějších, ale vzhledem k argumentům zde přednášeným, a vzhledem k schopnosti některých číst - už mě to žíly netrhá. Tak jsem se alespoň pobavil.

Kdybych se aspoň dozvěděl něco zajímavého...

1692

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 30. 08. 2016, 17:25:45 »

Supr. A metody to samé nezvládnou?

To byla ironie...

1693

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 30. 08. 2016, 15:50:45 »

...Vedeš tady svatou válku proti getterům a setterům, ale ony se v praxi používají, protože nikdo zatím nic lepšího nevymyslel... ...měl bys je tam taky, protože to prostě funguje nejlíp. Bez getterů a setterů by to šlo udělat, ale bude to horší. Jak z hlediska výkonu, tak z hlediska udržovatelnosti kódu...

Prosímvás, mohl by mi tady konečně někdo vysvětlit, co si místní diskutující představují pod termíny getter a setter? Pořád mám pocit, že je to něco sice magického a zakázaného, ale děsně to zrychlí aplikaci, když se to tam dá. Přitom jsem si vždy myslel, že se jedná pouze o luxusní název pro obyčejné, prašivé metody (často s cukrovou syntaxí pro trupky), přes které tečou informace z a do objektu. Možná by nebylo od věci připojit informaci, ke kterému že to zprasenému jazyku se ono provedení getterů a setterů vztahuje.
Děkuji velice za vysvětlení.

Nevím, zda se mi to podaří dostatečně objasnit, protože přeci jen, nemá ty zkušenosti, ale zkusím to.

Gettery a Settery jsou specielní zařízení, které slouží k naplnění nějakého objektu. Cíl je ten, aby to bylo pěkně rozmístěné. Na jednom místě si vytvoříš objekt. To je něco jako avizo na místo (velice drahá operace, proto má samostatnou kolonku). Pak přejdeš na jiné místo, kde pomocí setterů nastavíš tomu objektu nějaká data. Tím, jak je na každý prvek extra setter - metoda, tak to zásadně zpřehlední a pomůže to tomu, aby si na žádný povinný prvek nezapoměl.

Důležité je toto (vytváření a plnění) explicitně rozlišovat. To kůli výkonu.

Jak už tu někteří zmínili, velice příjemným vedlejším efektem je, že když se ti to na z nějakého důvodu nepovede (myšleno nastavení toho objektu pomocí setteru), tak to můžeš zkusit znova, případně i do třetice.

Další skvělou vlastností je, že když potřebuješ objektu přidat nějakou povinnou závislost, nějaký atribut, tak prostě jen přidáš dvě nové metody, setter/getter, a už jen všude dohledáš, kde se to nastavuje. A máš to.

Prostě díky setterům uděláš dobrou práci. Je to skvělý.

1694

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 30. 08. 2016, 14:16:31 »

Objekt ktory nie je inicializovany (tj nevalidny) by sa nemal pouzivat. Spajat instanciaciu s inicializaciou je zarabanie si na problemy.

Objekt který je nevalidní by neměl v prvé řadě vůbec existovat.

Naopak. Možnost něčeho takového, tedy oddělovat vytvoření a inicializace objektu je zadělávání si na problémy.

Objekty v nevalidnych stavoch existuju uplne bezne aj po inicializacii v konstruktore. (Nieco sa nepodari tak ako ma, kvoli vonkajsim vplyvom) Taky objekt je mozne zahodit a spustit znova drahy proces instanciacie, alebo je mozne ho znova nakonfigurovat a pustit init metodu.  Od smalltalku to tak funguje ze je oddelena instanciacia a inicializacia.

Zavrhov

Požádal bych o lepší argument.

Nekvalitní kód se také objevuje zcela běžně. A důvodem není to, že by to nešlo napsal lépe, ale pouze takové přízemní věci, jako nezkušenost, legaci, good-enought. Domníval jsem se, že se tu bavíme o tom, co je správně, ne o tom, jak se to dá zbastlit.

Pokud se konstruktoru nepodaří vytvořit validní objekt, tak chcípne. Volající má na starost sehnat všechno co konstruktor potřebuje/deklaruje (vnější vliv) aby byl spokojený.

Jestli budeš vytvářet drahý konstruktor, nebo drahou inicializaci, to máš fuk. Toto je obyčejný cargocult. Pokud narážíš na C++, nebo Javu a na alokaci paměti, když se nepovede inicializace, tak máš úplně jiné starosti, než honit bajtíky.

Pohledem do historie můžeme pozorovat, že konstruktor byl vymyšlen právě proto, aby se část alokace (malloc) sloučila s částí inicializací. Nevím, proč bych v moderních jazycích měl psát hůř než v plainC.

1695

Vývoj / Re:Postřehy ohledně architektury JavaScriptu

« kdy: 30. 08. 2016, 13:43:51 »

Objekt ktory nie je inicializovany (tj nevalidny) by sa nemal pouzivat. Spajat instanciaciu s inicializaciou je zarabanie si na problemy.

Objekt který je nevalidní by neměl v prvé řadě vůbec existovat.

Naopak. Možnost něčeho takového, tedy oddělovat vytvoření a inicializace objektu je zadělávání si na problémy.