Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: YF 23. 08. 2016, 18:35:53
-
Cau - po letech sem si rekl ze se podivam do weboveho sveta - konkretne na javascript & nodejs - a jak se tim svetem tak ubiram tak me prijde v ledascems zajimavy - chtel sem vas poprosit o postrehy ohledne 'architektury' javascriptu - jak ho vlastne spravne pouzivat - (ciste z hlediska javascriptu prosim :) ) Zaujal me cofee script - nicmene nevim jak premyslet nad psanim kodu v necem co vlastne jenom provadi transkripci do js .. a tak :) prosim troly at si daj pohov - konstruktivni technicke prizpevky - diky.
YF
-
Cau - po letech sem si rekl ze se podivam do weboveho sveta - konkretne na javascript & nodejs - a jak se tim svetem tak ubiram tak me prijde v ledascems zajimavy - chtel sem vas poprosit o postrehy ohledne 'architektury' javascriptu - jak ho vlastne spravne pouzivat - (ciste z hlediska javascriptu prosim :) ) Zaujal me cofee script - nicmene nevim jak premyslet nad psanim kodu v necem co vlastne jenom provadi transkripci do js .. a tak :) prosim troly at si daj pohov - konstruktivni technicke prizpevky - diky.
YF
node.js je poměrně zajímavé díky smyčce událostí, nicméně samotný JS je dost nízkoúrovňový (před ES6). Občas je to trochu zmatek, ale "psaní kódu" je jako kdekoliv jinde, důležitá je filosofie node.js (callbacky). Stručně a jasně, není třeba si s tím lámat hlavu a psát přirozeně, jako v jiných OO jazycích. libevent a podobné knihovny jsou beztak napsané v C, takže jdou použít z libovolného jazyka.
-
Coffeescript bych považoval spíš za preprocesor. Přeložený kód je čitelný a moc se neliší. ES6 implementuje většinu důležitých featur, které měl Coffeescript navíc. Používám Coffeescript a CSON hlavně kvůli víceřádkovým stringům, ale v novém nodejs už by mělo fungovat ``. Nový projekt už bych v Coffeescriptu nezačínal.
-
Cau - po letech sem si rekl ze se podivam do weboveho sveta - konkretne na javascript & nodejs - a jak se tim svetem tak ubiram tak me prijde v ledascems zajimavy - chtel sem vas poprosit o postrehy ohledne 'architektury' javascriptu - jak ho vlastne spravne pouzivat - (ciste z hlediska javascriptu prosim :) ) Zaujal me cofee script - nicmene nevim jak premyslet nad psanim kodu v necem co vlastne jenom provadi transkripci do js .. a tak :) prosim troly at si daj pohov - konstruktivni technicke prizpevky - diky.
YF
Dám ti jeden tip, nauč se jak používat systém prototypů ... už to z tebe udělá JS boha vzhledem k jeho nepochopení. A pak piš klasický OOP kód doplnění sem tam o nějaký JS hack (tudle někam za běhu strčit metodu nebo ji přepsat ...).
A v nodejs se rozhodně nauč jak fungují streamy. Systém postavený na streamech je neskutečně elegantní věc, to ti řeknu.
-
node.js je poměrně zajímavé díky smyčce událostí, nicméně samotný JS je dost nízkoúrovňový (před ES6). Občas je to trochu zmatek, ale "psaní kódu" je jako kdekoliv jinde, důležitá je filosofie node.js (callbacky). Stručně a jasně, není třeba si s tím lámat hlavu a psát přirozeně, jako v jiných OO jazycích. libevent a podobné knihovny jsou beztak napsané v C, takže jdou použít z libovolného jazyka.
Javascript nikdy nebyl moc nízkoúrovňový. Jen mu chyběla a chybí rozsáhlejší standartní knihovna. Namísto callbacků se dají používat i coroutiny.
-
Cau - po letech sem si rekl ze se podivam do weboveho sveta - konkretne na javascript & nodejs - a jak se tim svetem tak ubiram tak me prijde v ledascems zajimavy - chtel sem vas poprosit o postrehy ohledne 'architektury' javascriptu - jak ho vlastne spravne pouzivat - (ciste z hlediska javascriptu prosim :) ) Zaujal me cofee script - nicmene nevim jak premyslet nad psanim kodu v necem co vlastne jenom provadi transkripci do js .. a tak :) prosim troly at si daj pohov - konstruktivni technicke prizpevky - diky.
YF
node.js je poměrně zajímavé díky smyčce událostí, nicméně samotný JS je dost nízkoúrovňový (před ES6). Občas je to trochu zmatek, ale "psaní kódu" je jako kdekoliv jinde, důležitá je filosofie node.js (callbacky). Stručně a jasně, není třeba si s tím lámat hlavu a psát přirozeně, jako v jiných OO jazycích. libevent a podobné knihovny jsou beztak napsané v C, takže jdou použít z libovolného jazyka.
Nejsem si docela jistý co myslíš tímhle "JS je dost nízkoúrovňový před ES6"
Pokud myslíš ten syntaktickej cukr kolem tříd, tak to je pouze pro lidi s takovou mírou ignorace, že se ani neobtěžují přečíst co to sou ty zasraný prototypy.
-
node.js je poměrně zajímavé díky smyčce událostí, nicméně samotný JS je dost nízkoúrovňový (před ES6). Občas je to trochu zmatek, ale "psaní kódu" je jako kdekoliv jinde, důležitá je filosofie node.js (callbacky). Stručně a jasně, není třeba si s tím lámat hlavu a psát přirozeně, jako v jiných OO jazycích. libevent a podobné knihovny jsou beztak napsané v C, takže jdou použít z libovolného jazyka.
JS se mi také nejeví jako nízkoúrovňový. Podle mne má vše, co je k OOP potřebné. Skoro bych řekl, že je objektovější než Java nebo C#.
-
Cau - po letech sem si rekl ze se podivam do weboveho sveta - konkretne na javascript & nodejs - a jak se tim svetem tak ubiram tak me prijde v ledascems zajimavy - chtel sem vas poprosit o postrehy ohledne 'architektury' javascriptu - jak ho vlastne spravne pouzivat - (ciste z hlediska javascriptu prosim :) ) Zaujal me cofee script - nicmene nevim jak premyslet nad psanim kodu v necem co vlastne jenom provadi transkripci do js .. a tak :) prosim troly at si daj pohov - konstruktivni technicke prizpevky - diky.
YF
To máš dost těžké, každý ti bude radit něco jiného podle vlastních zkušeností. JS je strašně rychle se měnící svět, viz https://segment.com/blog/the-deep-roots-of-js-fatigue/
Osobní názor: už bych dneska do CoffeeScriptu neinvestoval čas, ani do dalších JS-ale-ne-tak-úplně-JS like jazyků, protože ES6 a Lodash (IMHO) plně dostačují. Node.js je pro server-side určitě fajn, pokud už nepoužíváte jinou technologii.
-
Zajímavější než JS je Dart. Architektura JS = lisp pro lopaty. Je to jazyk, který je snad nejvíce znásilňovaný ze všech.
-
...nicméně samotný JS je dost nízkoúrovňový (před ES6)...
To snad nemyslíte vážně...!!!!!
...důležitá je filosofie node.js (callbacky)...
Callbacky jsou jednou z nejproblematičtějších věcí Node.js, kdy strukturováním do funkcí (neboli vývojářem) je řešeno předávání vlákna, které v jiných jazycích řeší různé syncy ap.
...není třeba si s tím lámat hlavu a psát přirozeně, jako v jiných OO jazycích...
To "přirozeně" myslíte jako v Javě a C++, ne? Tak v tom případě je Javascript protipólem těchto dvou jazyků, protože modelování v něm je značně jednoduché.
Kam na ty "rady" chodíte?
-
Dám ti jeden tip, nauč se jak používat systém prototypů ... už to z tebe udělá JS boha vzhledem k jeho nepochopení...
Asi tak. S prototypy se dá docela čarovat, řekl bych, že je to taková přímočařejší forma sdílení vlastností a chování objektů oproti třídně-instančnímu OOP. Rozhodně stojí za pozornost, a to i pro pochopení OOP.
-
node.js je poměrně zajímavé díky smyčce událostí, nicméně samotný JS je dost nízkoúrovňový (před ES6). Občas je to trochu zmatek, ale "psaní kódu" je jako kdekoliv jinde, důležitá je filosofie node.js (callbacky). Stručně a jasně, není třeba si s tím lámat hlavu a psát přirozeně, jako v jiných OO jazycích. libevent a podobné knihovny jsou beztak napsané v C, takže jdou použít z libovolného jazyka.
Javascript nikdy nebyl moc nízkoúrovňový. Jen mu chyběla a chybí rozsáhlejší standartní knihovna. Namísto callbacků se dají používat i coroutiny.
To jako knihovna pro standarty? K čemu by tam byla?
-
Javascript nikdy nebyl moc nízkoúrovňový. Jen mu chyběla a chybí rozsáhlejší standartní knihovna. Namísto callbacků se dají používat i coroutiny.
Nenapadá mě nic, co by se v Javascriptu dalo označit za nízkoúrovňové. Snad jen komplikovanost je zde nízkoúrovňová (i když už to autoři taky kurví, např. pseudotřídami, syntaktickým balastem...).
-
...nicméně samotný JS je dost nízkoúrovňový (před ES6)...
To snad nemyslíte vážně...!!!!!
...důležitá je filosofie node.js (callbacky)...
Callbacky jsou jednou z nejproblematičtějších věcí Node.js, kdy strukturováním do funkcí (neboli vývojářem) je řešeno předávání vlákna, které v jiných jazycích řeší různé syncy ap.
...není třeba si s tím lámat hlavu a psát přirozeně, jako v jiných OO jazycích...
To "přirozeně" myslíte jako v Javě a C++, ne? Tak v tom případě je Javascript protipólem těchto dvou jazyků, protože modelování v něm je značně jednoduché.
Kam na ty "rady" chodíte?
1) Myslím.
2) Callbacky jsou všude možně, nejen v JS, a vesměs jde o užitečný koncept.
3) Ne. Přirozeně znamená "idiomaticky", tedy bez různých frajeřinek, rádoby sofistikovaných konstrukcí a kdejakých epicyklů. V tomto exceluje například Go, jiné jazyky poskytují příliš volnosti, což bývá - u méně zkušených - na škodu.
-
JS se mi také nejeví jako nízkoúrovňový. Podle mne má vše, co je k OOP potřebné. Skoro bych řekl, že je objektovější než Java nebo C#.
Skoro? Např. velmi pozdní vazba a silná reflexivita je v porovnání s uvedenými bastly bezkonkurenční a velmi užitečná pro snadné objektové modelování.
-
...Node.js je pro server-side určitě fajn, pokud už nepoužíváte jinou technologii.
Ono popravdě, jaké jiné serverové platformy jsou dnes použitelné? Bezestavové PHP? Moloch Java? Widloidní a taky molochoidní C#? Moc toho není, ale bud rád, když se dozvím nějaké další.
-
...nicméně samotný JS je dost nízkoúrovňový (před ES6)...
To snad nemyslíte vážně...!!!!!
...důležitá je filosofie node.js (callbacky)...
Callbacky jsou jednou z nejproblematičtějších věcí Node.js, kdy strukturováním do funkcí (neboli vývojářem) je řešeno předávání vlákna, které v jiných jazycích řeší různé syncy ap.
...není třeba si s tím lámat hlavu a psát přirozeně, jako v jiných OO jazycích...
To "přirozeně" myslíte jako v Javě a C++, ne? Tak v tom případě je Javascript protipólem těchto dvou jazyků, protože modelování v něm je značně jednoduché.
Kam na ty "rady" chodíte?
1) Myslím.
2) Callbacky jsou všude možně, nejen v JS, a vesměs jde o užitečný koncept.
3) Ne. Přirozeně znamená "idiomaticky", tedy bez různých frajeřinek, rádoby sofistikovaných konstrukcí a kdejakých epicyklů. V tomto exceluje například Go, jiné jazyky poskytují příliš volnosti, což bývá - u méně zkušených - na škodu.
1) Tak to rovnou uveďte, v čem ta nízkoúrovňovost spočívá.
2) To nevylučuje, že mi stačí řešit některé asynchronní operace synchronně.
3) Javascript (původní) je postavený jako minimalistický, takže v tomto smyslu asi ano.
-
...Node.js je pro server-side určitě fajn, pokud už nepoužíváte jinou technologii.
Ono popravdě, jaké jiné serverové platformy jsou dnes použitelné? Bezestavové PHP? Moloch Java? Widloidní a taky molochoidní C#? Moc toho není, ale bud rád, když se dozvím nějaké další.
Go.
-
Ono popravdě, jaké jiné serverové platformy jsou dnes použitelné? Bezestavové PHP? Moloch Java? Widloidní a taky molochoidní C#? Moc toho není, ale bud rád, když se dozvím nějaké další.
Go.
Taky hlasuji pro Go. Dobrá standardní knihovna, v základu skvělý tooling (lint+format, code coverage, testovací fw, dependency management), decentralizované závislosti, cross-kompilace, snadná distribuce (jeden spustitelný soubor), rychlost, čitelný zdroják...
Na druhou stranu psát kód v Go je trochu nuda. O to lépe se ale následně čte a chápe.
(Pro doplnění: živí mě Java, prošel jsem si PHP, Pythonem a JavaScriptem - včetně node, ES6, reactu, coffeescriptu, promises a await/async, všeho toho moderního a zrovna-tenhle-týden-cool)
-
...Node.js je pro server-side určitě fajn, pokud už nepoužíváte jinou technologii.
Ono popravdě, jaké jiné serverové platformy jsou dnes použitelné? Bezestavové PHP? Moloch Java? Widloidní a taky molochoidní C#? Moc toho není, ale bud rád, když se dozvím nějaké další.
Myslel jsem konkrétně "molocha" Javu, protože základní servlet kontejner je hodně lehkotonážní a ono node.js se svým VM také není úplně malé (řeknu to ještě jinak - systém balíčků a jejich závislostí v JS je poněkud problematický)
A jinak raději zopakuju - základní servlet kontejner bez dalších opičinek typu další-enterprise-logovací-systém, skoro-EE-knihovní-bastl a úplně-hustě-nejlepší-ale-teď-už-skutečně-funkční-generace-ORM.
-
Ono popravdě, jaké jiné serverové platformy jsou dnes použitelné? Bezestavové PHP? Moloch Java? Widloidní a taky molochoidní C#? Moc toho není, ale bud rád, když se dozvím nějaké další.
Go.
Taky hlasuji pro Go. Dobrá standardní knihovna, v základu skvělý tooling (lint+format, code coverage, testovací fw, dependency management), decentralizované závislosti, cross-kompilace, snadná distribuce (jeden spustitelný soubor), rychlost, čitelný zdroják...
Na druhou stranu psát kód v Go je trochu nuda. O to lépe se ale následně čte a chápe.
(Pro doplnění: živí mě Java, prošel jsem si PHP, Pythonem a JavaScriptem - včetně node, ES6, reactu, coffeescriptu, promises a await/async, všeho toho moderního a zrovna-tenhle-týden-cool)
Ta "nuda" byla záměrem tvůrců Go, jak jeden cca. před rokem obsáhle vysvětlil na konferenci. Nechtěli žádný super fancy jazyk, ale jednoduchý praktický nástroj. Myslím, že se jim to povedlo, Go je hodně rychlé (poráží Javu) a jako server se výkonem blíží nginxu. Záměrně nemá poslední výkřiky IT módy, ale je při zemi a pragmatické.
-
Ta "nuda" byla záměrem tvůrců Go, jak jeden cca. před rokem obsáhle vysvětlil na konferenci. Nechtěli žádný super fancy jazyk, ale jednoduchý praktický nástroj. Myslím, že se jim to povedlo, Go je hodně rychlé (poráží Javu) a jako server se výkonem blíží nginxu. Záměrně nemá poslední výkřiky IT módy, ale je při zemi a pragmatické.
Souhlas. Navic to ma ten efekt, ze se odfiltruji frikulini, kteri kazdy tyden meni bud cely framework nebo aspon templatovaci system, a go se zacina (i kdyz pomalicku) pouzivat na dost zajimave projekty.
-
Ono popravdě, jaké jiné serverové platformy jsou dnes použitelné? Bezestavové PHP? Moloch Java? Widloidní a taky molochoidní C#? Moc toho není, ale bud rád, když se dozvím nějaké další.
Možností je hodně. Nevýhoda Node.js je, že je nutné psát asynchroní kód i když to nepotřebuji.
-
Ono popravdě, jaké jiné serverové platformy jsou dnes použitelné? Bezestavové PHP? Moloch Java? Widloidní a taky molochoidní C#? Moc toho není, ale bud rád, když se dozvím nějaké další.
Možností je hodně. Nevýhoda Node.js je, že je nutné psát asynchroní kód i když to nepotřebuji.
Díky async await to ale už nebude problém, pokud vím, je to ale až v ES7 ...
-
Vzhledem k tomu že GO není ani objektové, tak bych s ním neztrácel čas, procedurální přístup je otázka historie.
-
Díky async await to ale už nebude problém, pokud vím, je to ale až v ES7 ...
Await se dá používat jen v async funkci. Je to téměř stejné jako generátory. Nemůžeš vzít libovolný kus kódu a spustit ho například v konzoli.
-
Ta "nuda" byla záměrem tvůrců Go, jak jeden cca. před rokem obsáhle vysvětlil na konferenci. Nechtěli žádný super fancy jazyk, ale jednoduchý praktický nástroj. Myslím, že se jim to povedlo, Go je hodně rychlé (poráží Javu) a jako server se výkonem blíží nginxu. Záměrně nemá poslední výkřiky IT módy, ale je při zemi a pragmatické.
Pokud se nepletu, tak nema ani pomerne zasadni vlastnosti, ktere tu jsou uz desitky let. Namatkou treba algebraicke typy + pattern matching (vcetne Maybe/Option typu), generika, makra... Nehlede na to, ze "posledni vykriky" IT mody nemusi nutne znamenat, ze jde o samoucelne vystrelky. Kdyz Go srovnam s "modernimi" jazyky jako Rust a Julia a asi i Nim, prijde mi, ze ta jeho konzervativnost je dana spise omezenosti jeho autoru, kteri se zasekli nekde v 70. letech a svoji omezenost ted vydavaji za prednost.
-
Co se tyce tech prototypu - existuji nejake paterny jak s dedicnosti v JS zachazet spravne? a co si dovolit a co uz ne? ctu good parts a prijde mi to trosku zastarale vuci ES6.
Dal sem se chtel zeptat jak se orientovat v tom ktera platforma co implementuje za 'featury' - nasel sem nejaky monstrozni matrix ktery to ma vysvetlovat nicmene napr. co implementuje node.js napr. ve verzi 0.10.40 sem tak nejak nenasel - o JS se zajimam hlavne kvuli node a atomu a rad bych si vubudoval nejaky vlastni js 'aparat' jak v tom psat aby to nebylo presroubovane a tak ... mate nejake linky o nejakem subsetu platnemu k 2016? :)
A posledni otazka k te nizkourovnovosti - jak je to teda mysleno? Diik
YF
-
Díky async await to ale už nebude problém, pokud vím, je to ale až v ES7 ...
Await se dá používat jen v async funkci. Je to téměř stejné jako generátory. Nemůžeš vzít libovolný kus kódu a spustit ho například v konzoli.
good point
-
Ta "nuda" byla záměrem tvůrců Go, jak jeden cca. před rokem obsáhle vysvětlil na konferenci. Nechtěli žádný super fancy jazyk, ale jednoduchý praktický nástroj. Myslím, že se jim to povedlo, Go je hodně rychlé (poráží Javu) a jako server se výkonem blíží nginxu. Záměrně nemá poslední výkřiky IT módy, ale je při zemi a pragmatické.
Pokud se nepletu, tak nema ani pomerne zasadni vlastnosti, ktere tu jsou uz desitky let. Namatkou treba algebraicke typy + pattern matching (vcetne Maybe/Option typu), generika, makra... Nehlede na to, ze "posledni vykriky" IT mody nemusi nutne znamenat, ze jde o samoucelne vystrelky. Kdyz Go srovnam s "modernimi" jazyky jako Rust a Julia a asi i Nim, prijde mi, ze ta jeho konzervativnost je dana spise omezenosti jeho autoru, kteri se zasekli nekde v 70. letech a svoji omezenost ted vydavaji za prednost.
Tak todle je fakt opravdu mimo ... pošli stejnou stížnost Jave/C++/C#/... starej jazyk se prostě vyvíjí pomalu a JS je starej jazyk (21 let).
Nehedě na to že v ES6 už něco jak náznaky pattern matchingu jsou.
-
Ta "nuda" byla záměrem tvůrců Go, jak jeden cca. před rokem obsáhle vysvětlil na konferenci. Nechtěli žádný super fancy jazyk, ale jednoduchý praktický nástroj. Myslím, že se jim to povedlo, Go je hodně rychlé (poráží Javu) a jako server se výkonem blíží nginxu. Záměrně nemá poslední výkřiky IT módy, ale je při zemi a pragmatické.
Pokud se nepletu, tak nema ani pomerne zasadni vlastnosti, ktere tu jsou uz desitky let. Namatkou treba algebraicke typy + pattern matching (vcetne Maybe/Option typu), generika, makra... Nehlede na to, ze "posledni vykriky" IT mody nemusi nutne znamenat, ze jde o samoucelne vystrelky. Kdyz Go srovnam s "modernimi" jazyky jako Rust a Julia a asi i Nim, prijde mi, ze ta jeho konzervativnost je dana spise omezenosti jeho autoru, kteri se zasekli nekde v 70. letech a svoji omezenost ted vydavaji za prednost.
Tak todle je fakt opravdu mimo ... pošli stejnou stížnost Jave/C++/C#/... starej jazyk se prostě vyvíjí pomalu a JS je starej jazyk (21 let).
Nehedě na to že v ES6 už něco jak náznaky pattern matchingu jsou.
Nepřehlédl jsi se, že reakce je na jazyk GO, a nikoliv na Javascript?
-
Co se tyce tech prototypu - existuji nejake paterny jak s dedicnosti v JS zachazet spravne? a co si dovolit a co uz ne? ctu good parts a prijde mi to trosku zastarale vuci ES6.
Dal sem se chtel zeptat jak se orientovat v tom ktera platforma co implementuje za 'featury' - nasel sem nejaky monstrozni matrix ktery to ma vysvetlovat nicmene napr. co implementuje node.js napr. ve verzi 0.10.40 sem tak nejak nenasel - o JS se zajimam hlavne kvuli node a atomu a rad bych si vubudoval nejaky vlastni js 'aparat' jak v tom psat aby to nebylo presroubovane a tak ... mate nejake linky o nejakem subsetu platnemu k 2016? :)
A posledni otazka k te nizkourovnovosti - jak je to teda mysleno? Diik
YF
Začni třeba tímhle (https://developer.mozilla.org/cs/docs/Web/JavaScript/Inheritance_and_the_prototype_chain), bude tam i ten shit s třídama. Díky ale za něj, aspoň nebudou ignoranti znovu vynalézat kolo/a.
Jo to máš kurva blbý, dneska přichází ES6, počkej 3-5 let a bude to bezpečný používat mainstreamově a tak dále. To znamená, piš jako kdyby ES6 nebyla ačkoli často podpora už bude. Budeš totiž ten svůj skvost chtít (měl bys) rozjet i na trochu starších enginech ...
Jak je to myšleno? Blbě. Autor si pod "lowlevel" představil asi něco kapku jinýho než jak se obecně pod tímhle termínem myslí. Lowlevel je například C++, ale není až tak lowlevel jako třeba C nebo rovnou ASM ...
-
Ta "nuda" byla záměrem tvůrců Go, jak jeden cca. před rokem obsáhle vysvětlil na konferenci. Nechtěli žádný super fancy jazyk, ale jednoduchý praktický nástroj. Myslím, že se jim to povedlo, Go je hodně rychlé (poráží Javu) a jako server se výkonem blíží nginxu. Záměrně nemá poslední výkřiky IT módy, ale je při zemi a pragmatické.
Pokud se nepletu, tak nema ani pomerne zasadni vlastnosti, ktere tu jsou uz desitky let. Namatkou treba algebraicke typy + pattern matching (vcetne Maybe/Option typu), generika, makra... Nehlede na to, ze "posledni vykriky" IT mody nemusi nutne znamenat, ze jde o samoucelne vystrelky. Kdyz Go srovnam s "modernimi" jazyky jako Rust a Julia a asi i Nim, prijde mi, ze ta jeho konzervativnost je dana spise omezenosti jeho autoru, kteri se zasekli nekde v 70. letech a svoji omezenost ted vydavaji za prednost.
Tak todle je fakt opravdu mimo ... pošli stejnou stížnost Jave/C++/C#/... starej jazyk se prostě vyvíjí pomalu a JS je starej jazyk (21 let).
Nehedě na to že v ES6 už něco jak náznaky pattern matchingu jsou.
Nepřehlédl jsi se, že reakce je na jazyk GO, a nikoliv na Javascript?
No jo ty vole, fakt sem se přehlíd ...
-
JS se mi také nejeví jako nízkoúrovňový. Podle mne má vše, co je k OOP potřebné. Skoro bych řekl, že je objektovější než Java nebo C#.
Skoro? Např. velmi pozdní vazba a silná reflexivita je v porovnání s uvedenými bastly bezkonkurenční a velmi užitečná pro snadné objektové modelování.
Napsal jsem "skoro", abych zbytečně neranil city javamana a jemu podobných. Jenže Javascript je multiparadigmatický, čímž se to mírně komplikuje. Samozřejmě ve prospěch Javascriptu.
-
Co se tyce tech prototypu - existuji nejake paterny jak s dedicnosti v JS zachazet spravne? a co si dovolit a co uz ne? ctu good parts a prijde mi to trosku zastarale vuci ES6.
Dal sem se chtel zeptat jak se orientovat v tom ktera platforma co implementuje za 'featury' - nasel sem nejaky monstrozni matrix ktery to ma vysvetlovat nicmene napr. co implementuje node.js napr. ve verzi 0.10.40 sem tak nejak nenasel - o JS se zajimam hlavne kvuli node a atomu a rad bych si vubudoval nejaky vlastni js 'aparat' jak v tom psat aby to nebylo presroubovane a tak ... mate nejake linky o nejakem subsetu platnemu k 2016? :)
A posledni otazka k te nizkourovnovosti - jak je to teda mysleno? Diik
YF
ES6 třídy jsou jen cukr nad prototypy. Narozdíl od čumila si nemyslím, že je to shit, ale není to nic převratného. To co se píše v Good Parts stále platí.
Přehled podporovaných featur v jednotlivých verzích je zde:
http://node.green/
-
Jo to máš kurva blbý, dneska přichází ES6, počkej 3-5 let a bude to bezpečný používat mainstreamově a tak dále. To znamená, piš jako kdyby ES6 nebyla ačkoli často podpora už bude. Budeš totiž ten svůj skvost chtít (měl bys) rozjet i na trochu starších enginech ...
Proč by neměl v node.js používat nové featury? Většinou se v budoucnu přechází na novější verzi a ne na starší. Není problém nainstalovat novější verzi i na starších systémech.
-
Jo to máš kurva blbý, dneska přichází ES6, počkej 3-5 let a bude to bezpečný používat mainstreamově a tak dále. To znamená, piš jako kdyby ES6 nebyla ačkoli často podpora už bude. Budeš totiž ten svůj skvost chtít (měl bys) rozjet i na trochu starších enginech ...
Proč by neměl v node.js používat nové featury? Většinou se v budoucnu přechází na novější verzi a ne na starší. Není problém nainstalovat novější verzi i na starších systémech.
O node nejde, o browser jde. Verzi nodu je možný ovlivnit, ale user má to co chce mít a ne to co chce developer.
-
Co se tyce tech prototypu - existuji nejake paterny jak s dedicnosti v JS zachazet spravne? a co si dovolit a co uz ne? ctu good parts a prijde mi to trosku zastarale vuci ES6.
Dal sem se chtel zeptat jak se orientovat v tom ktera platforma co implementuje za 'featury' - nasel sem nejaky monstrozni matrix ktery to ma vysvetlovat nicmene napr. co implementuje node.js napr. ve verzi 0.10.40 sem tak nejak nenasel - o JS se zajimam hlavne kvuli node a atomu a rad bych si vubudoval nejaky vlastni js 'aparat' jak v tom psat aby to nebylo presroubovane a tak ... mate nejake linky o nejakem subsetu platnemu k 2016? :)
A posledni otazka k te nizkourovnovosti - jak je to teda mysleno? Diik
YF
ES6 třídy jsou jen cukr nad prototypy. Narozdíl od čumila si nemyslím, že je to shit, ale není to nic převratného. To co se píše v Good Parts stále platí.
Přehled podporovaných featur v jednotlivých verzích je zde:
http://node.green/
Shit to je, třídy prostě do prototype based OOP nepatřej, a je jedno jestli jsou pouze imaginární a nebo real.
Jasně, můžeš to používat furt stejně protože tam žádný třídy ve skutečnosti nejsou. Jde tady spíš o tu filozofii.
-
Tak má user smůlu. Ať si tam dá klidně Netscape a pak si stěžuje kde chce.
-
Čumile, slyšel jsi už někdy třeba o Babelu? Ty kecy o shitech u tříd, které jsou přitom jenom trochu přehledněji zapsaným kódem, jsou taky dost mimo.
-
Tak má user smůlu. Ať si tam dá klidně Netscape a pak si stěžuje kde chce.
Když to vysvětlíš zákazníkovy ...
-
Čumile, slyšel jsi už někdy třeba o Babelu? Ty kecy o shitech u tříd, které jsou přitom jenom trochu přehledněji zapsaným kódem, jsou taky dost mimo.
... babel je limitovanej. Pokud featura potřebuje úpravu v enginu, je na to krátkej.
Ty si sám mimo ... kód s přímým využitím prototypů je přehledný taky, nesmíš ale být ignorant si o nich něco zjistit. Samozřejmě, když si každej udělá vlastní OOP systém (a že to JS umožňuje), tak je z toho bordel, to ale není chyba jazyka a ten class shit je snaha vyjít vstříct ignorantům.
-
Tak má user smůlu. Ať si tam dá klidně Netscape a pak si stěžuje kde chce.
Když to vysvětlíš zákazníkovy ...
Se na něj prostě vyseru. Zkus v ČR rešit každou blbost, co si někdo vymyslí. Pokud má problém, ať jde za lopatama, co mu tam dají klidně podporu hodinek s vodotryskem. Jsou věci, které smysl mají a které ne.
-
Čumile, limitovanej je tvůj mozek. V ES6 všechno píšu už přes dva roky. Vzbuď se.
-
Shit to je, třídy prostě do prototype based OOP nepatřej, a je jedno jestli jsou pouze imaginární a nebo real.
Jasně, můžeš to používat furt stejně protože tam žádný třídy ve skutečnosti nejsou. Jde tady spíš o tu filozofii.
Já nevím co ti na tom vadí. Výsledek je stejný a zápis je přehlednější nebo minimálně stejně přehledný. Nikdo tě nenutí to používat. Mnohem diskutabilnější mně přijdou properties. Jejich používání může kód znepřehlednit.
-
Tak má user smůlu. Ať si tam dá klidně Netscape a pak si stěžuje kde chce.
Když to vysvětlíš zákazníkovy ...
Se na něj prostě vyseru. Zkus v ČR rešit každou blbost, co si někdo vymyslí. Pokud má problém, ať jde za lopatama, co mu tam dají klidně podporu hodinek s vodotryskem. Jsou věci, které smysl mají a které ne.
Tak když ti to takhle funguje ...
-
Čumile, limitovanej je tvůj mozek. V ES6 všechno píšu už přes dva roky. Vzbuď se.
Tydle keci si nech někam jinam :D naposledy mi něco o vzbuzováni tlačili svědci jehovovy ...
K tomu ES6, gratuluju, zasloužíš si metál.
-
Shit to je, třídy prostě do prototype based OOP nepatřej, a je jedno jestli jsou pouze imaginární a nebo real.
Jasně, můžeš to používat furt stejně protože tam žádný třídy ve skutečnosti nejsou. Jde tady spíš o tu filozofii.
Já nevím co ti na tom vadí. Výsledek je stejný a zápis je přehlednější nebo minimálně stejně přehledný. Nikdo tě nenutí to používat. Mnohem diskutabilnější mně přijdou properties. Jejich používání může kód znepřehlednit.
Vadí mi to spíše z filozofických důvodů, to je vše.
Properties mě zrovna přijdou fajn, i když mohou jak ty říkáš, věci zkomplikovat.
Co mě ale sere je absence nějaké built-in metody na klonování objektů. Neexistuje a nikdo ji asi ani v příštím století nepřidá. Takhle si musí člověk napsat vlastní, ale protože je v JS, tak je to samozřejmě pomalejší než kdyby to bylo nativní.
-
Co mě ale sere je absence nějaké built-in metody na klonování objektů. Neexistuje a nikdo ji asi ani v příštím století nepřidá. Takhle si musí člověk napsat vlastní, ale protože je v JS, tak je to samozřejmě pomalejší než kdyby to bylo nativní.
Taková funkce je v každé utility knihovně. Nepoužíváš underscore, lodash nebo jQuery?
-
Co mě ale sere je absence nějaké built-in metody na klonování objektů. Neexistuje a nikdo ji asi ani v příštím století nepřidá. Takhle si musí člověk napsat vlastní, ale protože je v JS, tak je to samozřejmě pomalejší než kdyby to bylo nativní.
Taková funkce je v každé utility knihovně. Nepoužíváš underscore, lodash nebo jQuery?
V 90% případů ty knihovní funkce nejsou schopny ani udělat deep copy. Přenos prototypů je z říše pohádek, o cyklickejch referencích ani nemluvím.
Nehledě na to že to furt neřeší problém. Není to nativní == je to pomalí.
-
Co mě ale sere je absence nějaké built-in metody na klonování objektů. Neexistuje a nikdo ji asi ani v příštím století nepřidá. Takhle si musí člověk napsat vlastní, ale protože je v JS, tak je to samozřejmě pomalejší než kdyby to bylo nativní.
Taková funkce je v každé utility knihovně. Nepoužíváš underscore, lodash nebo jQuery?
V 90% případů ty knihovní funkce nejsou schopny ani udělat deep copy. Přenos prototypů je z říše pohádek, o cyklickejch referencích ani nemluvím.
Nehledě na to že to furt neřeší problém. Není to nativní == je to pomalí.
Nenapadá tě, že je to prostě záměr, aby to nešlo, alespoň ne jednoduše?
-
Co mě ale sere je absence nějaké built-in metody na klonování objektů. Neexistuje a nikdo ji asi ani v příštím století nepřidá. Takhle si musí člověk napsat vlastní, ale protože je v JS, tak je to samozřejmě pomalejší než kdyby to bylo nativní.
Taková funkce je v každé utility knihovně. Nepoužíváš underscore, lodash nebo jQuery?
V 90% případů ty knihovní funkce nejsou schopny ani udělat deep copy. Přenos prototypů je z říše pohádek, o cyklickejch referencích ani nemluvím.
Nehledě na to že to furt neřeší problém. Není to nativní == je to pomalí.
Nenapadá tě, že je to prostě záměr, aby to nešlo, alespoň ne jednoduše?
A nenapadá tě, že pokud je to záměr, tak je kurva debilní ? Zvlášť v prototype based OOP kde se nové objekty standardně tvoří právě skrz klonování.
-
A nenapadá tě, že pokud je to záměr, tak je kurva debilní ? Zvlášť v prototype based OOP kde se nové objekty standardně tvoří právě skrz klonování.
Zaprvé, objekty se AFAIK většinou vytváří konstruktorem. Zadruhé, jQuery.extend má volbu pro deep copy. Lodash má deepClone. Všechny kopírovací funkce, se kterými jsem se setkal, přenáší prototyp. Cyklické reference ty funkce kontrolují.
-
Oprava. jQuery.extend nefunguje správně. Nakopíruje vlastnosti prototypu přímo do objektu. Lodash clone funguje správně.
-
V mojej oblubenej knizke "Douglas Croockford - Javascript:The good parts" autor vytvoril klonovaciu metodu monkey patchingom objektu "Object".
if (typeof Object.create !== 'function') {
Object.create = function (o) {
var F = function () {};
F.prototype = o;
return new F();
};
}
Klonuje sa potom takto:
var another_stooge = Object.create(stooge);
Mne to vzdy fungovalo, je nejaky dovod, preco to nepouzivat?
Pytam sa, lebo tu su sami experti a ja som len vysokoskolsky vzdelana lopata v odbore softverove inzinierstvo s praxou.
-
Vzhledem k tomu že GO není ani objektové, tak bych s ním neztrácel čas, procedurální přístup je otázka historie.
Potřebuju to pro obchodní systémy, takže neobjektový (či jiný rádobyobjektový jazyk) nechci. Takže děkuji Zbojovi, ale Go asi no go.
-
...Jak je to myšleno? Blbě. Autor si pod "lowlevel" představil asi něco kapku jinýho než jak se obecně pod tímhle termínem myslí. Lowlevel je například C++, ale není až tak lowlevel jako třeba C nebo rovnou ASM ...
Předpokládám, že autor (Zboj) si pod úrovní jazyku nepředstavuje jeho abstraktnost, ale množství do jazyku začleněných sraček, které by měly být součástí knihoven.
-
ES6 třídy jsou jen cukr nad prototypy. Narozdíl od čumila si nemyslím, že je to shit, ale není to nic převratného. To co se píše v Good Parts stále platí.
Přehled podporovaných featur v jednotlivých verzích je zde:
http://node.green/
Osobně si myslím, že předstírat, že Javascript je třídně-instanční, není dobře, je prostě prototypový, tak by se neměly v jazyku takovéto excesy objevovat. Jazyk má být minimalistický - narážím na Lisp či Smalltalk a jejich protipólů C# a Javu, proto mě tyto tendence v Javascriptu netěší.
Dovolil bych si připomenout citáty 2 velikánů:
„Dokonalosti není dosaženo tehdy, když už není co přidat, ale tehdy, když už nemůžete nic odebrat."
„Jednoduchost je nejvyšší sofistikovanost."
-
ES6 třídy jsou jen cukr nad prototypy. Narozdíl od čumila si nemyslím, že je to shit, ale není to nic převratného. To co se píše v Good Parts stále platí.
Přehled podporovaných featur v jednotlivých verzích je zde:
http://node.green/
Osobně si myslím, že předstírat, že Javascript je třídně-instanční, není dobře, je prostě prototypový, tak by se neměly v jazyku takovéto excesy objevovat. Jazyk má být minimalistický - narážím na Lisp či Smalltalk a jejich protipólů C# a Javu, proto mě tyto tendence v Javascriptu netěší.
Dovolil bych si připomenout citáty 2 velikánů:
„Dokonalosti není dosaženo tehdy, když už není co přidat, ale tehdy, když už nemůžete nic odebrat."
„Jednoduchost je nejvyšší sofistikovanost."
Squeak image ma 7 mb, pharo ma 18 mb. Kosate java api bolo prave inspirovane smalltalkom.
-
Proč by neměl v node.js používat nové featury? Většinou se v budoucnu přechází na novější verzi a ne na starší. Není problém nainstalovat novější verzi i na starších systémech.
O node nejde, o browser jde. Verzi nodu je možný ovlivnit, ale user má to co chce mít a ne to co chce developer.
Tady to spíš vede na otázku, kolik zdrojáků sdílíte na straně Node (server) a prohlížeče (klient).
-
Čumile, slyšel jsi už někdy třeba o Babelu? Ty kecy o shitech u tříd, které jsou přitom jenom trochu přehledněji zapsaným kódem, jsou taky dost mimo.
... babel je limitovanej. Pokud featura potřebuje úpravu v enginu, je na to krátkej.
Hlavně je Babel další mezivrstvou s potenciálem chyb.
...a ten class shit je snaha vyjít vstříct ignorantům.
Taky si myslím.
Napište mi prosím nějaký pro vás zajímavý materiál o modelování domény v Javascriptu. Děkuji.
-
To se tu zase sešla "parta". Všechno je špatně, go je neobjektové (po 10 minutách studia), žádné knihovny neumožní klonovat objekty, experti na ES6 a přitom neznají ani Object.assign. No comment.
-
...Mnohem diskutabilnější mně přijdou properties. Jejich používání může kód znepřehlednit.
Properties jako vlastnosti objektů? To je jedna z nejlepších věcí na Javascriptu, vysoce reflexivní přístup umožňuje vytváření obecných zpracování vlastností.
-
Co mě ale sere je absence nějaké built-in metody na klonování objektů. Neexistuje a nikdo ji asi ani v příštím století nepřidá. Takhle si musí člověk napsat vlastní, ale protože je v JS, tak je to samozřejmě pomalejší než kdyby to bylo nativní.
To je docela problém. Ale horší věc, co mě sere, je, že odstranili elegantní __noSuchMethod__ https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/noSuchMethod (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/noSuchMethod) a nahradili to jakýmsi komplikovaným Proxy. Nechápu.
-
To se tu zase sešla "parta". Všechno je špatně, go je neobjektové (po 10 minutách studia), žádné knihovny neumožní klonovat objekty, experti na ES6 a přitom neznají ani Object.assign. No comment.
Assign nedělá ani deep copy idiote :D
-
V mojej oblubenej knizke "Douglas Croockford - Javascript:The good parts" autor vytvoril klonovaciu metodu monkey patchingom objektu "Object".
if (typeof Object.create !== 'function') {
Object.create = function (o) {
var F = function () {};
F.prototype = o;
return new F();
};
}
Klonuje sa potom takto:
var another_stooge = Object.create(stooge);
Mne to vzdy fungovalo, je nejaky dovod, preco to nepouzivat?
Pytam sa, lebo tu su sami experti a ja som len vysokoskolsky vzdelana lopata v odbore softverove inzinierstvo s praxou.
Tohle objekt neklonuje. Pouze to vytvoří nový objekt s prototypem o.
-
Co mě ale sere je absence nějaké built-in metody na klonování objektů. Neexistuje a nikdo ji asi ani v příštím století nepřidá. Takhle si musí člověk napsat vlastní, ale protože je v JS, tak je to samozřejmě pomalejší než kdyby to bylo nativní.
To je docela problém. Ale horší věc, co mě sere, je, že odstranili elegantní __noSuchMethod__ https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/noSuchMethod (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/noSuchMethod) a nahradili to jakýmsi komplikovaným Proxy. Nechápu.
Hej to je fakt pruser, a co je nejhorší, proxy to nenahradí. Může odchytit přístup na neexistující slot ale už nevý jestli si ten slot zpřístupňoval a nebo volal (a s čím).
Na to sem zapoměl a je to fakt fakt nahovno.
-
V mojej oblubenej knizke "Douglas Croockford - Javascript:The good parts" autor vytvoril klonovaciu metodu monkey patchingom objektu "Object".
if (typeof Object.create !== 'function') {
Object.create = function (o) {
var F = function () {};
F.prototype = o;
return new F();
};
}
Klonuje sa potom takto:
var another_stooge = Object.create(stooge);
Mne to vzdy fungovalo, je nejaky dovod, preco to nepouzivat?
Pytam sa, lebo tu su sami experti a ja som len vysokoskolsky vzdelana lopata v odbore softverove inzinierstvo s praxou.
Tohle objekt neklonuje. Pouze to vytvoří nový objekt s prototypem o.
a?
-
A nenapadá tě, že pokud je to záměr, tak je kurva debilní ? Zvlášť v prototype based OOP kde se nové objekty standardně tvoří právě skrz klonování.
Zaprvé, objekty se AFAIK většinou vytváří konstruktorem. Zadruhé, jQuery.extend má volbu pro deep copy. Lodash má deepClone. Všechny kopírovací funkce, se kterými jsem se setkal, přenáší prototyp. Cyklické reference ty funkce kontrolují.
Tak asi hej ... V dokumentaci ale není nic o přenesenejch prototypech napsáno. Natožpak o schopnosti překlopit i zacyklenej objekt. Takže je to k hovnu.
-
Taková funkce je v každé utility knihovně. Nepoužíváš underscore, lodash nebo jQuery?
V 90% případů ty knihovní funkce nejsou schopny ani udělat deep copy. Přenos prototypů je z říše pohádek, o cyklickejch referencích ani nemluvím.
Nehledě na to že to furt neřeší problém. Není to nativní == je to pomalí.
Clone je klíčová operace a mohla by být součástí jazyku.
Na deep copy pozor, z podstaty věci si ji musí stejně udělat vývojář sám dle situace (není deep jako deep).
-
V mojej oblubenej knizke "Douglas Croockford - Javascript:The good parts" autor vytvoril klonovaciu metodu monkey patchingom objektu "Object".
if (typeof Object.create !== 'function') {
Object.create = function (o) {
var F = function () {};
F.prototype = o;
return new F();
};
}
Klonuje sa potom takto:
var another_stooge = Object.create(stooge);
Mne to vzdy fungovalo, je nejaky dovod, preco to nepouzivat?
Pytam sa, lebo tu su sami experti a ja som len vysokoskolsky vzdelana lopata v odbore softverove inzinierstvo s praxou.
Tohle objekt neklonuje. Pouze to vytvoří nový objekt s prototypem o.
a?
To cos postnul je polyfill na object.create, hovno klonování ...
-
V mojej oblubenej knizke "Douglas Croockford - Javascript:The good parts" autor vytvoril klonovaciu metodu monkey patchingom objektu "Object".
if (typeof Object.create !== 'function') {
Object.create = function (o) {
var F = function () {};
F.prototype = o;
return new F();
};
}
Klonuje sa potom takto:
var another_stooge = Object.create(stooge);
Mne to vzdy fungovalo, je nejaky dovod, preco to nepouzivat?
Pytam sa, lebo tu su sami experti a ja som len vysokoskolsky vzdelana lopata v odbore softverove inzinierstvo s praxou.
Tohle objekt neklonuje. Pouze to vytvoří nový objekt s prototypem o.
a?
V některých situacích to může stačit. Ale třeba hasOwnProperty nebude fungovat.
-
ES6 třídy jsou jen cukr nad prototypy. Narozdíl od čumila si nemyslím, že je to shit, ale není to nic převratného. To co se píše v Good Parts stále platí.
Přehled podporovaných featur v jednotlivých verzích je zde:
http://node.green/
Osobně si myslím, že předstírat, že Javascript je třídně-instanční, není dobře, je prostě prototypový, tak by se neměly v jazyku takovéto excesy objevovat. Jazyk má být minimalistický - narážím na Lisp či Smalltalk a jejich protipólů C# a Javu, proto mě tyto tendence v Javascriptu netěší.
Dovolil bych si připomenout citáty 2 velikánů:
„Dokonalosti není dosaženo tehdy, když už není co přidat, ale tehdy, když už nemůžete nic odebrat."
„Jednoduchost je nejvyšší sofistikovanost."
Squeak image ma 7 mb, pharo ma 18 mb. Kosate java api bolo prave inspirovane smalltalkom.
Je třeba uvažovat ještě VM, ale to má kolem 3 MB bez ovladačů. Image Phara má 24 MB (pořád je to prd na to, jakou funkcionalitu to zvládá), image Cuisu 6 MB (jestli si to dobře pamatuju)!
-
V mojej oblubenej knizke "Douglas Croockford - Javascript:The good parts" autor vytvoril klonovaciu metodu monkey patchingom objektu "Object".
if (typeof Object.create !== 'function') {
Object.create = function (o) {
var F = function () {};
F.prototype = o;
return new F();
};
}
Klonuje sa potom takto:
var another_stooge = Object.create(stooge);
Mne to vzdy fungovalo, je nejaky dovod, preco to nepouzivat?
Pytam sa, lebo tu su sami experti a ja som len vysokoskolsky vzdelana lopata v odbore softverove inzinierstvo s praxou.
Tohle objekt neklonuje. Pouze to vytvoří nový objekt s prototypem o.
a?
To cos postnul je polyfill na object.create, hovno klonování ...
Zaujimave veci sa dozviem, povedzte mi kefalin, co je potom rozumiete pod takym slovom "klonovanie" v prototype based programming?
-
V mojej oblubenej knizke "Douglas Croockford - Javascript:The good parts" autor vytvoril klonovaciu metodu monkey patchingom objektu "Object".
if (typeof Object.create !== 'function') {
Object.create = function (o) {
var F = function () {};
F.prototype = o;
return new F();
};
}
Klonuje sa potom takto:
var another_stooge = Object.create(stooge);
Mne to vzdy fungovalo, je nejaky dovod, preco to nepouzivat?
Pytam sa, lebo tu su sami experti a ja som len vysokoskolsky vzdelana lopata v odbore softverove inzinierstvo s praxou.
Tohle objekt neklonuje. Pouze to vytvoří nový objekt s prototypem o.
a?
V některých situacích to může stačit. Ale třeba hasOwnProperty nebude fungovat.
Nejen !!! Nic se sakra neklonuje, jenom se to frkne do prototypu novýho objektu. Ty data sou kurva sdílený, používat todle na klonování je ve stylu javamana...
-
V mojej oblubenej knizke "Douglas Croockford - Javascript:The good parts" autor vytvoril klonovaciu metodu monkey patchingom objektu "Object".
if (typeof Object.create !== 'function') {
Object.create = function (o) {
var F = function () {};
F.prototype = o;
return new F();
};
}
Klonuje sa potom takto:
var another_stooge = Object.create(stooge);
Mne to vzdy fungovalo, je nejaky dovod, preco to nepouzivat?
Pytam sa, lebo tu su sami experti a ja som len vysokoskolsky vzdelana lopata v odbore softverove inzinierstvo s praxou.
Tohle objekt neklonuje. Pouze to vytvoří nový objekt s prototypem o.
a?
V některých situacích to může stačit. Ale třeba hasOwnProperty nebude fungovat.
Nejen !!! Nic se sakra neklonuje, jenom se to frkne do prototypu novýho objektu. Ty data sou kurva sdílený, používat todle na klonování je ve stylu javamana...
Co poviete na taku feature javy, co sa vola "prototype chain"? To akoze nic, nula bodov?
-
V mojej oblubenej knizke "Douglas Croockford - Javascript:The good parts" autor vytvoril klonovaciu metodu monkey patchingom objektu "Object".
if (typeof Object.create !== 'function') {
Object.create = function (o) {
var F = function () {};
F.prototype = o;
return new F();
};
}
Klonuje sa potom takto:
var another_stooge = Object.create(stooge);
Mne to vzdy fungovalo, je nejaky dovod, preco to nepouzivat?
Pytam sa, lebo tu su sami experti a ja som len vysokoskolsky vzdelana lopata v odbore softverove inzinierstvo s praxou.
Tohle objekt neklonuje. Pouze to vytvoří nový objekt s prototypem o.
a?
To cos postnul je polyfill na object.create, hovno klonování ...
Zaujimave veci sa dozviem, povedzte mi kefalin, co je potom rozumiete pod takym slovom "klonovanie" v prototype based programming?
Alespoň deep copy, nejlíp přenést i prototypy sub objektů (be kopírování, chci aby fungovalo instaceof). Cyklicity by měli být korektně zkopírovány také.
-
V mojej oblubenej knizke "Douglas Croockford - Javascript:The good parts" autor vytvoril klonovaciu metodu monkey patchingom objektu "Object".
if (typeof Object.create !== 'function') {
Object.create = function (o) {
var F = function () {};
F.prototype = o;
return new F();
};
}
Klonuje sa potom takto:
var another_stooge = Object.create(stooge);
Mne to vzdy fungovalo, je nejaky dovod, preco to nepouzivat?
Pytam sa, lebo tu su sami experti a ja som len vysokoskolsky vzdelana lopata v odbore softverove inzinierstvo s praxou.
Tohle objekt neklonuje. Pouze to vytvoří nový objekt s prototypem o.
a?
To cos postnul je polyfill na object.create, hovno klonování ...
Zaujimave veci sa dozviem, povedzte mi kefalin, co je potom rozumiete pod takym slovom "klonovanie" v prototype based programming?
Alespoň deep copy, nejlíp přenést i prototypy sub objektů (be kopírování, chci aby fungovalo instaceof). Cyklicity by měli být korektně zkopírovány také.
Deep copy je komplexny problem. To nemoze vediet uz z podtaty veci jazyk sam dobre robit.
-
Assign nedělá ani deep copy idiote :D
Díky, že jste projevil své IQ tykve.
A potrefená husa zakejhala. Já nic o deep copy nepsal, jen jsem reagoval na nesmysl o neexistenci built-in methody na klonování objektů.
-
V mojej oblubenej knizke "Douglas Croockford - Javascript:The good parts" autor vytvoril klonovaciu metodu monkey patchingom objektu "Object".
if (typeof Object.create !== 'function') {
Object.create = function (o) {
var F = function () {};
F.prototype = o;
return new F();
};
}
Klonuje sa potom takto:
var another_stooge = Object.create(stooge);
Mne to vzdy fungovalo, je nejaky dovod, preco to nepouzivat?
Pytam sa, lebo tu su sami experti a ja som len vysokoskolsky vzdelana lopata v odbore softverove inzinierstvo s praxou.
Tohle objekt neklonuje. Pouze to vytvoří nový objekt s prototypem o.
a?
To cos postnul je polyfill na object.create, hovno klonování ...
Zaujimave veci sa dozviem, povedzte mi kefalin, co je potom rozumiete pod takym slovom "klonovanie" v prototype based programming?
Alespoň deep copy, nejlíp přenést i prototypy sub objektů (be kopírování, chci aby fungovalo instaceof). Cyklicity by měli být korektně zkopírovány také.
Deep copy je komplexny problem. To nemoze vediet uz z podtaty veci jazyk sam dobre robit.
Nežvaň mistře ...... A co strukturovaný klonovací mechanismus použitý na objekty které se posílají do workerů. Zvládne dokonce cyklicity (krom deep copy) ale už nepřenese prototypy.
-
Nejen !!! Nic se sakra neklonuje, jenom se to frkne do prototypu novýho objektu. Ty data sou kurva sdílený, používat todle na klonování je ve stylu javamana...
To nemusí vadit. Když změníš položku té kopie, tak se nepřepíše v prototypu. Pokud to není zanořená položka v podobjektu.
-
Assign nedělá ani deep copy idiote :D
Díky, že jste projevil své IQ tykve.
A potrefená husa zakejhala. Já nic o deep copy nepsal, jen jsem reagoval na nesmysl o neexistenci built-in methody na klonování objektů.
Šikovnej klučík našel nativní shallow copy, tady máš cukřík :D
-
To je marný. To se opravdu sešla parta. Vývojáři, co se zakopali X let zpátky a odmítají se pohnout z místa, jsou k ničemu. Zdůvodnění, že při konjunkci Jupitera se Saturnem může použití Babelu způsobovat problémy, je k smíchu. Když už teď máte problém držet krok s ostatními a ještě jste na svoje ignoranství hrdí, tak se na to radši vyserte.
-
V mojej oblubenej knizke "Douglas Croockford - Javascript:The good parts" autor vytvoril klonovaciu metodu monkey patchingom objektu "Object".
if (typeof Object.create !== 'function') {
Object.create = function (o) {
var F = function () {};
F.prototype = o;
return new F();
};
}
Klonuje sa potom takto:
var another_stooge = Object.create(stooge);
Mne to vzdy fungovalo, je nejaky dovod, preco to nepouzivat?
Pytam sa, lebo tu su sami experti a ja som len vysokoskolsky vzdelana lopata v odbore softverove inzinierstvo s praxou.
Tohle objekt neklonuje. Pouze to vytvoří nový objekt s prototypem o.
a?
To cos postnul je polyfill na object.create, hovno klonování ...
Zaujimave veci sa dozviem, povedzte mi kefalin, co je potom rozumiete pod takym slovom "klonovanie" v prototype based programming?
Alespoň deep copy, nejlíp přenést i prototypy sub objektů (be kopírování, chci aby fungovalo instaceof). Cyklicity by měli být korektně zkopírovány také.
Deep copy je komplexny problem. To nemoze vediet uz z podtaty veci jazyk sam dobre robit.
Nežvaň mistře ...... A co strukturovaný klonovací mechanismus použitý na objekty které se posílají do workerů. Zvládne dokonce cyklicity (krom deep copy) ale už nepřenese prototypy.
No je to pekne, len zle urobena "deep copy" moze sklonovat celu aplikaciu. Otazka, co je potom deep copy, a co nie je deep copy? Kto to ma rozhodnut? V jazyku to preto nie je, lebo sa nechcu srat s blbostami, ktore si ma osetrit pouzivatel jazyka.
-
To se tu zase sešla "parta". Všechno je špatně, go je neobjektové (po 10 minutách studia), žádné knihovny neumožní klonovat objekty, experti na ES6 a přitom neznají ani Object.assign. No comment.
Kdo psal, že je všechno špatně?
Objekt je v Go onen nezapouzdřený struct?
Je klonování klíčovou funkcionalitou objektového systému?
Řeší Object.assign nastavení správného prototypu?
Rádi se necháme poučit (tj. comment).
-
Nejen !!! Nic se sakra neklonuje, jenom se to frkne do prototypu novýho objektu. Ty data sou kurva sdílený, používat todle na klonování je ve stylu javamana...
To nemusí vadit. Když změníš položku té kopie, tak se nepřepíše v prototypu. Pokud to není zanořená položka v podobjektu.
Good point
Namátkou jen by mě zajímalo jestli to vošéfuje cyklicity korektně.
A co se mi nelíbý, přidává to další level do chainu.
-
Assign nedělá ani deep copy idiote :D
Díky, že jste projevil své IQ tykve.
A potrefená husa zakejhala. Já nic o deep copy nepsal, jen jsem reagoval na nesmysl o neexistenci built-in methody na klonování objektů.
Šikovnej klučík našel nativní shallow copy, tady máš cukřík :D
Krom toho, že to v mnoha případech (nebál bych se napsat ve většině) postačuje, tak se netvářím jako expert a poté co jsem přichycen to maskuji. Deep copy je součástí mnoha knihoven (ať už komplexních, tak takových, kde je pouze tato jedna funkce). Většinu toho, co jste tady za dnešek "nablil" jsou polopravdy (nesmysly a domněnky), čili lži. Nakonec toto je váš styl, pamatuji si vás i z jiných vláken.
-
Nejen !!! Nic se sakra neklonuje, jenom se to frkne do prototypu novýho objektu. Ty data sou kurva sdílený, používat todle na klonování je ve stylu javamana...
To nemusí vadit. Když změníš položku té kopie, tak se nepřepíše v prototypu. Pokud to není zanořená položka v podobjektu.
Jejda, má to problém, pokud v mateřském objektu se změní slot x, zmení se i v klonu pokud slot x do te doby neprepsal, což není garantováno.
-
Assign nedělá ani deep copy idiote :D
Díky, že jste projevil své IQ tykve.
A potrefená husa zakejhala. Já nic o deep copy nepsal, jen jsem reagoval na nesmysl o neexistenci built-in methody na klonování objektů.
Šikovnej klučík našel nativní shallow copy, tady máš cukřík :D
Krom toho, že to v mnoha případech (nebál bych se napsat ve většině) postačuje, tak se netvářím jako expert a poté co jsem přichycen to maskuji. Deep copy je součástí mnoha knihoven (ať už komplexních, tak takových, kde je pouze tato jedna funkce). Většinu toho, co jste tady za dnešek "nablil" jsou polopravdy (nesmysly a domněnky), čili lži. Nakonec toto je váš styl, pamatuji si vás i z jiných vláken.
No jo, jasně, diký, tak už zalez...
-
Nejen !!! Nic se sakra neklonuje, jenom se to frkne do prototypu novýho objektu. Ty data sou kurva sdílený, používat todle na klonování je ve stylu javamana...
To nemusí vadit. Když změníš položku té kopie, tak se nepřepíše v prototypu. Pokud to není zanořená položka v podobjektu.
Good point
Namátkou jen by mě zajímalo jestli to vošéfuje cyklicity korektně.
A co se mi nelíbý, přidává to další level do chainu.
Tam se nemá co zacyklit. Žádná rekurze tam neprobíhá.
-
Deep copy je komplexny problem. To nemoze vediet uz z podtaty veci jazyk sam dobre robit.
Nežvaň mistře ...... A co strukturovaný klonovací mechanismus použitý na objekty které se posílají do workerů. Zvládne dokonce cyklicity (krom deep copy) ale už nepřenese prototypy.
No je to pekne, len zle urobena "deep copy" moze sklonovat celu aplikaciu. Otazka, co je potom deep copy, a co nie je deep copy? Kto to ma rozhodnut? V jazyku to preto nie je, lebo sa nechcu srat s blbostami, ktore si ma osetrit pouzivatel jazyka.
Já bych to deep copy nerozpatlával, už z názvu je zřejmé, že clone není copy, clone by mělo být vytvoření objektu identického obsahu a chování, tj. i identických skládaných objektů, ne jejich kopií, neboli mimo identity se tyto 2 objekty ničím neliší.
-
Nejen !!! Nic se sakra neklonuje, jenom se to frkne do prototypu novýho objektu. Ty data sou kurva sdílený, používat todle na klonování je ve stylu javamana...
To nemusí vadit. Když změníš položku té kopie, tak se nepřepíše v prototypu. Pokud to není zanořená položka v podobjektu.
Good point
Namátkou jen by mě zajímalo jestli to vošéfuje cyklicity korektně.
A co se mi nelíbý, přidává to další level do chainu.
Tam se nemá co zacyklit. Žádná rekurze tam neprobíhá.
Jop, tak už jen ten chain a problem viz nahoře
-
Nejen !!! Nic se sakra neklonuje, jenom se to frkne do prototypu novýho objektu. Ty data sou kurva sdílený, používat todle na klonování je ve stylu javamana...
To nemusí vadit. Když změníš položku té kopie, tak se nepřepíše v prototypu. Pokud to není zanořená položka v podobjektu.
Jejda, má to problém, pokud v mateřském objektu se změní slot x, zmení se i v klonu pokud slot x do te doby neprepsal, což není garantováno.
To je pravda. Já jsem psal o změnách kopie.
-
To je marný. To se opravdu sešla parta. Vývojáři, co se zakopali X let zpátky a odmítají se pohnout z místa, jsou k ničemu. Zdůvodnění, že při konjunkci Jupitera se Saturnem může použití Babelu způsobovat problémy, je k smíchu. Když už teď máte problém držet krok s ostatními a ještě jste na svoje ignoranství hrdí, tak se na to radši vyserte.
O konjunkci jsem nic nepsal. Pořád dokola tu prosazuju, jednoduchý, přímočarý a koncepční systém.
Držet krok v čem? Některých držení kroků se totiž rád zdržím.
-
To je marný. To se opravdu sešla parta. Vývojáři, co se zakopali X let zpátky a odmítají se pohnout z místa, jsou k ničemu. Zdůvodnění, že při konjunkci Jupitera se Saturnem může použití Babelu způsobovat problémy, je k smíchu. Když už teď máte problém držet krok s ostatními a ještě jste na svoje ignoranství hrdí, tak se na to radši vyserte.
O konjunkci jsem nic nepsal. Pořád dokola tu prosazuju, jednoduchý, přímočarý a koncepční systém.
Držet krok v čem? Některých držení kroků se totiž rád zdržím.
Na supermužika nereaguj, pro něj je každej pod 20 starej ...
-
To je marný. To se opravdu sešla parta. Vývojáři, co se zakopali X let zpátky a odmítají se pohnout z místa, jsou k ničemu. Zdůvodnění, že při konjunkci Jupitera se Saturnem může použití Babelu způsobovat problémy, je k smíchu. Když už teď máte problém držet krok s ostatními a ještě jste na svoje ignoranství hrdí, tak se na to radši vyserte.
O konjunkci jsem nic nepsal. Pořád dokola tu prosazuju, jednoduchý, přímočarý a koncepční systém.
Držet krok v čem? Některých držení kroků se totiž rád zdržím.
Na supermužika nereaguj, pro něj je každej pod 20 starej ...
Shiiiit nad 20 ...
-
Nejen !!! Nic se sakra neklonuje, jenom se to frkne do prototypu novýho objektu. Ty data sou kurva sdílený, používat todle na klonování je ve stylu javamana...
To nemusí vadit. Když změníš položku té kopie, tak se nepřepíše v prototypu. Pokud to není zanořená položka v podobjektu.
Jejda, má to problém, pokud v mateřském objektu se změní slot x, zmení se i v klonu pokud slot x do te doby neprepsal, což není garantováno.
To je pravda. Já jsem psal o změnách kopie.
Tak to pak jo, jako klonování to de využít když chceš chránit interní stav (modulu / whatever) a neděláš klony klonů.
Chytrý ale nepoužitelný všude
-
To se tu zase sešla "parta". Všechno je špatně, go je neobjektové (po 10 minutách studia), žádné knihovny neumožní klonovat objekty, experti na ES6 a přitom neznají ani Object.assign. No comment.
Kdo psal, že je všechno špatně?
Objekt je v Go onen nezapouzdřený struct?
Je klonování klíčovou funkcionalitou objektového systému?
Řeší Object.assign nastavení správného prototypu?
Rádi se necháme poučit (tj. comment).
1. Tohle je subjektivní. Každý si může udělat názor sám.
2. Go není objektové, ale umí chování objektů emulovat. Samozřejmě to nesplňuje požadavky objektových puristů, ale to nesplňuje ani Java nebo Javascript.
3. Nevím, co myslíte objektovým systémem.
4. let copy = Object.assign({ __proto__: obj.__proto__ }, obj);
-
To se tu zase sešla "parta". Všechno je špatně, go je neobjektové (po 10 minutách studia), žádné knihovny neumožní klonovat objekty, experti na ES6 a přitom neznají ani Object.assign. No comment.
Kdo psal, že je všechno špatně?
Objekt je v Go onen nezapouzdřený struct?
Je klonování klíčovou funkcionalitou objektového systému?
Řeší Object.assign nastavení správného prototypu?
Rádi se necháme poučit (tj. comment).
1. Tohle je subjektivní. Každý si může udělat názor sám.
2. Go není objektové, ale umí chování objektů emulovat. Samozřejmě to nesplňuje požadavky objektových puristů, ale to nesplňuje ani Java nebo Javascript.
3. Nevím, co myslíte objektovým systémem.
4. let copy = Object.assign({ __proto__: obj.__proto__ }, obj);
A co prototypy vnořených objektů? Co deep copy?
-
Deep copy je komplexny problem. To nemoze vediet uz z podtaty veci jazyk sam dobre robit.
Nežvaň mistře ...... A co strukturovaný klonovací mechanismus použitý na objekty které se posílají do workerů. Zvládne dokonce cyklicity (krom deep copy) ale už nepřenese prototypy.
No je to pekne, len zle urobena "deep copy" moze sklonovat celu aplikaciu. Otazka, co je potom deep copy, a co nie je deep copy? Kto to ma rozhodnut? V jazyku to preto nie je, lebo sa nechcu srat s blbostami, ktore si ma osetrit pouzivatel jazyka.
Já bych to deep copy nerozpatlával, už z názvu je zřejmé, že clone není copy, clone by mělo být vytvoření objektu identického obsahu a chování, tj. i identických skládaných objektů, ne jejich kopií, neboli mimo identity se tyto 2 objekty ničím neliší.
Ja tomu rozumiem, len cumil ma tu presviedcal, ze klon by mal byt deep copy.
-
Kdo psal, že je všechno špatně?
Objekt je v Go onen nezapouzdřený struct?
Je klonování klíčovou funkcionalitou objektového systému?
Řeší Object.assign nastavení správného prototypu?
Rádi se necháme poučit (tj. comment).
1. Tohle je subjektivní. Každý si může udělat názor sám.
2. Go není objektové, ale umí chování objektů emulovat. Samozřejmě to nesplňuje požadavky objektových puristů, ale to nesplňuje ani Java nebo Javascript.
3. Nevím, co myslíte objektovým systémem.
4. let copy = Object.assign({ __proto__: obj.__proto__ }, obj);
2. Nejde mi o purismus, jen si nechci přidělávat práci - čím lepší je implemetace OOP, tím víc práce mi to ušetří. Java je slabá, ale Javascript je na tom o dost lépe, a o tom to je. :)
3. Myslím zde implementaci OOP, nějaký zazyk.
4. A nešlo by to jednodušeji? mimochodem z dokumentace: "It uses [[Get]] on the source and [[Set]] on the target, so it will invoke getters and setters." To může být na škodu. Neboli nejedná se o nízkoúrovňový klon.
-
Deep copy je komplexny problem. To nemoze vediet uz z podtaty veci jazyk sam dobre robit.
Nežvaň mistře ...... A co strukturovaný klonovací mechanismus použitý na objekty které se posílají do workerů. Zvládne dokonce cyklicity (krom deep copy) ale už nepřenese prototypy.
No je to pekne, len zle urobena "deep copy" moze sklonovat celu aplikaciu. Otazka, co je potom deep copy, a co nie je deep copy? Kto to ma rozhodnut? V jazyku to preto nie je, lebo sa nechcu srat s blbostami, ktore si ma osetrit pouzivatel jazyka.
Já bych to deep copy nerozpatlával, už z názvu je zřejmé, že clone není copy, clone by mělo být vytvoření objektu identického obsahu a chování, tj. i identických skládaných objektů, ne jejich kopií, neboli mimo identity se tyto 2 objekty ničím neliší.
Ja tomu rozumiem, len cumil ma tu presviedcal, ze klon by mal byt deep copy.
Klony mezi sebou nesmí mít žádný sdílený stav s vyjímkou prototypů. Jinak to pak opravdu nejsou klony, představ si lidskýho klona se sdílenou slezinou, dává to smysl ?
Jak už tady zaznělo, když má v sobě objekt referenci třeba na window nebo nějaký jiný objekt jehož není přímý majitel, klonování udělá pěknej bordel a musí se udělat ručně.
Není to ale zas tak častý případ a rozhodně to není důvod nedat k dispozici nativní klonovací metodu ...
-
Kdo psal, že je všechno špatně?
Objekt je v Go onen nezapouzdřený struct?
Je klonování klíčovou funkcionalitou objektového systému?
Řeší Object.assign nastavení správného prototypu?
Rádi se necháme poučit (tj. comment).
1. Tohle je subjektivní. Každý si může udělat názor sám.
2. Go není objektové, ale umí chování objektů emulovat. Samozřejmě to nesplňuje požadavky objektových puristů, ale to nesplňuje ani Java nebo Javascript.
3. Nevím, co myslíte objektovým systémem.
4. let copy = Object.assign({ __proto__: obj.__proto__ }, obj);
2. Nejde mi o purismus, jen si nechci přidělávat práci - čím lepší je implemetace OOP, tím víc práce mi to ušetří. Java je slabá, ale Javascript je na tom o dost lépe, a o tom to je. :)
3. Myslím zde implementaci OOP, nějaký zazyk.
4. A nešlo by to jednodušeji? mimochodem z dokumentace: "It uses [[Get]] on the source and [[Set]] on the target, so it will invoke getters and setters." To může být na škodu. Neboli nejedná se o nízkoúrovňový klon.
Tady nejde o to aby to šlo jednodušeji, tady de o to že to nedělá deep copy, sub objekty nejsou naklonovány. Výsledekem je brutální sdílení stavu mezi klonem a originálem. (o prototypech ani nemluvím)
Používá to gettery a settery, pokud by byli tak implementovány, mohly by provádět klonování a tím pádem by assign fungovalo korektně, jenže ty blbý gettery a settery si musíš opět udělat sám, ty default jen překopírujou referenci z jednoho slotu do druhýho.
-
Kdo psal, že je všechno špatně?
Objekt je v Go onen nezapouzdřený struct?
Je klonování klíčovou funkcionalitou objektového systému?
Řeší Object.assign nastavení správného prototypu?
Rádi se necháme poučit (tj. comment).
1. Tohle je subjektivní. Každý si může udělat názor sám.
2. Go není objektové, ale umí chování objektů emulovat. Samozřejmě to nesplňuje požadavky objektových puristů, ale to nesplňuje ani Java nebo Javascript.
3. Nevím, co myslíte objektovým systémem.
4. let copy = Object.assign({ __proto__: obj.__proto__ }, obj);
2. Nejde mi o purismus, jen si nechci přidělávat práci - čím lepší je implemetace OOP, tím víc práce mi to ušetří. Java je slabá, ale Javascript je na tom o dost lépe, a o tom to je. :)
3. Myslím zde implementaci OOP, nějaký zazyk.
4. A nešlo by to jednodušeji? mimochodem z dokumentace: "It uses [[Get]] on the source and [[Set]] on the target, so it will invoke getters and setters." To může být na škodu. Neboli nejedná se o nízkoúrovňový klon.
Ad 2: Go nějak přidělává práci?
-
Deep copy je komplexny problem. To nemoze vediet uz z podtaty veci jazyk sam dobre robit.
Nežvaň mistře ...... A co strukturovaný klonovací mechanismus použitý na objekty které se posílají do workerů. Zvládne dokonce cyklicity (krom deep copy) ale už nepřenese prototypy.
No je to pekne, len zle urobena "deep copy" moze sklonovat celu aplikaciu. Otazka, co je potom deep copy, a co nie je deep copy? Kto to ma rozhodnut? V jazyku to preto nie je, lebo sa nechcu srat s blbostami, ktore si ma osetrit pouzivatel jazyka.
Já bych to deep copy nerozpatlával, už z názvu je zřejmé, že clone není copy, clone by mělo být vytvoření objektu identického obsahu a chování, tj. i identických skládaných objektů, ne jejich kopií, neboli mimo identity se tyto 2 objekty ničím neliší.
Ja tomu rozumiem, len cumil ma tu presviedcal, ze klon by mal byt deep copy.
Klony mezi sebou nesmí mít žádný sdílený stav s vyjímkou prototypů. Jinak to pak opravdu nejsou klony, představ si lidskýho klona se sdílenou slezinou, dává to smysl ?
Jak už tady zaznělo, když má v sobě objekt referenci třeba na window nebo nějaký jiný objekt jehož není přímý majitel, klonování udělá pěknej bordel a musí se udělat ručně.
Není to ale zas tak častý případ a rozhodně to není důvod nedat k dispozici nativní klonovací metodu ...
Slezina nie je dobry priklad, lebo ludsky organizmus nepozna referencie. To by bolo slezinu mozne transplantovat zmenenim referencie na inu slezinu a to dobre nejde.
-
Deep copy je komplexny problem. To nemoze vediet uz z podtaty veci jazyk sam dobre robit.
Nežvaň mistře ...... A co strukturovaný klonovací mechanismus použitý na objekty které se posílají do workerů. Zvládne dokonce cyklicity (krom deep copy) ale už nepřenese prototypy.
No je to pekne, len zle urobena "deep copy" moze sklonovat celu aplikaciu. Otazka, co je potom deep copy, a co nie je deep copy? Kto to ma rozhodnut? V jazyku to preto nie je, lebo sa nechcu srat s blbostami, ktore si ma osetrit pouzivatel jazyka.
Já bych to deep copy nerozpatlával, už z názvu je zřejmé, že clone není copy, clone by mělo být vytvoření objektu identického obsahu a chování, tj. i identických skládaných objektů, ne jejich kopií, neboli mimo identity se tyto 2 objekty ničím neliší.
Ja tomu rozumiem, len cumil ma tu presviedcal, ze klon by mal byt deep copy.
Klony mezi sebou nesmí mít žádný sdílený stav s vyjímkou prototypů. Jinak to pak opravdu nejsou klony, představ si lidskýho klona se sdílenou slezinou, dává to smysl ?
Jak už tady zaznělo, když má v sobě objekt referenci třeba na window nebo nějaký jiný objekt jehož není přímý majitel, klonování udělá pěknej bordel a musí se udělat ručně.
Není to ale zas tak častý případ a rozhodně to není důvod nedat k dispozici nativní klonovací metodu ...
Slezina nie je dobry priklad, lebo ludsky organizmus nepozna referencie. To by bolo slezinu mozne transplantovat zmenenim referencie na inu slezinu a to dobre nejde.
Jo jasně, neber to doslova, bylo to pouze symbolický připodobnění.
-
Ja tomu rozumiem, len cumil ma tu presviedcal, ze klon by mal byt deep copy.
Klony mezi sebou nesmí mít žádný sdílený stav s vyjímkou prototypů. Jinak to pak opravdu nejsou klony, představ si lidskýho klona se sdílenou slezinou, dává to smysl ?
Jak už tady zaznělo, když má v sobě objekt referenci třeba na window nebo nějaký jiný objekt jehož není přímý majitel, klonování udělá pěknej bordel a musí se udělat ručně.
Není to ale zas tak častý případ a rozhodně to není důvod nedat k dispozici nativní klonovací metodu ...
Odkazování na jiný objekt ve smyslu asociace (bez vlastnictví - kompozice) je zcela běžné. Podstatné je, proč klonujete originál. U objektů s jedinečnými údaji je to hovadina, tam se používá kopírování s výběrem jednotlivých vlastností.
Pro nativní Clone je podstatné, že je nízkoúrovňové (řeší VM), takže jde naklonovat cokoli, což by jinak u objektů s nepřístupnými vlastnostmi nešlo.
-
OT: skutečně celá tato debata pomohla původnímu tazateli? :-)
-
Ja tomu rozumiem, len cumil ma tu presviedcal, ze klon by mal byt deep copy.
Klony mezi sebou nesmí mít žádný sdílený stav s vyjímkou prototypů. Jinak to pak opravdu nejsou klony, představ si lidskýho klona se sdílenou slezinou, dává to smysl ?
Jak už tady zaznělo, když má v sobě objekt referenci třeba na window nebo nějaký jiný objekt jehož není přímý majitel, klonování udělá pěknej bordel a musí se udělat ručně.
Není to ale zas tak častý případ a rozhodně to není důvod nedat k dispozici nativní klonovací metodu ...
Odkazování na jiný objekt ve smyslu asociace (bez vlastnictví - kompozice) je zcela běžné. Podstatné je, proč klonujete originál. U objektů s jedinečnými údaji je to hovadina, tam se používá kopírování s výběrem jednotlivých vlastností.
Pro nativní Clone je podstatné, že je nízkoúrovňové (řeší VM), takže jde naklonovat cokoli, což by jinak u objektů s nepřístupnými vlastnostmi nešlo.
Tak samozřejmě, používá se to a ostatně, OOP o tom je. Důvod proč chci interface pro klonování je v opačném případě nutnost ručně psát to blbý kopírování slot po slotu, a tolik času fakt nemám. U objektů u kterých počítám s klonováním obvykle (pokud lze) zařídím aby neobsahovali reference někam mimo svůj subgraf, pokud to nejde, musím udělat custom řešení, ...
A krom toho by ještě nativní klonování mohlo nějak kontrolovat zdali objekt neobsahuje referenci někam "mimo" a vyhodit exception.
-
OT: skutečně celá tato debata pomohla původnímu tazateli? :-)
Tak, to klonování je celkem zajímavý ...
-
Tak jako minimalne vime ze se muzeme bavit napriklad o klonovani - nicmene abych pravdu tak se ta debata vzdycky zvrhne v silenej proud domenek a nikam moc to nevede - navic si vsichni zacnou na 3ti strance nadavat; tak premyslim jak to udrzet v nejake kondici tu debatu :} tak rekneme ze klonovani: a zajimalo by me odkud teda se bere potreba vubec objekty klonovat? osobne to vidim jako naprosto posledni instanci jak bych resil vytvareni objektu - je to v js normalni a skutecne tak potrebne?
-
Tak jako minimalne vime ze se muzeme bavit napriklad o klonovani - nicmene abych pravdu tak se ta debata vzdycky zvrhne v silenej proud domenek a nikam moc to nevede - navic si vsichni zacnou na 3ti strance nadavat; tak premyslim jak to udrzet v nejake kondici tu debatu :} tak rekneme ze klonovani: a zajimalo by me odkud teda se bere potreba vubec objekty klonovat? osobne to vidim jako naprosto posledni instanci jak bych resil vytvareni objektu - je to v js normalni a skutecne tak potrebne?
Hele, řeknu ti kde to používám já.
- Mějme systém A.
- V systému A jsou mimo jiné objekty B.
- Do systému A je možné registrovat hooky ( callbacky ).
- Systém A občas v návaznosti na vnitřní stav zavolá některý z callbacku s jedním z interních objektů B a očekává od callbacku odpověď v podobě objektu C.
- Nechci aby user systému A mohl z callbacku zasáhnout do vnitřního stavu A, takže předávaný objekt B naklonuju, a tím pádem si s ním pak už user může dělat co jen chce.
Jindy zase klonování využívám když chci oddělit jednotlivé transformační fáze objektu od sebe třeba proto že někde dál chci použít daný objekt v jednom z mezistavů.
Taky by šlo před-inicializovat objekt a místo tvorby nového objektu jen ten předinicializovaný naklonovat. (defakto factory pattern)
Dále v prototype based OOP se obvykle využívá klonování k tvorbě nových objektů. Respektive objekt získáme tak že naklonujeme prototyp. Dědění se pak dá udělat jako úprava klonu a vydání ho za další prototyp.
Tady se pouštím na tenký led, nejlíp znám JS a to má ten prototypový model maličkato pojatý jinak (o tom také svědčí ignorace klonování), takže tady by bylo fajn kdyby přišel na scénu nějaký guru prototypů.
-
To je dost divoka hra: nemelo by to uvazovani byt spis nez o stavu spise o prototypu jako predpisu ktery chci dale pouzit k tvorbe instanci ktere maji stejne metody a chovani a to uvazovani o stavu nechat spis na navrh te aplikace? Prijde mi to jednodussi na dalsi uvazovani nad tim - tim ze klonuju se muzu dopustit spousty chyb a nekonzistenci - tim padem je ta struktura potom rekneme dost ... krehka :) Ale sorry - fakt js nerozumim ...
-
To je dost divoka hra: nemelo by to uvazovani byt spis nez o stavu spise o prototypu jako predpisu ktery chci dale pouzit k tvorbe instanci ktere maji stejne metody a chovani a to uvazovani o stavu nechat spis na navrh te aplikace? Prijde mi to jednodussi na dalsi uvazovani nad tim - tim ze klonuju se muzu dopustit spousty chyb a nekonzistenci - tim padem je ta struktura potom rekneme dost ... krehka :) Ale sorry - fakt js nerozumim ...
Kdyžtak se vyjádři konkrétně k jednotlivejm aplikacím, takhle slytý v jednom to moc nedávám
-
Nejen !!! Nic se sakra neklonuje, jenom se to frkne do prototypu novýho objektu. Ty data sou kurva sdílený, používat todle na klonování je ve stylu javamana...
To nemusí vadit. Když změníš položku té kopie, tak se nepřepíše v prototypu. Pokud to není zanořená položka v podobjektu.
Good point
Namátkou jen by mě zajímalo jestli to vošéfuje cyklicity korektně.
A co se mi nelíbý, přidává to další level do chainu.
Tam se nemá co zacyklit. Žádná rekurze tam neprobíhá.
Moze tam byt cyklicky graf v referenciach a to sa moze zacyklit. Pekne nazorne to bolo vidiet, ked som pre byvalu firmu robil do RSA plugin ktory vybranu triedu v UML previedol na stromovu strukturu. Riesil som to naivne tak, ze po 4-tej otocke som usudil, ze sa cyklim a dalej som nepokracoval.
-
idem radsej spat :) Pozeram o prispevok vyssie. Zomg.
-
Moze tam byt cyklicky graf v referenciach a to sa moze zacyklit. Pekne nazorne to bolo vidiet, ked som pre byvalu firmu robil do RSA plugin ktory vybranu triedu v UML previedol na stromovu strukturu. Riesil som to naivne tak, ze po 4-tej otocke som usudil, ze sa cyklim a dalej som nepokracoval.
v téhle funkci
if (typeof Object.create !== 'function') {
Object.create = function (o) {
var F = function () {};
F.prototype = o;
return new F();
};
}
se opravdu nemůže nic zacyklit. Pokud nemám pravdu, prosím o příklad objektu, který tu funkci zacyklí.
-
Moze tam byt cyklicky graf v referenciach a to sa moze zacyklit. Pekne nazorne to bolo vidiet, ked som pre byvalu firmu robil do RSA plugin ktory vybranu triedu v UML previedol na stromovu strukturu. Riesil som to naivne tak, ze po 4-tej otocke som usudil, ze sa cyklim a dalej som nepokracoval.
v téhle funkci
if (typeof Object.create !== 'function') {
Object.create = function (o) {
var F = function () {};
F.prototype = o;
return new F();
};
}
se opravdu nemůže nic zacyklit. Pokud nemám pravdu, prosím o příklad objektu, který tu funkci zacyklí.
Cykli sa mi gebula, spat idem.
-
Pánové, to Object.create ... je k piči tyvole. Jako copy-on-write klonování to nejde použít. V tomhle vlákně sme došli k závěru že změny v klonu se nedostanou do parenta, jenom naopak. To by někdy šlapalo fajn, ale hovno, ty cyklický reference mi prostě vrtaly furt hlavou a tak sem se to jal vyzkoušet, výsledek je že díky cyklicitám leakne změna stavu v klonu do parenta, takže je to vlastně klonování napiču, přesněji jenom shallow copy, a to není to po čem volám že chci nativně. Kód je dole
var FckinObj = {
x : { shit: "fuck this" }
};
FckinObj.x.parent = FckinObj;
console.log("FckinObj x: " + FckinObj.x.shit);
var y = Object.create(FckinObj);
y.x.shit = " ERROR BITCH ";
console.log("FckinObj x: " + FckinObj.x.shit);
/* OUTPUT
"FckinObj x: fuck this"
"FckinObj x: ERROR BITCH "
*/
-
Pánové, to Object.create ... je k piči tyvole. Jako copy-on-write klonování to nejde použít. V tomhle vlákně sme došli k závěru že změny v klonu se nedostanou do parenta, jenom naopak. To by někdy šlapalo fajn, ale hovno, ty cyklický reference mi prostě vrtaly furt hlavou a tak sem se to jal vyzkoušet, výsledek je že díky cyklicitám leakne změna stavu v klonu do parenta, takže je to vlastně klonování napiču, přesněji jenom shallow copy, a to není to po čem volám že chci nativně. Kód je dole
var FckinObj = {
x : { shit: "fuck this" }
};
FckinObj.x.parent = FckinObj;
console.log("FckinObj x: " + FckinObj.x.shit);
var y = Object.create(FckinObj);
y.x.shit = " ERROR BITCH ";
console.log("FckinObj x: " + FckinObj.x.shit);
/* OUTPUT
"FckinObj x: fuck this"
"FckinObj x: ERROR BITCH "
*/
To má být vtip? Zkus odstranit tu cyklickou referenci. Vypíše to úplně to stejné. y.x.shit vezme x z prototypu. Musel bys nejdřív udělat něco jako y.x = {}, aby se ti vytvořilo x přímo v tom objektu. Create nemůže nahradit deep copy. To tu ani nikdo netvrdil.
-
Pánové, to Object.create ... je k piči tyvole. Jako copy-on-write klonování to nejde použít. V tomhle vlákně sme došli k závěru že změny v klonu se nedostanou do parenta, jenom naopak. To by někdy šlapalo fajn, ale hovno, ty cyklický reference mi prostě vrtaly furt hlavou a tak sem se to jal vyzkoušet, výsledek je že díky cyklicitám leakne změna stavu v klonu do parenta, takže je to vlastně klonování napiču, přesněji jenom shallow copy, a to není to po čem volám že chci nativně. Kód je dole
var FckinObj = {
x : { shit: "fuck this" }
};
FckinObj.x.parent = FckinObj;
console.log("FckinObj x: " + FckinObj.x.shit);
var y = Object.create(FckinObj);
y.x.shit = " ERROR BITCH ";
console.log("FckinObj x: " + FckinObj.x.shit);
/* OUTPUT
"FckinObj x: fuck this"
"FckinObj x: ERROR BITCH "
*/
To má být vtip? Zkus odstranit tu cyklickou referenci. Vypíše to úplně to stejné. y.x.shit vezme x z prototypu. Musel bys nejdřív udělat něco jako y.x = {}, aby se ti vytvořilo x přímo v tom objektu. Create nemůže nahradit deep copy. To tu ani nikdo netvrdil.
Aa taky pravda. Tak tím pádem je to kompletně k ničemu, neb to v žádném scénáři neodstíní parenta od změn, a přesně to s tím odstíněním parenta tady někdo tvrdil ...
-
Pánové, to Object.create ... je k piči tyvole. Jako copy-on-write klonování to nejde použít. V tomhle vlákně sme došli k závěru že změny v klonu se nedostanou do parenta, jenom naopak. To by někdy šlapalo fajn, ale hovno, ty cyklický reference mi prostě vrtaly furt hlavou a tak sem se to jal vyzkoušet, výsledek je že díky cyklicitám leakne změna stavu v klonu do parenta, takže je to vlastně klonování napiču, přesněji jenom shallow copy, a to není to po čem volám že chci nativně. Kód je dole
var FckinObj = {
x : { shit: "fuck this" }
};
FckinObj.x.parent = FckinObj;
console.log("FckinObj x: " + FckinObj.x.shit);
var y = Object.create(FckinObj);
y.x.shit = " ERROR BITCH ";
console.log("FckinObj x: " + FckinObj.x.shit);
/* OUTPUT
"FckinObj x: fuck this"
"FckinObj x: ERROR BITCH "
*/
To má být vtip? Zkus odstranit tu cyklickou referenci. Vypíše to úplně to stejné. y.x.shit vezme x z prototypu. Musel bys nejdřív udělat něco jako y.x = {}, aby se ti vytvořilo x přímo v tom objektu. Create nemůže nahradit deep copy. To tu ani nikdo netvrdil.
Aa taky pravda. Tak tím pádem je to kompletně k ničemu, neb to v žádném scénáři neodstíní parenta od změn, a přesně to s tím odstíněním parenta tady někdo tvrdil ...
Odstíní ho to od stejných změn jako shallow copy.
-
Pánové, to Object.create ... je k piči tyvole. Jako copy-on-write klonování to nejde použít. V tomhle vlákně sme došli k závěru že změny v klonu se nedostanou do parenta, jenom naopak. To by někdy šlapalo fajn, ale hovno, ty cyklický reference mi prostě vrtaly furt hlavou a tak sem se to jal vyzkoušet, výsledek je že díky cyklicitám leakne změna stavu v klonu do parenta, takže je to vlastně klonování napiču, přesněji jenom shallow copy, a to není to po čem volám že chci nativně. Kód je dole
var FckinObj = {
x : { shit: "fuck this" }
};
FckinObj.x.parent = FckinObj;
console.log("FckinObj x: " + FckinObj.x.shit);
var y = Object.create(FckinObj);
y.x.shit = " ERROR BITCH ";
console.log("FckinObj x: " + FckinObj.x.shit);
/* OUTPUT
"FckinObj x: fuck this"
"FckinObj x: ERROR BITCH "
*/
To má být vtip? Zkus odstranit tu cyklickou referenci. Vypíše to úplně to stejné. y.x.shit vezme x z prototypu. Musel bys nejdřív udělat něco jako y.x = {}, aby se ti vytvořilo x přímo v tom objektu. Create nemůže nahradit deep copy. To tu ani nikdo netvrdil.
Aa taky pravda. Tak tím pádem je to kompletně k ničemu, neb to v žádném scénáři neodstíní parenta od změn, a přesně to s tím odstíněním parenta tady někdo tvrdil ...
Odstíní ho to od stejných změn jako shallow copy.
jop ...
-
var FckinObj = {
x : { shit: "fuck this" }
};
FckinObj.x.parent = FckinObj;
console.log("FckinObj x: " + FckinObj.x.shit);
var y = Object.create(FckinObj);
y.x.shit = " ERROR BITCH ";
console.log("FckinObj x: " + FckinObj.x.shit);
/* OUTPUT
"FckinObj x: fuck this"
"FckinObj x: ERROR BITCH "
*/
Ehm su tie vulgarizmy nutne, aby ste ukazali, ze sa vlastne vytvori shallow copy?
-
Ehm su tie vulgarizmy nutne, aby ste ukazali, ze sa vlastne vytvori shallow copy?
Shallow copy se nevytvoří.
-
<trapne ticho>
-
Sranda ako tu onanujete nad tým dementným jazykom a reálne patláte trápne webiky. JavaScriptári sú najväčšia háveď pod slnkom. Vymýšľať nejaké šialené super teoretické psychopatiny je príznak toho, že ste na programátori na nič.
-
Sranda ako tu onanujete nad tým dementným jazykom a reálne patláte trápne webiky. JavaScriptári sú najväčšia háveď pod slnkom. Vymýšľať nejaké šialené super teoretické psychopatiny je príznak toho, že ste na programátori na nič.
ja si nemyslim ze ten jazyk je dementni - on me prijde jenom ze ma strasne moc moznosti a tim padem se domluvit nad necim nad nim je slozity a dochazi tam k mnoha nepochopenim ... ale zpet k te otazce at uzavrem aspon to klonovani kdyz uz nic at ma tohle vlakno alespon nejaky zaver kdyz uz sem to zacal (i kdyz toho ted trosku lituju) ... :}
takze proc je potreba tak strasne klonovat objekty? :) nemeli by ty prototypy slouzit predevsim k tomu ze definuji strukturu a hierarchii ze ktere pak tvorim instance a pomoci 'konstruktoru' potom definuju jejich vychozi stav ktery dale upravuje jen proces (jednotlive kroky programu? :) ) nebo to je v js spatny pristup?
diky
-
Sranda ako tu onanujete nad tým dementným jazykom a reálne patláte trápne webiky. JavaScriptári sú najväčšia háveď pod slnkom. Vymýšľať nejaké šialené super teoretické psychopatiny je príznak toho, že ste na programátori na nič.
Aneb když nick sedí i na psaný projev... ;) Nejdřív si v tom jazyce něco komplexního napište, než začnete nadávat.
-
takze proc je potreba tak strasne klonovat objekty? :) nemeli by ty prototypy slouzit predevsim k tomu ze definuji strukturu a hierarchii ze ktere pak tvorim instance a pomoci 'konstruktoru' potom definuju jejich vychozi stav ktery dale upravuje jen proces (jednotlive kroky programu? :) ) nebo to je v js spatny pristup?
diky
Jinými slovy máme dostatek creational patterns a klonování k tomu nepotřebujeme.
-
ja myslim ze co me zajima - (mohlo by vas zajimat) je pekne popsano tady:
http://dmitrysoshnikov.com/ecmascript/chapter-7.1-oop-general-theory/
http://dmitrysoshnikov.com/ecmascript/chapter-7-2-oop-ecmascript-implementation/
-
Ad 2: Go nějak přidělává práci?
Ano. Nemá zapouzdření.
-
Sranda ako tu onanujete nad tým dementným jazykom a reálne patláte trápne webiky. JavaScriptári sú najväčšia háveď pod slnkom. Vymýšľať nejaké šialené super teoretické psychopatiny je príznak toho, že ste na programátori na nič.
Javascript není špatný, jenom prostě není pro každého.
-
Ad 2: Go nějak přidělává práci?
Ano. Nemá zapouzdření.
Encapsulation: the ability to restrict or provide access to data and the ability to tie behavior or methods with the data. For Go some of the salient features are:
* There are two levels of access - within the package alone, and public.
* If a field, type, or method starts with a capital letter it is exported outside the package and is public. If instead it starts with a small letter, it is visible only within the package.
* Exported/public items: MyStruct, MyMethod, MyField
* Items with package visibility: myStruct, myMethod, myField
* You can tie in methods/behavior to a type by defining functions associated with it. func (m my_type) my_func() int { }
* You cannot attach methods to a type if it is not defined in the local package.
-
<trapne ticho>
-
Takže bez zapouzdření, protože i když budete mít v package jen jednu třídu, i její instance budou vzájemně nezapouzdřené (stejně jako v C# a Javě).
-
Sranda ako tu onanujete nad tým dementným jazykom a reálne patláte trápne webiky. JavaScriptári sú najväčšia háveď pod slnkom. Vymýšľať nejaké šialené super teoretické psychopatiny je príznak toho, že ste na programátori na nič.
ja si nemyslim ze ten jazyk je dementni - on me prijde jenom ze ma strasne moc moznosti a tim padem se domluvit nad necim nad nim je slozity a dochazi tam k mnoha nepochopenim ... ale zpet k te otazce at uzavrem aspon to klonovani kdyz uz nic at ma tohle vlakno alespon nejaky zaver kdyz uz sem to zacal (i kdyz toho ted trosku lituju) ... :}
takze proc je potreba tak strasne klonovat objekty? :) nemeli by ty prototypy slouzit predevsim k tomu ze definuji strukturu a hierarchii ze ktere pak tvorim instance a pomoci 'konstruktoru' potom definuju jejich vychozi stav ktery dale upravuje jen proces (jednotlive kroky programu? :) ) nebo to je v js spatny pristup?
diky
Pochopitelně k vytváření objektů slouží konstruktory. Celá tato debata je ukázkou "cargo cult programming", kdy se sofistikované koncepty naprosto nelogicky aplikují úplně mimo bez jejich pochopení. Je to něco jako posadit opici před psací stroj, román z toho taky nikdy nevznikne.
-
Ad 2: Go nějak přidělává práci?
Ano. Nemá zapouzdření.
Encapsulation: the ability to restrict or provide access to data and the ability to tie behavior or methods with the data. For Go some of the salient features are:
* There are two levels of access - within the package alone, and public.
* If a field, type, or method starts with a capital letter it is exported outside the package and is public. If instead it starts with a small letter, it is visible only within the package.
* Exported/public items: MyStruct, MyMethod, MyField
* Items with package visibility: myStruct, myMethod, myField
* You can tie in methods/behavior to a type by defining functions associated with it. func (m my_type) my_func() int { }
* You cannot attach methods to a type if it is not defined in the local package.
Díky, ušetřil jsem příspěvek. V praxi je tato kontrola přístupu naprosto dostačující.
-
Pochopitelně k vytváření objektů slouží konstruktory...
Objekt lze vytvořit více způsoby, konstruktor je jenom jedním z nich.
...Celá tato debata je ukázkou "cargo cult programming", kdy se sofistikované koncepty naprosto nelogicky aplikují úplně mimo bez jejich pochopení...
Jo, právě to si myslím o vás.
-
Encapsulation: the ability to restrict or provide access to data and the ability to tie behavior or methods with the data. For Go some of the salient features are:
* There are two levels of access - within the package alone, and public.
* If a field, type, or method starts with a capital letter it is exported outside the package and is public. If instead it starts with a small letter, it is visible only within the package.
* Exported/public items: MyStruct, MyMethod, MyField
* Items with package visibility: myStruct, myMethod, myField
* You can tie in methods/behavior to a type by defining functions associated with it. func (m my_type) my_func() int { }
* You cannot attach methods to a type if it is not defined in the local package.
Díky, ušetřil jsem příspěvek. V praxi je tato kontrola přístupu naprosto dostačující.
Mluvte za sebe, ne za ostatní.
-
Pochopitelně k vytváření objektů slouží konstruktory...
Objekt lze vytvořit více způsoby, konstruktor je jenom jedním z nich.
...Celá tato debata je ukázkou "cargo cult programming", kdy se sofistikované koncepty naprosto nelogicky aplikují úplně mimo bez jejich pochopení...
Jo, právě to si myslím o vás.
V tomto konkrétním případě mám ostatně jen stejný názor jak Rob Pike. Jestli se můžeš odvolat na nějakou podobnou kapacitu, rád si poslechnu odborný (akademicky podložený) názor. Jinak tuto diskusi odložme, až budeš mít aspoň PhD, ne že bych se na takové úrovni odmítal bavit, ale potřebuju k tomu hospodu a pivo ;)
-
Sranda ako tu onanujete nad tým dementným jazykom a reálne patláte trápne webiky. JavaScriptári sú najväčšia háveď pod slnkom. Vymýšľať nejaké šialené super teoretické psychopatiny je príznak toho, že ste na programátori na nič.
Chcípni pičo
-
Sranda ako tu onanujete nad tým dementným jazykom a reálne patláte trápne webiky. JavaScriptári sú najväčšia háveď pod slnkom. Vymýšľať nejaké šialené super teoretické psychopatiny je príznak toho, že ste na programátori na nič.
ja si nemyslim ze ten jazyk je dementni - on me prijde jenom ze ma strasne moc moznosti a tim padem se domluvit nad necim nad nim je slozity a dochazi tam k mnoha nepochopenim ... ale zpet k te otazce at uzavrem aspon to klonovani kdyz uz nic at ma tohle vlakno alespon nejaky zaver kdyz uz sem to zacal (i kdyz toho ted trosku lituju) ... :}
takze proc je potreba tak strasne klonovat objekty? :) nemeli by ty prototypy slouzit predevsim k tomu ze definuji strukturu a hierarchii ze ktere pak tvorim instance a pomoci 'konstruktoru' potom definuju jejich vychozi stav ktery dale upravuje jen proces (jednotlive kroky programu? :) ) nebo to je v js spatny pristup?
diky
Pochopitelně k vytváření objektů slouží konstruktory. Celá tato debata je ukázkou "cargo cult programming", kdy se sofistikované koncepty naprosto nelogicky aplikují úplně mimo bez jejich pochopení. Je to něco jako posadit opici před psací stroj, román z toho taky nikdy nevznikne.
Konstruktory jsou jen jedna cesta, BTW ty konstruktory v JS mě spíš připomínaj factory...
Druhá cesta je klonování objektů, v JS se tenhle způsob tvorby objektů nepoužívá, pokud vím, v některých prototype based OOP implementacích byl tenhle princip použit. Detaily neřeknu, znám nejlíp JS.
Tím chci říct, nemluv jako kdyby tady nebyla jiná cesta, brání to inovacím
-
Tenhle problem mame s detmi: kdyz sme jim koupili moc hracek - nehrali si ani s jednou, vsechny rozhazeny a rozbity - ale meli jich hodne a mohli donekonecna premyslet o tom s cim si budou hrat aniz by si s nima vlastne hrali. Tak sem se jednou nastval - a protoze neuklizely tak sem ty vsechny hracky nahazel do pytle - nechal jim prazdnej pokoj jen s jednou stavebnici - a ted postupne pridavam hracky podle toho jak si poradili s tema co uz maji ... :) Nic - dekuji za prispevky - ja myslim ze obrazek sem si udelal - tak se mejte.
-
V tomto konkrétním případě mám ostatně jen stejný názor jak Rob Pike. Jestli se můžeš odvolat na nějakou podobnou kapacitu, rád si poslechnu odborný (akademicky podložený) názor. Jinak tuto diskusi odložme, až budeš mít aspoň PhD, ne že bych se na takové úrovni odmítal bavit, ale potřebuju k tomu hospodu a pivo ;)
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them." Alan Kay http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en (http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en)
Nepředpokládám, že Kay měl na mysli nějaké částečné zapouzdření (hiding), které někdy funguje a někdy ne.
Zato já už nemám náladu dohadovat se s nějakými céčkaři přeškolenými na OOP, chci se vrátit k původnímu tématu, a to je Javascript a jeho použití. Jestli máte potřebu protřepávat způsob, jak pozalamovat OOP do Go, založte si pro to jinou diskusi.
-
V tomto konkrétním případě mám ostatně jen stejný názor jak Rob Pike. Jestli se můžeš odvolat na nějakou podobnou kapacitu, rád si poslechnu odborný (akademicky podložený) názor. Jinak tuto diskusi odložme, až budeš mít aspoň PhD, ne že bych se na takové úrovni odmítal bavit, ale potřebuju k tomu hospodu a pivo ;)
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them." Alan Kay http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en (http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en)
Nepředpokládám, že Kay měl na mysli nějaké částečné zapouzdření (hiding), které někdy funguje a někdy ne.
Zato já už nemám náladu dohadovat se s nějakými céčkaři přeškolenými na OOP, chci se vrátit k původnímu tématu, a to je Javascript a jeho použití. Jestli máte potřebu protřepávat způsob, jak pozalamovat OOP do Go, založte si pro to jinou diskusi.
To chápu, céčkaři jsou divná stvoření, taky jsem jim nepříšel na chuť. Stejně jako javascriptařům. Programování ostatně není věda, ale čistě praktická a pragmatická činnost, něco jako tesařina, a absolutně nemá smysl se bavit o tom, jaká míra zapouzdření je žádoucí, protože to závisí na kontextu. Takže cargo kult pozdravuje :p Prvním krokem k přechodu od žvanila k odborníkovi - přiznávám, ne každý na to intelektuálně má - bude naučení se věcné diskusi...
-
Objekt lze vytvořit více způsoby, konstruktor je jenom jedním z nich.
Ale jistě. V JavaScriptu se dá snad všechno udělat na sto způsobů. Jen některé z těch způsobů jsou jaksi zavedené a očekávané, jiné pak méně vhodné. Dělat něco jinak než zbytek jenom proto, že TO TAKY JDE(čumte, co jsem se včera naučil!) není ta správná cesta, pokud nehodláš do smrti dělat one-man show.
-
Konstruktory jsou jen jedna cesta, BTW ty konstruktory v JS mě spíš připomínaj factory...
Druhá cesta je klonování objektů, v JS se tenhle způsob tvorby objektů nepoužívá, pokud vím, v některých prototype based OOP implementacích byl tenhle princip použit. Detaily neřeknu, znám nejlíp JS.
Tím chci říct, nemluv jako kdyby tady nebyla jiná cesta, brání to inovacím
Konkrétně třeba v Selfu a v Rebolu. V Selfu je to celé vymyšlené poměrně dobře a taky to byla jedna z inspirací pro javascript, bohužel se to ale povedlo kompletně posrat, od chybějící delegace po právě kopírování / klonování a bez toho je prototype-based OOP model jen parodie sebe sama.
Viz třeba:
- http://bibliography.selflanguage.org/organizing-programs.html
- http://bibliography.selflanguage.org/parents-shared-parts.html
-
Zboji jsi stejnej debil jako javaman. Až budou prohlížeče umět haskell a všichni programátoři budou mít Phd z teorie programovacích jazyků, tak budou tvoje výblitky možná někoho zajímat.
-
Objekt lze vytvořit více způsoby, konstruktor je jenom jedním z nich.
Ale jistě. V JavaScriptu se dá snad všechno udělat na sto způsobů. Jen některé z těch způsobů jsou jaksi zavedené a očekávané, jiné pak méně vhodné. Dělat něco jinak než zbytek jenom proto, že TO TAKY JDE(čumte, co jsem se včera naučil!) není ta správná cesta, pokud nehodláš do smrti dělat one-man show.
To je znak začínajících programátorů, použít právě naučené fancy věcičky, když by to šlo elegantně a jednoduše. Neštěstí je, když pak někdo normální musí ten prasokód (bez getterů, setterů, else, zato s milionem returnů a deep klonováním každého s prominutím h***a) číst. I v tom JS jde psát rozumně, jen to ten JS jaksi nevyžaduje :(
-
Objekt lze vytvořit více způsoby, konstruktor je jenom jedním z nich.
Ale jistě. V JavaScriptu se dá snad všechno udělat na sto způsobů. Jen některé z těch způsobů jsou jaksi zavedené a očekávané, jiné pak méně vhodné. Dělat něco jinak než zbytek jenom proto, že TO TAKY JDE(čumte, co jsem se včera naučil!) není ta správná cesta, pokud nehodláš do smrti dělat one-man show.
To je znak začínajících programátorů, použít právě naučené fancy věcičky, když by to šlo elegantně a jednoduše. Neštěstí je, když pak někdo normální musí ten prasokód (bez getterů, setterů, else, zato s milionem returnů a deep klonováním každého s prominutím h***a) číst. I v tom JS jde psát rozumně, jen to ten JS jaksi nevyžaduje :(
Zrovna gettery a settery jsou ten nejhloupější cargo kult.
-
Zrovna gettery a settery jsou ten nejhloupější cargo kult.
Spíš bych je označil za zbytečné boiler plates.
-
Objekt lze vytvořit více způsoby, konstruktor je jenom jedním z nich.
Ale jistě. V JavaScriptu se dá snad všechno udělat na sto způsobů. Jen některé z těch způsobů jsou jaksi zavedené a očekávané, jiné pak méně vhodné. Dělat něco jinak než zbytek jenom proto, že TO TAKY JDE(čumte, co jsem se včera naučil!) není ta správná cesta, pokud nehodláš do smrti dělat one-man show.
To je znak začínajících programátorů, použít právě naučené fancy věcičky, když by to šlo elegantně a jednoduše. Neštěstí je, když pak někdo normální musí ten prasokód (bez getterů, setterů, else, zato s milionem returnů a deep klonováním každého s prominutím h***a) číst. I v tom JS jde psát rozumně, jen to ten JS jaksi nevyžaduje :(
Zrovna gettery a settery jsou ten nejhloupější cargo kult.
Cargo kult je vzorec chování, nemůže označovat konkrétní věc nebo koncept. Nicméně používání cizích slov bez znalosti jejich významu a kontextu použití už by cargo kult být mohl. Hezky ses ztrapnil, ale teď místo kecání na fórech by ses mohl vrátit do školy (doslova nebo obrazně), ať příště nepůsobíš jako ta poslední lopata (doufám, že na toto slovo nemá patent tvé dvojče "javaman").
-
Objekt lze vytvořit více způsoby, konstruktor je jenom jedním z nich.
Ale jistě. V JavaScriptu se dá snad všechno udělat na sto způsobů. Jen některé z těch způsobů jsou jaksi zavedené a očekávané, jiné pak méně vhodné. Dělat něco jinak než zbytek jenom proto, že TO TAKY JDE(čumte, co jsem se včera naučil!) není ta správná cesta, pokud nehodláš do smrti dělat one-man show.
To je znak začínajících programátorů, použít právě naučené fancy věcičky, když by to šlo elegantně a jednoduše. Neštěstí je, když pak někdo normální musí ten prasokód (bez getterů, setterů, else, zato s milionem returnů a deep klonováním každého s prominutím h***a) číst. I v tom JS jde psát rozumně, jen to ten JS jaksi nevyžaduje :(
Zrovna gettery a settery jsou ten nejhloupější cargo kult.
Cargo kult je vzorec chování, nemůže označovat konkrétní věc nebo koncept. Nicméně používání cizích slov bez znalosti jejich významu a kontextu použití už by cargo kult být mohl. Hezky ses ztrapnil, ale teď místo kecání na fórech by ses mohl vrátit do školy (doslova nebo obrazně), ať příště nepůsobíš jako ta poslední lopata (doufám, že na toto slovo nemá patent tvé dvojče "javaman").
Dobře. Nemyslel jsem gettery a settery, ale jejich používání. Javaman mi připomíná spíš tebe. Já se tady narozdíl od vás dvou nad nikoho nevyvyšuju.
-
Proboha zboji, chováš se jak s prominutím čurák, ještě do toho javaman a můžem todle vlákno vodepsat ...
Né každej je tak hyper super cyber úžasnej jako ty, takže trošku míň schazování lidí "bez PhD" ...
-
:D
Kitův brácha to rozjel. Ale samozřejmě on trollí úplně stejný jako já i jeho brácha. PhD. má tak možná z nějaké české odpadní české školy typu MFF, jinak by neměl šanci s jeho přístupem něco získat. Tady si honí ego, protože jinde mu to nežerou. Ono asi těžko někoho zaujmou nazpaměť naučené věci, že jo...
-
Konstruktory jsou jen jedna cesta, BTW ty konstruktory v JS mě spíš připomínaj factory...
Druhá cesta je klonování objektů, v JS se tenhle způsob tvorby objektů nepoužívá, pokud vím, v některých prototype based OOP implementacích byl tenhle princip použit. Detaily neřeknu, znám nejlíp JS.
Tím chci říct, nemluv jako kdyby tady nebyla jiná cesta, brání to inovacím
Konkrétně třeba v Selfu a v Rebolu. V Selfu je to celé vymyšlené poměrně dobře a taky to byla jedna z inspirací pro javascript, bohužel se to ale povedlo kompletně posrat, od chybějící delegace po právě kopírování / klonování a bez toho je prototype-based OOP model jen parodie sebe sama.
Viz třeba:
- http://bibliography.selflanguage.org/organizing-programs.html
- http://bibliography.selflanguage.org/parents-shared-parts.html
Hej super, někoho kdo zná Self a jeho bratříčky tady bylo třeba.
Aby tadle diskuze bylo rozseknutá, správně interpretuju že klonování (deep) je pro prototype OOP kriticky důležité?
-
Cargo kult je vzorec chování, nemůže označovat konkrétní věc nebo koncept. Nicméně používání cizích slov bez znalosti jejich významu a kontextu použití už by cargo kult být mohl.
Takovým vzorcem chování typu "cargo kult" je například používání různých frameworků a spoléhání na to, že v další verzi to už konečně bude správně a že se nerozsype zase něco jiného.
-
Jedna ze základních dovedností inteligentního člověka by měl být způsob vedení debaty tak, aby z ní žádná strana nevyšla s pocitem, že je hlavním cílem oponenta protivníka shodit. A sbírka akademických titulů ani sdílení názoru s někým, koho považujeme za kompetentního, nezaručuje ani vítězství v debatě a už vůbec ne patent na pravdu.
-
Aby tadle diskuze bylo rozseknutá, správně interpretuju že klonování (deep) je pro prototype OOP kriticky důležité?
ty hele - cetls ty odkazy co sem posilal? tam je to pekne vysvetleny - kriticky dulezity je si udelat cas a cist a premyslet a to aspon hodinu v kuse :) tyhle fora tezko muzou suplovat uceleny zdroje informaci ... :)
-
Aby tadle diskuze bylo rozseknutá, správně interpretuju že klonování (deep) je pro prototype OOP kriticky důležité?
ty hele - cetls ty odkazy co sem posilal? tam je to pekne vysvetleny - kriticky dulezity je si udelat cas a cist a premyslet a to aspon hodinu v kuse :) tyhle fora tezko muzou suplovat uceleny zdroje informaci ... :)
Včera sem na to detailně už nemrkal, proto sem jen rychle vyhodil otázku, to byl jeden důvod, ten druhej bylo zavřít tlamu zboji.
-
Nic proti, ale podle toho, co tady čtu, tak hubu bys možná konečně mohl zavřít ty ;-)
-
Architektura Javascriptu:
[10, 1, 5, 4, 2].sort();
/*
1,10,2,4,5
*/
Javascript nebrat
-
Nic proti, ale podle toho, co tady čtu, tak hubu bys možná konečně mohl zavřít ty ;-)
+1, ale trolly je lepší ignorovat ;)
-
Nic proti, ale podle toho, co tady čtu, tak hubu bys možná konečně mohl zavřít ty ;-)
No jo prosimtě ...
-
Architektura Javascriptu:
[10, 1, 5, 4, 2].sort();
/*
1,10,2,4,5
*/
Javascript nebrat
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort
If compareFunction is not supplied, elements are sorted by converting them to strings and comparing strings in Unicode code point order. For example, "Banana" comes before "cherry". In a numeric sort, 9 comes before 80, but because numbers are converted to strings, "80" comes before "9" in Unicode order.
:D blbče
-
Architektura Javascriptu II.
'12345'.replace('3', '$`')
/*
121245
*/
'12345'.replace('3', "$'")
/*
124545
*/
nebrat!
-
Nic proti, ale podle toho, co tady čtu, tak hubu bys možná konečně mohl zavřít ty ;-)
+1, ale trolly je lepší ignorovat ;)
Tak to nevim, co bys tu pak s bráchou dělal. Ani na blog by ti nikdo pak nepsal :-\
-
Architektura Javascriptu II.
'12345'.replace('3', '$`')
/*
121245
*/
'12345'.replace('3', "$'")
/*
124545
*/
nebrat!
Mohl bys tady laskavě přestat hrát hru "koukejte sem debil" ????
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace
Nascrolluj na "Specifying a string as a parameter" a čum dopiče
$` a $' jsou replacement patterns
-
Architektura Javascriptu II.
'12345'.replace('3', '$`')
/*
121245
*/
'12345'.replace('3', "$'")
/*
124545
*/
nebrat!
$` je část před matchem a $' je část za matchem. Funguje to tak i jinde. Nejen v JS.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace
-
Architektura Javascriptu II.
'12345'.replace('3', '$`')
/*
121245
*/
'12345'.replace('3', "$'")
/*
124545
*/
nebrat!
Mohl bys tady laskavě přestat hrát hru "koukejte sem debil" ????
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace
Nascrolluj na "Specifying a string as a parameter" a čum dopiče
$` a $' jsou replacement patterns
sorry, odpověděl jsem to stejné.
-
Objekt lze vytvořit více způsoby, konstruktor je jenom jedním z nich.
Ale jistě. V JavaScriptu se dá snad všechno udělat na sto způsobů. Jen některé z těch způsobů jsou jaksi zavedené a očekávané, jiné pak méně vhodné. Dělat něco jinak než zbytek jenom proto, že TO TAKY JDE(čumte, co jsem se včera naučil!) není ta správná cesta, pokud nehodláš do smrti dělat one-man show.
To je znak začínajících programátorů, použít právě naučené fancy věcičky, když by to šlo elegantně a jednoduše. Neštěstí je, když pak někdo normální musí ten prasokód (bez getterů, setterů, else, zato s milionem returnů a deep klonováním každého s prominutím h***a) číst. I v tom JS jde psát rozumně, jen to ten JS jaksi nevyžaduje :(
Zrovna gettery a settery jsou ten nejhloupější cargo kult.
Cargo kult je vzorec chování, nemůže označovat konkrétní věc nebo koncept. Nicméně používání cizích slov bez znalosti jejich významu a kontextu použití už by cargo kult být mohl. Hezky ses ztrapnil, ale teď místo kecání na fórech by ses mohl vrátit do školy (doslova nebo obrazně), ať příště nepůsobíš jako ta poslední lopata (doufám, že na toto slovo nemá patent tvé dvojče "javaman").
No ale zrovna zde použití "cargo kultu" je na místě. Ve smyslu, nadělám tam settery a gettery a moje aplikace bude stejně funkční, jako ty od "mistrů". Cargo kult = představa, že nápodobou pouze vnějších znaků se dosáhne stejného výsledku, jako kopírovaný originál. No a do toho zapadá přidělání setterů a getterů do aplikace bez vlastní představy o jejich smyslu. Obdobnými cargo kulty dnešní doby je euro, federalizace EU, tedy nápodoba vnějších znaků USA.
-
No ale zrovna zde použití "cargo kultu" je na místě. Ve smyslu, nadělám tam settery a gettery a moje aplikace bude stejně funkční, jako ty od "mistrů". Cargo kult = představa, že nápodobou pouze vnějších znaků se dosáhne stejného výsledku, jako kopírovaný originál. No a do toho zapadá přidělání setterů a getterů do aplikace bez vlastní představy o jejich smyslu. Obdobnými cargo kulty dnešní doby je euro, federalizace EU, tedy nápodoba vnějších znaků USA.
V Javascriptu jdou dopsat settery a gettery dodatečně až v případě potřeby. Proto je správné je nepoužívat a ignorovat neznalce jako Zboj, kteří to označí za prasokód.
-
V Javascriptu jdou dopsat settery a gettery dodatečně až v případě potřeby. Proto je správné je nepoužívat a ignorovat neznalce jako Zboj, kteří to označí za prasokód.
V OOP jsou gettery a settery zbytečné. Ani v Javascriptu nedávají smysl.
-
V OOP jsou gettery a settery zbytečné. Ani v Javascriptu nedávají smysl.
Také si to myslím.
-
V Javascriptu jdou dopsat settery a gettery dodatečně až v případě potřeby. Proto je správné je nepoužívat a ignorovat neznalce jako Zboj, kteří to označí za prasokód.
V OOP jsou gettery a settery zbytečné. Ani v Javascriptu nedávají smysl.
proc?
-
To jsi neměl dělat. Právě jsi spustil lavinu hoven.
-
V Javascriptu jdou dopsat settery a gettery dodatečně až v případě potřeby. Proto je správné je nepoužívat a ignorovat neznalce jako Zboj, kteří to označí za prasokód.
V OOP jsou gettery a settery zbytečné. Ani v Javascriptu nedávají smysl.
proc?
Už jsem to tady psal mnohokrát. Porušují zapouzdření objektu. Programátoři pak zbytečně píší výkonný kód mimo objekt místo toho, aby ho psali dovnitř. OOP je tak degradováno na trochu lepší strukturované programování.
-
V Javascriptu jdou dopsat settery a gettery dodatečně až v případě potřeby. Proto je správné je nepoužívat a ignorovat neznalce jako Zboj, kteří to označí za prasokód.
V OOP jsou gettery a settery zbytečné. Ani v Javascriptu nedávají smysl.
proc?
Už jsem to tady psal mnohokrát. Porušují zapouzdření objektu. Programátoři pak zbytečně píší výkonný kód mimo objekt místo toho, aby ho psali dovnitř. OOP je tak degradováno na trochu lepší strukturované programování.
takze kdyz budu mit zpravu "nastav jmeno" kterou poslu objektu ktery ji zpracuje tak ze zvaliduje jmeno a pojmenuje ho - tak tim porusuju zapouzdreni? tim padem si v OOP zakazal metody a zpravy ktere tam uz tak rikajic nejsou potreba ... vlastne OOP porusuje zapouzdreni objektu ... to se mi uplne nelibi clovece ...
-
takze kdyz budu mit zpravu "nastav jmeno" kterou poslu objektu ktery ji zpracuje tak ze zvaliduje jmeno a pojmenuje ho - tak tim porusuju zapouzdreni? tim padem si v OOP zakazal metody a zpravy ktere tam uz tak rikajic nejsou potreba ... vlastne OOP porusuje zapouzdreni objektu ... to se mi uplne nelibi clovece ...
Validace dat by neměla být svázána s ukládáním.
-
takze kdyz budu mit zpravu "nastav jmeno" kterou poslu objektu ktery ji zpracuje tak ze zvaliduje jmeno a pojmenuje ho - tak tim porusuju zapouzdreni? tim padem si v OOP zakazal metody a zpravy ktere tam uz tak rikajic nejsou potreba ... vlastne OOP porusuje zapouzdreni objektu ... to se mi uplne nelibi clovece ...
Validace dat by neměla být svázána s ukládáním.
hele todle neni zadek - Kit tady ted rozhoduje o dalsi existenci OOP jako takovyho a ty tu resis nakej design ...
-
takze kdyz budu mit zpravu "nastav jmeno" kterou poslu objektu ktery ji zpracuje tak ze zvaliduje jmeno a pojmenuje ho - tak tim porusuju zapouzdreni? tim padem si v OOP zakazal metody a zpravy ktere tam uz tak rikajic nejsou potreba ... vlastne OOP porusuje zapouzdreni objektu ... to se mi uplne nelibi clovece ...
Validace dat by neměla být svázána s ukládáním.
hele todle neni zadek - Kit tady ted rozhoduje o dalsi existenci OOP jako takovyho a ty tu resis nakej design ...
chtel sem napsat ze tohle neni zadna zadek - Kit tady ted rozhoduje o dalsi existenci OOP jako takovyho a ty tu resis nakej design ...
-
takze kdyz budu mit zpravu "nastav jmeno" kterou poslu objektu ktery ji zpracuje tak ze zvaliduje jmeno a pojmenuje ho - tak tim porusuju zapouzdreni? tim padem si v OOP zakazal metody a zpravy ktere tam uz tak rikajic nejsou potreba ... vlastne OOP porusuje zapouzdreni objektu ... to se mi uplne nelibi clovece ...
Validace dat by neměla být svázána s ukládáním.
hele todle neni zadek - Kit tady ted rozhoduje o dalsi existenci OOP jako takovyho a ty tu resis nakej design ...
chtel sem napsat ze tohle neni zadna zadek - Kit tady ted rozhoduje o dalsi existenci OOP jako takovyho a ty tu resis nakej design ...
aha - ono to meni p***l za zadek ... tohle forum me bavi cim dal vic :)
-
V Javascriptu jdou dopsat settery a gettery dodatečně až v případě potřeby. Proto je správné je nepoužívat a ignorovat neznalce jako Zboj, kteří to označí za prasokód.
V OOP jsou gettery a settery zbytečné. Ani v Javascriptu nedávají smysl.
proc?
Už jsem to tady psal mnohokrát. Porušují zapouzdření objektu. Programátoři pak zbytečně píší výkonný kód mimo objekt místo toho, aby ho psali dovnitř. OOP je tak degradováno na trochu lepší strukturované programování.
takze kdyz budu mit zpravu "nastav jmeno" kterou poslu objektu ktery ji zpracuje tak ze zvaliduje jmeno a pojmenuje ho - tak tim porusuju zapouzdreni? tim padem si v OOP zakazal metody a zpravy ktere tam uz tak rikajic nejsou potreba ... vlastne OOP porusuje zapouzdreni objektu ... to se mi uplne nelibi clovece ...
Ano tím porušujete zapouzdření, protože s objektem máte pracovat jako s celkem, a nemá být individualizovaný, individuální zpracování má být uvnitř objektu.
Takže když půjde o zpracování objektu zaměstnanec, tak kontrolu jména máte dělat uvnitř, třeba na základě databáze, ale ne takto map(update, [z for z in zamestnanci if z.get_jmeno() == "Jan"]), ale takto map(update, [z for z in zamestnanci if z.identify({jmeno: Jan})).
Dovnitř objektu poskytnete data k vyhledání, ale nijak neurčujete, jak se data mají vyhledat. V prvním případě to určuje to "==", algoritmus zpracování se dostal vně objektu. To má tu zásadní nevýhodu, že když chcete porovnávání změnit, například na "LIKE", tak to buď musíte změnit všude, kde se něco podobného vyskytuje, nebo přetížit operátor "==", což se vám jen tak nepodaří, protože to "==" bude kontextově závislé, takže jméno stejně budete muset obalit do nějakých jiných objektů.
Kdežto v druhém případě vám stačí změnit metodu identify. A je vymalováno. Vnější objekty nemusí vůbec znát jméno daného objektu. Identifikaci ke zpracování děláte obecnou metodou, která může mít různou implementaci v každé třídě. Změny pak provádíte jen v té třídě, které se to týká a o závislosti mezi vnějšími třídami se nemusíte starat. Dále identifikační metoda si může jen vyzobávat údaje, které potřebuje.
-
To jsi neměl dělat. Právě jsi spustil lavinu hoven.
Ano, zatímco páně thorn sežralo šalamounovo hovno, a ví jak je to dobře a ostatní jsou hádavý nicky ...
-
V Javascriptu jdou dopsat settery a gettery dodatečně až v případě potřeby. Proto je správné je nepoužívat a ignorovat neznalce jako Zboj, kteří to označí za prasokód.
V OOP jsou gettery a settery zbytečné. Ani v Javascriptu nedávají smysl.
proc?
Už jsem to tady psal mnohokrát. Porušují zapouzdření objektu. Programátoři pak zbytečně píší výkonný kód mimo objekt místo toho, aby ho psali dovnitř. OOP je tak degradováno na trochu lepší strukturované programování.
takze kdyz budu mit zpravu "nastav jmeno" kterou poslu objektu ktery ji zpracuje tak ze zvaliduje jmeno a pojmenuje ho - tak tim porusuju zapouzdreni? tim padem si v OOP zakazal metody a zpravy ktere tam uz tak rikajic nejsou potreba ... vlastne OOP porusuje zapouzdreni objektu ... to se mi uplne nelibi clovece ...
Ano tím porušujete zapouzdření, protože s objektem máte pracovat jako s celkem, a nemá být individualizovaný, individuální zpracování má být uvnitř objektu.
Takže když půjde o zpracování objektu zaměstnanec, tak kontrolu jména máte dělat uvnitř, třeba na základě databáze, ale ne takto map(update, [z for z in zamestnanci if z.get_jmeno() == "Jan"]), ale takto map(update, [z for z in zamestnanci if z.identify({jmeno: Jan})).
Dovnitř objektu poskytnete data k vyhledání, ale nijak neurčujete, jak se data mají vyhledat. V prvním případě to určuje to "==", algoritmus zpracování se dostal vně objektu. To má tu zásadní nevýhodu, že když chcete porovnávání změnit, například na "LIKE", tak to buď musíte změnit všude, kde se něco podobného vyskytuje, nebo přetížit operátor "==", což se vám jen tak nepodaří, protože to "==" bude kontextově závislé, takže jméno stejně budete muset obalit do nějakých jiných objektů.
Kdežto v druhém případě vám stačí změnit metodu identify. A je vymalováno. Vnější objekty nemusí vůbec znát jméno daného objektu. Identifikaci ke zpracování děláte obecnou metodou, která může mít různou implementaci v každé třídě. Změny pak provádíte jen v té třídě, které se to týká a o závislosti mezi vnějšími třídami se nemusíte starat. Dále identifikační metoda si může jen vyzobávat údaje, které potřebuje.
To je podle mne dobré vysvětlení, ačkoli gettery nebo settery toto neovlivní, jde o návrh. Jediný účinný krok by možná tak bylo zakázat z vnějšku přístup k jakémukoli datovému slotu. Ale i tak nic nezabrání uživateli udělat kupříkladu metodu getName() | setName() ...
-
Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer. Vhodne pouzitie je konfiguracia objektu a zistovanie jeho stavu.
Pouzivanie v objektoch, ktore su vlastne mudrejsie "structy" sa mi sice nepaci, ale niekedy je ozaj potrebne zmenit spravanie pri nastaveni fieldu (atributu). Vtedy sa to hodi.
-
V Javascriptu jdou dopsat settery a gettery dodatečně až v případě potřeby. Proto je správné je nepoužívat a ignorovat neznalce jako Zboj, kteří to označí za prasokód.
V OOP jsou gettery a settery zbytečné. Ani v Javascriptu nedávají smysl.
proc?
Už jsem to tady psal mnohokrát. Porušují zapouzdření objektu. Programátoři pak zbytečně píší výkonný kód mimo objekt místo toho, aby ho psali dovnitř. OOP je tak degradováno na trochu lepší strukturované programování.
takze kdyz budu mit zpravu "nastav jmeno" kterou poslu objektu ktery ji zpracuje tak ze zvaliduje jmeno a pojmenuje ho - tak tim porusuju zapouzdreni? tim padem si v OOP zakazal metody a zpravy ktere tam uz tak rikajic nejsou potreba ... vlastne OOP porusuje zapouzdreni objektu ... to se mi uplne nelibi clovece ...
Ano tím porušujete zapouzdření, protože s objektem máte pracovat jako s celkem, a nemá být individualizovaný, individuální zpracování má být uvnitř objektu.
Takže když půjde o zpracování objektu zaměstnanec, tak kontrolu jména máte dělat uvnitř, třeba na základě databáze, ale ne takto map(update, [z for z in zamestnanci if z.get_jmeno() == "Jan"]), ale takto map(update, [z for z in zamestnanci if z.identify({jmeno: Jan})).
Dovnitř objektu poskytnete data k vyhledání, ale nijak neurčujete, jak se data mají vyhledat. V prvním případě to určuje to "==", algoritmus zpracování se dostal vně objektu. To má tu zásadní nevýhodu, že když chcete porovnávání změnit, například na "LIKE", tak to buď musíte změnit všude, kde se něco podobného vyskytuje, nebo přetížit operátor "==", což se vám jen tak nepodaří, protože to "==" bude kontextově závislé, takže jméno stejně budete muset obalit do nějakých jiných objektů.
Kdežto v druhém případě vám stačí změnit metodu identify. A je vymalováno. Vnější objekty nemusí vůbec znát jméno daného objektu. Identifikaci ke zpracování děláte obecnou metodou, která může mít různou implementaci v každé třídě. Změny pak provádíte jen v té třídě, které se to týká a o závislosti mezi vnějšími třídami se nemusíte starat. Dále identifikační metoda si může jen vyzobávat údaje, které potřebuje.
To je podle mne dobré vysvětlení, ačkoli gettery nebo settery toto neovlivní, jde o návrh. Jediný účinný krok by možná tak bylo zakázat z vnějšku přístup k jakémukoli datovému slotu. Ale i tak nic nezabrání uživateli udělat kupříkladu metodu getName() | setName() ...
No právě, getName, setName je porušení objektového přístupu, něco jako goto ve strukturovaném programování. Použít ho smíte, ale ne jako základ tvorby kódu. Takže pokud se tomu vyhnete, budete mít méně práce v budoucnosti s úpravami.
Protože i když máte metodu getName, tak to stejně vede na konstrukce jako je tato:
$x = $this->getName().'_insert', takže to getName není ve skutečnosti getName, protože k identifikaci čehokoliv nestačí a je to spíše getNameSegment. Zase máte kus algoritmu mimo objekt a matoucí název metody z hlediska jejího reálného používání v systému.
-
https://www.youtube.com/watch?v=JC-VkFkKE8c
-
Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer. Vhodne pouzitie je konfiguracia objektu a zistovanie jeho stavu.
Pouzivanie v objektoch, ktore su vlastne mudrejsie "structy" sa mi sice nepaci, ale niekedy je ozaj potrebne zmenit spravanie pri nastaveni fieldu (atributu). Vtedy sa to hodi.
Konstruktory, které dělám, bývají obvykle na 2-6 řádek. Do kilometru to má daleko. Další konfigurace objektu už není potřebná. Není třeba zjišťovat stav objektu. Tell, don't ask.
Atributy si objekt musí umět nastavit sám podle zpráv, které mu chodí z okolí.
-
Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer. Vhodne pouzitie je konfiguracia objektu a zistovanie jeho stavu.
Pouzivanie v objektoch, ktore su vlastne mudrejsie "structy" sa mi sice nepaci, ale niekedy je ozaj potrebne zmenit spravanie pri nastaveni fieldu (atributu). Vtedy sa to hodi.
Konstruktory, které dělám, bývají obvykle na 2-6 řádek. Do kilometru to má daleko. Další konfigurace objektu už není potřebná. Není třeba zjišťovat stav objektu. Tell, don't ask.
Atributy si objekt musí umět nastavit sám podle zpráv, které mu chodí z okolí.
Nechci bejt rejpal, ale setName je taky příklad zprávy ...
-
Nechci bejt rejpal, ale setName je taky příklad zprávy ...
Z oblasti cargo kultu... ;-)
-
To jsi neměl dělat. Právě jsi spustil lavinu hoven.
+1
-
Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer. Vhodne pouzitie je konfiguracia objektu a zistovanie jeho stavu.
Pouzivanie v objektoch, ktore su vlastne mudrejsie "structy" sa mi sice nepaci, ale niekedy je ozaj potrebne zmenit spravanie pri nastaveni fieldu (atributu). Vtedy sa to hodi.
Konstruktory, které dělám, bývají obvykle na 2-6 řádek. Do kilometru to má daleko. Další konfigurace objektu už není potřebná. Není třeba zjišťovat stav objektu. Tell, don't ask.
Atributy si objekt musí umět nastavit sám podle zpráv, které mu chodí z okolí.
Idealna dlzka konstruktoru je tak 1 az 3 parametre. Ok, moze byt ich aj 6 ak je dovod (netreba bez rozmyslu vsetko striktne dodrziavat), ale 2 az 6 riadkov, to uz je trochu moc, strasne neprehladne. V redmonde take lubia.
K tomu Tell, don't ask - no ano, clovek potom da objektu robotu a caka pol dna, lebo nevie co to do certa robi. To tak ficalo v 60-tych rokoch pri davkovom spracovani.
-
Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer. Vhodne pouzitie je konfiguracia objektu a zistovanie jeho stavu.
Pouzivanie v objektoch, ktore su vlastne mudrejsie "structy" sa mi sice nepaci, ale niekedy je ozaj potrebne zmenit spravanie pri nastaveni fieldu (atributu). Vtedy sa to hodi.
Konstruktory, které dělám, bývají obvykle na 2-6 řádek. Do kilometru to má daleko. Další konfigurace objektu už není potřebná. Není třeba zjišťovat stav objektu. Tell, don't ask.
Atributy si objekt musí umět nastavit sám podle zpráv, které mu chodí z okolí.
Nechci bejt rejpal, ale setName je taky příklad zprávy ...
To je spíše příklad zneužití zprávy. Mérde. Je taky věta, ale silně meziobjektově kontextově závislá :-)))
-
Idealna dlzka konstruktoru je tak 1 az 3 parametre. Ok, moze byt ich aj 6 ak je dovod (netreba bez rozmyslu vsetko striktne dodrziavat), ale 2 az 6 riadkov, to uz je trochu moc, strasne neprehladne. V redmonde take lubia.
K tomu Tell, don't ask - no ano, clovek potom da objektu robotu a caka pol dna, lebo nevie co to do certa robi. To tak ficalo v 60-tych rokoch pri davkovom spracovani.
Pokud jsou v konstruktoru 1-3 parametry, je to tak akorát. Tomu obvykle odpovídá zmíněných 2-6 řádků konstruktoru. Někdo píše konstruktory s jedním parametrem třeba i na 10 řádek, ale to není můj případ.
Pravidlo Tell, don't ask má také své omezení. Například View v architektuře MVC ho porušuje a nikoho to netrápí.
-
Atributy si objekt musí umět nastavit sám podle zpráv, které mu chodí z okolí.
Nechci bejt rejpal, ale setName je taky příklad zprávy ...
setName() je zpráva s podivným názvem vytvářejícím iluzi, že objekt obsahuje atribut Name. Pokud chci objekt přejmenovat, obvykle použiji metodu s názvem rename() nebo update().
-
Idealna dlzka konstruktoru je tak 1 az 3 parametre. Ok, moze byt ich aj 6 ak je dovod (netreba bez rozmyslu vsetko striktne dodrziavat), ale 2 az 6 riadkov, to uz je trochu moc, strasne neprehladne. V redmonde take lubia.
K tomu Tell, don't ask - no ano, clovek potom da objektu robotu a caka pol dna, lebo nevie co to do certa robi. To tak ficalo v 60-tych rokoch pri davkovom spracovani.
Pokud jsou v konstruktoru 1-3 parametry, je to tak akorát. Tomu obvykle odpovídá zmíněných 2-6 řádků konstruktoru. Někdo píše konstruktory s jedním parametrem třeba i na 10 řádek, ale to není můj případ.
Pravidlo Tell, don't ask má také své omezení. Například View v architektuře MVC ho porušuje a nikoho to netrápí.
Vztah model-view v mvc je vzor observer. Tam je nutne aby si view tahal data z modelu, ked sa model zmeni. Ked tak rozmyslam behavioralne, vzory vsetky porusuju pravidlo "Tell don't ask".
Dovolim si tvrdit, ze je to skor vynimka ako pravidlo. Mozno si to viem predstavit, pri nejakych extremnych paralelnych vypoctoch, kde sa nepredpoklada interaktivita. Ale aj tam je obcas vhodne vediet, kde sa nieco zadrhlo.
-
Atributy si objekt musí umět nastavit sám podle zpráv, které mu chodí z okolí.
Nechci bejt rejpal, ale setName je taky příklad zprávy ...
setName() je zpráva s podivným názvem vytvářejícím iluzi, že objekt obsahuje atribut Name. Pokud chci objekt přejmenovat, obvykle použiji metodu s názvem rename() nebo update().
UPDATE ;D
-
Pravidlo Tell, don't ask má také své omezení. Například View v architektuře MVC ho porušuje a nikoho to netrápí.
Jak ho porušuje??
-
Pravidlo Tell, don't ask má také své omezení. Například View v architektuře MVC ho porušuje a nikoho to netrápí.
Jak ho porušuje??
Ked model zmeni svoj stav, tak view je notifikovany modelom, aby si stiahol nove data z modelu. Model si nasledne tieto data stiahne. Cize view si pyta vnutorny stav modelu, ktory by podla tejto zasady, ktoru nepoznam, nemal vediet.
-
Pravidlo Tell, don't ask má také své omezení. Například View v architektuře MVC ho porušuje a nikoho to netrápí.
Jak ho porušuje??
Ked model zmeni svoj stav, tak view je notifikovany modelom, aby si stiahol nove data z modelu. Model si nasledne tieto data stiahne. Cize view si pyta vnutorny stav modelu, ktory by podla tejto zasady, ktoru nepoznam, nemal vediet.
*view si nasledne tieto data stiahne. Neviem, na co zasa myslim, ach jo senilita.
-
ach jo senilita.
To je v pohodě, my jsme zvyklí ;)
-
Pravidlo Tell, don't ask má také své omezení. Například View v architektuře MVC ho porušuje a nikoho to netrápí.
Jak ho porušuje??
Ked model zmeni svoj stav, tak view je notifikovany modelom, aby si stiahol nove data z modelu. Model si nasledne tieto data stiahne. Cize view si pyta vnutorny stav modelu, ktory by podla tejto zasady, ktoru nepoznam, nemal vediet.
Tak mne napadá, co kdyby model místo notifikace rovnou poslal diff mezi old a new state ? View by si to pak přebralo.
-
Pravidlo Tell, don't ask má také své omezení. Například View v architektuře MVC ho porušuje a nikoho to netrápí.
Jak ho porušuje??
Ked model zmeni svoj stav, tak view je notifikovany modelom, aby si stiahol nove data z modelu. Model si nasledne tieto data stiahne. Cize view si pyta vnutorny stav modelu, ktory by podla tejto zasady, ktoru nepoznam, nemal vediet.
Tak mne napadá, co kdyby model místo notifikace rovnou poslal diff mezi old a new state ? View by si to pak přebralo.
To je vzor mediator, uz by to nebolo "celkom tak MVC"
-
Pravidlo Tell, don't ask má také své omezení. Například View v architektuře MVC ho porušuje a nikoho to netrápí.
Jak ho porušuje??
Ked model zmeni svoj stav, tak view je notifikovany modelom, aby si stiahol nove data z modelu. [View] si nasledne tieto data stiahne. Cize view si pyta vnutorny stav modelu, ktory by podla tejto zasady, ktoru nepoznam, nemal vediet.
To je skoro správně, ale nepřesné. Tu zásadu to neporušuje. Proč asi View čeká na notifikaci o změně Modelu, a neptá(!) se na ten stav přímo?
-
Pravidlo Tell, don't ask má také své omezení. Například View v architektuře MVC ho porušuje a nikoho to netrápí.
Jak ho porušuje??
Ked model zmeni svoj stav, tak view je notifikovany modelom, aby si stiahol nove data z modelu. [View] si nasledne tieto data stiahne. Cize view si pyta vnutorny stav modelu, ktory by podla tejto zasady, ktoru nepoznam, nemal vediet.
To je skoro správně, ale nepřesné. Tu zásadu to neporušuje. Proč asi View čeká na notifikaci o změně Modelu, a neptá(!) se na ten stav přímo?
Problem je, ze se "pta" na stav. To je uz samotne "asking", co by nemal robit.
-
Pravidlo Tell, don't ask má také své omezení. Například View v architektuře MVC ho porušuje a nikoho to netrápí.
Jak ho porušuje??
Ked model zmeni svoj stav, tak view je notifikovany modelom, aby si stiahol nove data z modelu. [View] si nasledne tieto data stiahne. Cize view si pyta vnutorny stav modelu, ktory by podla tejto zasady, ktoru nepoznam, nemal vediet.
To je skoro správně, ale nepřesné. Tu zásadu to neporušuje. Proč asi View čeká na notifikaci o změně Modelu, a neptá(!) se na ten stav přímo?
Problem je, ze se "pta" na stav. To je uz samotne "asking", co by nemal robit.
Přece View se na nic neptá, to ten změněný Model spouští řetězec událostí, podle kterých se View aktualizuje, nebo ne?
-
Přece View se na nic neptá, to ten změněný Model spouští řetězec událostí, podle kterých se View aktualizuje, nebo ne?
Bavíte se o webových aplikacích?
-
Přece View se na nic neptá, to ten změněný Model spouští řetězec událostí, podle kterých se View aktualizuje, nebo ne?
Bavíte se o webových aplikacích?
O architektonickom vzore MVC.
A podla mojho nazoru je to zlozitejsie napisane, ze sa view nakoniec spyta, ale ok, uz to necham tak.
Tieto akademicke debaty ma nikdy nebavili, preto som phd nedorobil.
-
Přece View se na nic neptá, to ten změněný Model spouští řetězec událostí, podle kterých se View aktualizuje, nebo ne?
Bavíte se o webových aplikacích?
O architektonickom vzore MVC.
A podla mojho nazoru je to zlozitejsie napisane, ze sa view nakoniec spyta, ale ok, uz to necham tak.
Tieto akademicke debaty ma nikdy nebavili, preto som phd nedorobil.
Mimo root jsem nepotkal akademika, který by se zabýval něčím podobným. S vědou to nemá nic společného.
To co píše Honza se mi moc nezdá. Já MVC rozumím tak, že View je funkce requestu a modelu, která vrátí response. Controler je funkce requestu, která vybere View. Modifikace modelu na tom nic nemění. Určitě existuje spousta interpretací. Tohle je jedna z nich, ze které vychází Django.
-
Problem je, ze se "pta" na stav. To je uz samotne "asking", co by nemal robit.
Přece View se na nic neptá, to ten změněný Model spouští řetězec událostí, podle kterých se View aktualizuje, nebo ne?
View dostane notifikaci (je vcelku jedno odkud), ale žádná data. Ta data si vyptá z Modelu a podle nich se aktualizuje. Není na tom nic špatného. Pouze to ukazuje, že pravidlo "Tell, don't ask" se nedá používat univerzálně na všechno. V rámci jednoho modulu je však velmi užitečné - v podstatě eliminuje potřebu většiny getterů.
-
To co píše Honza se mi moc nezdá. Já MVC rozumím tak, že View je funkce requestu a modelu, která vrátí response. Controler je funkce requestu, která vybere View. Modifikace modelu na tom nic nemění. Určitě existuje spousta interpretací. Tohle je jedna z nich, ze které vychází Django.
Interpretací architektury MVC je více a je v tom docela chaos. MVC se vyskytuje na různých úrovních aplikace a dokonce se dá najít i uvnitř každého objektu. Vypadá to, že Django to má vyřešeno docela dobře.
V mém webovém pojetí: Vše, co přijde metodou GET, je nasměrováno do View. Vše, co přijde metodou POST, je nasměrováno do Controlleru. Oba tyto moduly pracují s Modelem. View z něj pouze čte, Controller pouze zapisuje.
-
To co píše Honza se mi moc nezdá. Já MVC rozumím tak, že View je funkce requestu a modelu, která vrátí response. Controler je funkce requestu, která vybere View. Modifikace modelu na tom nic nemění. Určitě existuje spousta interpretací. Tohle je jedna z nich, ze které vychází Django.
Interpretací architektury MVC je více a je v tom docela chaos. MVC se vyskytuje na různých úrovních aplikace a dokonce se dá najít i uvnitř každého objektu. Vypadá to, že Django to má vyřešeno docela dobře.
V mém webovém pojetí: Vše, co přijde metodou GET, je nasměrováno do View. Vše, co přijde metodou POST, je nasměrováno do Controlleru. Oba tyto moduly pracují s Modelem. View z něj pouze čte, Controller pouze zapisuje.
Doufám, že je to zmatení pouze v pojmech, podle mě, pokud ten View Model pouze čte, tak to není porušení toho principu "Tell, Don't Ask", o kterém je řeč.
O interpretaci MVC vůbec nejde, ani o implementaci na serveru.
-
Přece View se na nic neptá, to ten změněný Model spouští řetězec událostí, podle kterých se View aktualizuje, nebo ne?
Bavíte se o webových aplikacích?
O architektonickom vzore MVC.
A podla mojho nazoru je to zlozitejsie napisane, ze sa view nakoniec spyta, ale ok, uz to necham tak.
Tieto akademicke debaty ma nikdy nebavili, preto som phd nedorobil.
Mimo root jsem nepotkal akademika, který by se zabýval něčím podobným. S vědou to nemá nic společného.
To co píše Honza se mi moc nezdá. Já MVC rozumím tak, že View je funkce requestu a modelu, která vrátí response. Controler je funkce requestu, která vybere View. Modifikace modelu na tom nic nemění. Určitě existuje spousta interpretací. Tohle je jedna z nich, ze které vychází Django.
Mno, to je computer science, a ja som tych akademikov stretol dost. Aplikacie sa rozrastaju a modularita, a potencialne rozsirenia oop su dost horuca tema. Bol som na aosd 2012 a na ecoop 2011. Tam sa mi nezdalo, ze by sa nikto tym nezaoberal.
-
To jsou nějaký lopaty, to nesmíš řešit. Taky by ses mohl týdny bavit o blbostech s kitem a nikam by to nevedlo.
-
Doufám, že je to zmatení pouze v pojmech, podle mě, pokud ten View Model pouze čte, tak to není porušení toho principu "Tell, Don't Ask", o kterém je řeč.
O interpretaci MVC vůbec nejde, ani o implementaci na serveru.
Ok, v akej literature je to vysvetlene? Pocujem to prvy krat, rad sa nieco nove dozviem.
-
Doufám, že je to zmatení pouze v pojmech, podle mě, pokud ten View Model pouze čte, tak to není porušení toho principu "Tell, Don't Ask", o kterém je řeč.
O interpretaci MVC vůbec nejde, ani o implementaci na serveru.
Ok, v akej literature je to vysvetlene? Pocujem to prvy krat, rad sa nieco nove dozviem.
Zkus začít třeba tady: https://www.zdrojak.cz/clanky/uvod-do-architektury-mvc/ (https://www.zdrojak.cz/clanky/uvod-do-architektury-mvc/)
-
Doufám, že je to zmatení pouze v pojmech, podle mě, pokud ten View Model pouze čte, tak to není porušení toho principu "Tell, Don't Ask", o kterém je řeč.
O interpretaci MVC vůbec nejde, ani o implementaci na serveru.
Ok, v akej literature je to vysvetlene? Pocujem to prvy krat, rad sa nieco nove dozviem.
Zkus začít třeba tady: https://www.zdrojak.cz/clanky/uvod-do-architektury-mvc/ (https://www.zdrojak.cz/clanky/uvod-do-architektury-mvc/)
Na tell don't ask som sa pytal. MVC, je pecene varene, najlepsi vyklad vzoru je v knizke od Gang of four.
Co je to ten zahadny "tell don't ask"?
-
Co je to ten zahadny "tell don't ask"?
Poměrně dobře vysvětleno a je tam i pár pravidel navíc:
https://pragprog.com/articles/tell-dont-ask (https://pragprog.com/articles/tell-dont-ask)
Motto: Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.
-
Pravidlo Tell, don't ask má také své omezení. Například View v architektuře MVC ho porušuje a nikoho to netrápí.
Jak ho porušuje??
Ked model zmeni svoj stav, tak view je notifikovany modelom, aby si stiahol nove data z modelu. Model si nasledne tieto data stiahne. Cize view si pyta vnutorny stav modelu, ktory by podla tejto zasady, ktoru nepoznam, nemal vediet.
Tak mne napadá, co kdyby model místo notifikace rovnou poslal diff mezi old a new state ? View by si to pak přebralo.
To je vzor mediator, uz by to nebolo "celkom tak MVC"
Ako pozeram, aj mate pravdu, existuju 2 pristupy k updatovaniu protokolu
K vzoru observer (vztah Model - View):
Avoiding observer-specific update protocols: the push and pull models. Implementations of the Observer pattern often have the subject broadcast additional information about the change. The subject passes this information as an argument to Update. The amount of information may vary widely.
At one extreme, which we call the push model, the subject sends observers detailed information about the change, whether they want it or not. At the other extreme is the pull model; the subject sends nothing but the most minimal notification, and observers ask for details explicitly thereafter.
The pull model emphasizes the subject’s ignorance of its observers, whereas the push model assumes subjects know something about their observers’ needs. The push model might make observers less reusable, because Subject classes make assumptions about Observer classes that might not always be true. On the other hand, the pull model may be inefficient, because Observer classes must ascertain what changed without help from the Subject.
-
Co je to ten zahadny "tell don't ask"?
Tady je to i s ilustračním obrázkem:
http://martinfowler.com/bliki/TellDontAsk.html (http://martinfowler.com/bliki/TellDontAsk.html)
-
Co je to ten zahadny "tell don't ask"?
Tady je to i s ilustračním obrázkem:
http://martinfowler.com/bliki/TellDontAsk.html (http://martinfowler.com/bliki/TellDontAsk.html)
Dakujem, toto je dokonca od jedneho z najvyssich iluminatov, bude to serious business.
Aspon nieco uzitocne z tejto diskusie ziskam.
-
Pravidlo Tell, don't ask má také své omezení. Například View v architektuře MVC ho porušuje a nikoho to netrápí.
Jak ho porušuje??
Ked model zmeni svoj stav, tak view je notifikovany modelom, aby si stiahol nove data z modelu. Model si nasledne tieto data stiahne. Cize view si pyta vnutorny stav modelu, ktory by podla tejto zasady, ktoru nepoznam, nemal vediet.
Tak mne napadá, co kdyby model místo notifikace rovnou poslal diff mezi old a new state ? View by si to pak přebralo.
To je vzor mediator, uz by to nebolo "celkom tak MVC"
Ako pozeram, aj mate pravdu, existuju 2 pristupy k updatovaniu protokolu
K vzoru observer (vztah Model - View):
Avoiding observer-specific update protocols: the push and pull models. Implementations of the Observer pattern often have the subject broadcast additional information about the change. The subject passes this information as an argument to Update. The amount of information may vary widely.
At one extreme, which we call the push model, the subject sends observers detailed information about the change, whether they want it or not. At the other extreme is the pull model; the subject sends nothing but the most minimal notification, and observers ask for details explicitly thereafter.
The pull model emphasizes the subject’s ignorance of its observers, whereas the push model assumes subjects know something about their observers’ needs. The push model might make observers less reusable, because Subject classes make assumptions about Observer classes that might not always be true. On the other hand, the pull model may be inefficient, because Observer classes must ascertain what changed without help from the Subject.
Je to v sekcii problemov, ktorym sa treba vyhnut. Zle citam.
Pull, je tahanie bez notifikacie.
Push je prave posielanie stavu subjektom (modelom).
Sorry, vraj sa to nema tak tobit.
-
Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer. Vhodne pouzitie je konfiguracia objektu a zistovanie jeho stavu.
Pouzivanie v objektoch, ktore su vlastne mudrejsie "structy" sa mi sice nepaci, ale niekedy je ozaj potrebne zmenit spravanie pri nastaveni fieldu (atributu). Vtedy sa to hodi.
Gettery a settery jsou především vznosným názvem pro jedny z mnoha metod, které zprostředkovávají komunikaci mezi vnějškem a vnitřkem objektu. Problémem je, že v mnoha začátečnících vyvolávají dojem, že každá vlastnost objektu má mít svůj getter a setter, což by skutečně vedlo na porušení zapouzdření u některých vlastností. Další chybou je, že u některých jazyků mají extra syntaktické řešení - zbytečnou komplikaci a jisté důsledky. Smalltalk se obešel bez nich, aniž by to čemukoliv vadilo.
-
Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer. Vhodne pouzitie je konfiguracia objektu a zistovanie jeho stavu.
Pouzivanie v objektoch, ktore su vlastne mudrejsie "structy" sa mi sice nepaci, ale niekedy je ozaj potrebne zmenit spravanie pri nastaveni fieldu (atributu). Vtedy sa to hodi.
Gettery a settery jsou především vznosným názvem pro jedny z mnoha metod, které zprostředkovávají komunikaci mezi vnějškem a vnitřkem objektu. Problémem je, že v mnoha začátečnících vyvolávají dojem, že každá vlastnost objektu má mít svůj getter a setter, což by skutečně vedlo na porušení zapouzdření u některých vlastností. Další chybou je, že u některých jazyků mají extra syntaktické řešení - zbytečnou komplikaci a jisté důsledky. Smalltalk se obešel bez nich, aniž by to čemukoliv vadilo.
No ale vtip OOP je přece v tom, že objekty svůj stav nekomunikují ven. A algoritmus na nich postavený se nemůže rozhodovat na základě znalosti stavů objektů, ale pouze na základě jimi zasílaných zpráv.
-
No ale vtip OOP je přece v tom, že objekty svůj stav nekomunikují ven. A algoritmus na nich postavený se nemůže rozhodovat na základě znalosti stavů objektů, ale pouze na základě jimi zasílaných zpráv.
To máš pravdu, ale dnes je v módě udělat anemický objekt (což je vlastně obyčejná struktura "obohacená" o gettery a settery) a k tomu několik servisních tříd, které s touto strukturou pracují. Sám nevím, co ty programátory k oddělování programu a datových struktur vede, když OOP je hlavně o tom, že algoritmy a datové struktury jsou zapouzdřeny uvnitř objektu a s okolím komunikují co nejméně prostřednictvím zmíněných zpráv.
-
No ale vtip OOP je přece v tom, že objekty svůj stav nekomunikují ven. A algoritmus na nich postavený se nemůže rozhodovat na základě znalosti stavů objektů, ale pouze na základě jimi zasílaných zpráv.
To máš pravdu, ale dnes je v módě udělat anemický objekt (což je vlastně obyčejná struktura "obohacená" o gettery a settery) a k tomu několik servisních tříd, které s touto strukturou pracují. Sám nevím, co ty programátory k oddělování programu a datových struktur vede, když OOP je hlavně o tom, že algoritmy a datové struktury jsou zapouzdřeny uvnitř objektu a s okolím komunikují co nejméně prostřednictvím zmíněných zpráv.
Co je k tomu vede? Vzpomínky na budoucnost, snaha vytvořit univerzální objekt, který nebude třeba nikdy upravovat, protože díky geterům a setterům je to složité.
-
...Pravidlo Tell, don't ask má také své omezení. Například View v architektuře MVC ho porušuje a nikoho to netrápí.
Pravidlo "Tell, don't ask" má jeden velký problém - nezohledňuje kompetence objektů - není možno po nějakém objektu chtít vypočítat nebo udělat něco, k čemu není kompetentní, tudíž místo tell bude muset volající objekt udělat ask, aby se dozvěděl informaci k výpočtu, který je kompetentní provést. Je to věc návrhu a rozmístění kompetencí do tříd.
-
No ale vtip OOP je přece v tom, že objekty svůj stav nekomunikují ven. A algoritmus na nich postavený se nemůže rozhodovat na základě znalosti stavů objektů, ale pouze na základě jimi zasílaných zpráv.
To máš pravdu, ale dnes je v módě udělat anemický objekt (což je vlastně obyčejná struktura "obohacená" o gettery a settery) a k tomu několik servisních tříd, které s touto strukturou pracují. Sám nevím, co ty programátory k oddělování programu a datových struktur vede, když OOP je hlavně o tom, že algoritmy a datové struktury jsou zapouzdřeny uvnitř objektu a s okolím komunikují co nejméně prostřednictvím zmíněných zpráv.
Pretoze niektore "objekty" su proste surove data, napriklad vytiahnute z databazy. Bolo by neprakticke a tazko udraziavatelne, napriklad povedat dokumentu, aby sa natiahol z databazy a zobrazil. A este neviem ako bez pomoci "structov". Ide o to, ze OOP nie je nikdy cisto objektove, ale je vzdy multiparadigmove.
-
Ked model zmeni svoj stav, tak view je notifikovany modelom, aby si stiahol nove data z modelu. Model si nasledne tieto data stiahne. Cize view si pyta vnutorny stav modelu, ktory by podla tejto zasady, ktoru nepoznam, nemal vediet.
1. Objekt sám určuje, které svoje vnitřní změny bude ven ventilovat, tj. nemá smysl opruzovat pozorovatele se změnou zvenku neviditelných stavů, protože zvenku se objekt jeví jako beze změny.
2. Může-li si view přečíst nějakou metodou nějaký stav (klidně i dopočítaný) objektu, je to veřejný stav.
-
Tak mne napadá, co kdyby model místo notifikace rovnou poslal diff mezi old a new state ? View by si to pak přebralo.
To jde. Má to několik úskalí:
1. Při nepozornosti může objekt na sebe napráskat něco, co se nemá dostat ven.
2. Na straně objektu i pozorovatele musíte mít aparát, který změnu zpracuje (a to i násobnou!), to poněkud komplikuje návrh.
-
To máš pravdu, ale dnes je v módě udělat anemický objekt (což je vlastně obyčejná struktura "obohacená" o gettery a settery) a k tomu několik servisních tříd, které s touto strukturou pracují. Sám nevím, co ty programátory k oddělování programu a datových struktur vede, když OOP je hlavně o tom, že algoritmy a datové struktury jsou zapouzdřeny uvnitř objektu a s okolím komunikují co nejméně prostřednictvím zmíněných zpráv.
Co je k tomu vede? Vzpomínky na budoucnost, snaha vytvořit univerzální objekt, který nebude třeba nikdy upravovat, protože díky geterům a setterům je to složité.
To zní jako nekonečné hledání "silver bullet". Tudy cesta opravdu nevede. Objekt má být kompetentní udělat nějakou kompletní práci. Pokud po něm chci jinou práci, musím vytvořit jiný objekt, který ji bude dělat.
-
No ale vtip OOP je přece v tom, že objekty svůj stav nekomunikují ven. A algoritmus na nich postavený se nemůže rozhodovat na základě znalosti stavů objektů, ale pouze na základě jimi zasílaných zpráv.
To máš pravdu, ale dnes je v módě udělat anemický objekt (což je vlastně obyčejná struktura "obohacená" o gettery a settery) a k tomu několik servisních tříd, které s touto strukturou pracují. Sám nevím, co ty programátory k oddělování programu a datových struktur vede, když OOP je hlavně o tom, že algoritmy a datové struktury jsou zapouzdřeny uvnitř objektu a s okolím komunikují co nejméně prostřednictvím zmíněných zpráv.
Pretoze niektore "objekty" su proste surove data, napriklad vytiahnute z databazy. Bolo by neprakticke a tazko udraziavatelne, napriklad povedat dokumentu, aby sa natiahol z databazy a zobrazil. A este neviem ako bez pomoci "structov". Ide o to, ze OOP nie je nikdy cisto objektove, ale je vzdy multiparadigmove.
Nesouhlasím, právě, že surová data mají zpracovávaná v rám objektu a nemají být tahaná ven.
customer = Customer().findByName(customer_name)
cart = Cart().findByCustomerName(customer_name)
order = Order().create(customer, order)
customer.sendOrder(order)
A sendOrder bude:
order.sendByMail(self._record['email'])
A žádná surová data z databáze nepotřebujete
-
No ale vtip OOP je přece v tom, že objekty svůj stav nekomunikují ven. A algoritmus na nich postavený se nemůže rozhodovat na základě znalosti stavů objektů, ale pouze na základě jimi zasílaných zpráv.
To máš pravdu, ale dnes je v módě udělat anemický objekt (což je vlastně obyčejná struktura "obohacená" o gettery a settery) a k tomu několik servisních tříd, které s touto strukturou pracují. Sám nevím, co ty programátory k oddělování programu a datových struktur vede, když OOP je hlavně o tom, že algoritmy a datové struktury jsou zapouzdřeny uvnitř objektu a s okolím komunikují co nejméně prostřednictvím zmíněných zpráv.
Pretoze niektore "objekty" su proste surove data, napriklad vytiahnute z databazy. Bolo by neprakticke a tazko udraziavatelne, napriklad povedat dokumentu, aby sa natiahol z databazy a zobrazil. A este neviem ako bez pomoci "structov". Ide o to, ze OOP nie je nikdy cisto objektove, ale je vzdy multiparadigmove.
Nesouhlasím, právě, že surová data mají zpracovávaná v rám objektu a nemají být tahaná ven.
customer = Customer().findByName(customer_name)
cart = Cart().findByCustomerName(customer_name)
order = Order().create(customer, order)
customer.sendOrder(order)
A sendOrder bude:
order.sendByMail(self._record['email'])
A žádná surová data z databáze nepotřebujete
Tu uz nastava miesanie zodpovednosti objektu, to nie je dobry napad.
-
...Pravidlo Tell, don't ask má také své omezení. Například View v architektuře MVC ho porušuje a nikoho to netrápí.
Pravidlo "Tell, don't ask" má jeden velký problém - nezohledňuje kompetence objektů - není možno po nějakém objektu chtít vypočítat nebo udělat něco, k čemu není kompetentní, tudíž místo tell bude muset volající objekt udělat ask, aby se dozvěděl informaci k výpočtu, který je kompetentní provést. Je to věc návrhu a rozmístění kompetencí do tříd.
To se pleteš. Objekt může být kompetentní něco vypočítat, ale jsou i další objekty, které jsou kompetentní úlohu rozdělit mezi jiné objekty. Takové objekty nepotřebují žádné informace k výpočtu, protože výpočet nedělají.
-
... dnes je v módě udělat anemický objekt (což je vlastně obyčejná struktura "obohacená" o gettery a settery) a k tomu několik servisních tříd, které s touto strukturou pracují. Sám nevím, co ty programátory k oddělování programu a datových struktur vede, když OOP je hlavně o tom, že algoritmy a datové struktury jsou zapouzdřeny uvnitř objektu a s okolím komunikují co nejméně prostřednictvím zmíněných zpráv.
Pretoze niektore "objekty" su proste surove data, napriklad vytiahnute z databazy. Bolo by neprakticke a tazko udraziavatelne, napriklad povedat dokumentu, aby sa natiahol z databazy a zobrazil. A este neviem ako bez pomoci "structov". Ide o to, ze OOP nie je nikdy cisto objektove, ale je vzdy multiparadigmove.
Surová data z databáze mám jako atribut objektu, který zná jejich strukturu a nemá tedy problém s nimi pracovat. Nemám důvod k tomu, aby tento datový "struct" byl mimo objekt s potřebnými metodami.
-
... dnes je v módě udělat anemický objekt (což je vlastně obyčejná struktura "obohacená" o gettery a settery) a k tomu několik servisních tříd, které s touto strukturou pracují. Sám nevím, co ty programátory k oddělování programu a datových struktur vede, když OOP je hlavně o tom, že algoritmy a datové struktury jsou zapouzdřeny uvnitř objektu a s okolím komunikují co nejméně prostřednictvím zmíněných zpráv.
Pretoze niektore "objekty" su proste surove data, napriklad vytiahnute z databazy. Bolo by neprakticke a tazko udraziavatelne, napriklad povedat dokumentu, aby sa natiahol z databazy a zobrazil. A este neviem ako bez pomoci "structov". Ide o to, ze OOP nie je nikdy cisto objektove, ale je vzdy multiparadigmove.
Surová data z databáze mám jako atribut objektu, který zná jejich strukturu a nemá tedy problém s nimi pracovat. Nemám důvod k tomu, aby tento datový "struct" byl mimo objekt s potřebnými metodami.
Problem nastane, ked bude treba menit napr zdroj dat. Data neprijdu z db, ale trebarz z queue, alebo webservisu. Najlepsie ak by mohli prist zo vsetkych troch, podla konfiguracie.
Ak ma objekt privela zodpovednosti, miesto toho, aby sa zamenil objekt na pristup k udajom (ktory ma standardne rozhranie vracajuce structy), je treba spravit skaredu zmenu logiky vo vnutri objektu. Nie je to dobre zbytocne to zvysuje previazanost zalezitosti, ktore by az tak previazane byt nemuseli.
-
Problem nastane, ked bude treba menit napr zdroj dat. Data neprijdu z db, ale trebarz z queue, alebo webservisu. Najlepsie ak by mohli prist zo vsetkych troch, podla konfiguracie.
Ak ma objekt privela zodpovednosti, miesto toho, aby sa zamenil objekt na pristup k udajom (ktory ma standardne rozhranie vracajuce structy), je treba spravit skaredu zmenu logiky vo vnutri objektu. Nie je to dobre zbytocne to zvysuje previazanost zalezitosti, ktore by az tak previazane byt nemuseli.
Problém nenastane, protože pro jiný zdroj dat napíši nový objekt se stejným rozhraním, ale jiným vnitřním chováním. Tím se rozdíly mezi těmito zdroji dat smáznou, budou se navenek chovat stejně.
-
No ale vtip OOP je přece v tom, že objekty svůj stav nekomunikují ven. A algoritmus na nich postavený se nemůže rozhodovat na základě znalosti stavů objektů, ale pouze na základě jimi zasílaných zpráv.
To máš pravdu, ale dnes je v módě udělat anemický objekt (což je vlastně obyčejná struktura "obohacená" o gettery a settery) a k tomu několik servisních tříd, které s touto strukturou pracují. Sám nevím, co ty programátory k oddělování programu a datových struktur vede, když OOP je hlavně o tom, že algoritmy a datové struktury jsou zapouzdřeny uvnitř objektu a s okolím komunikují co nejméně prostřednictvím zmíněných zpráv.
Pretoze niektore "objekty" su proste surove data, napriklad vytiahnute z databazy. Bolo by neprakticke a tazko udraziavatelne, napriklad povedat dokumentu, aby sa natiahol z databazy a zobrazil. A este neviem ako bez pomoci "structov". Ide o to, ze OOP nie je nikdy cisto objektove, ale je vzdy multiparadigmove.
Nesouhlasím, právě, že surová data mají zpracovávaná v rám objektu a nemají být tahaná ven.
customer = Customer().findByName(customer_name)
cart = Cart().findByCustomerName(customer_name)
order = Order().create(customer, order)
customer.sendOrder(order)
A sendOrder bude:
order.sendByMail(self._record['email'])
A žádná surová data z databáze nepotřebujete
Tu uz nastava miesanie zodpovednosti objektu, to nie je dobry napad.
Možná, takže to upravíme:
cart = Cart().fromRequest()
order = cart.createOrder()
order.send()
-
Ako pozeram, aj mate pravdu, existuju 2 pristupy k updatovaniu protokolu
K vzoru observer (vztah Model - View):
Avoiding observer-specific update protocols: the push and pull models. Implementations of the Observer pattern often have the subject broadcast additional information about the change. The subject passes this information as an argument to Update. The amount of information may vary widely.
At one extreme, which we call the push model, the subject sends observers detailed information about the change, whether they want it or not. At the other extreme is the pull model; the subject sends nothing but the most minimal notification, and observers ask for details explicitly thereafter.
The pull model emphasizes the subject’s ignorance of its observers, whereas the push model assumes subjects know something about their observers’ needs. The push model might make observers less reusable, because Subject classes make assumptions about Observer classes that might not always be true. On the other hand, the pull model may be inefficient, because Observer classes must ascertain what changed without help from the Subject.
Je to v sekcii problemov, ktorym sa treba vyhnut. Zle citam.
Pull, je tahanie bez notifikacie.
Push je prave posielanie stavu subjektom (modelom).
Sorry, vraj sa to nema tak tobit.
Čtete špatně, notifikace je vždy, pull znamená, že si to tahá sám pozorovatel, protože mimo notifikace mu nic nepřišlo.
-
Problem nastane, ked bude treba menit napr zdroj dat. Data neprijdu z db, ale trebarz z queue, alebo webservisu. Najlepsie ak by mohli prist zo vsetkych troch, podla konfiguracie.
Ak ma objekt privela zodpovednosti, miesto toho, aby sa zamenil objekt na pristup k udajom (ktory ma standardne rozhranie vracajuce structy), je treba spravit skaredu zmenu logiky vo vnutri objektu. Nie je to dobre zbytocne to zvysuje previazanost zalezitosti, ktore by az tak previazane byt nemuseli.
Problém nenastane, protože pro jiný zdroj dat napíši nový objekt se stejným rozhraním, ale jiným vnitřním chováním. Tím se rozdíly mezi těmito zdroji dat smáznou, budou se navenek chovat stejně.
To je priznak nedobreho navrhu mat tri objekty, ktore sa lisia len pristupom k datam a ine zalezitosti kopiruju. Pristup je jedna zalezitost. Povezme, ze dalsia zalezitost bude pristup do ERP kvoli fakturacii a tie ERP budu zasa 3. To uz sa zvysuje pocet konfiguracii objektu. To budete pisat x objektov, len preto, aby sa porusil nejaky princip "Tell don't ask", ktory nie je ani nikde poriadne zdokumentovany a preskunany?
-
Ako pozeram, aj mate pravdu, existuju 2 pristupy k updatovaniu protokolu
K vzoru observer (vztah Model - View):
Avoiding observer-specific update protocols: the push and pull models. Implementations of the Observer pattern often have the subject broadcast additional information about the change. The subject passes this information as an argument to Update. The amount of information may vary widely.
At one extreme, which we call the push model, the subject sends observers detailed information about the change, whether they want it or not. At the other extreme is the pull model; the subject sends nothing but the most minimal notification, and observers ask for details explicitly thereafter.
The pull model emphasizes the subject’s ignorance of its observers, whereas the push model assumes subjects know something about their observers’ needs. The push model might make observers less reusable, because Subject classes make assumptions about Observer classes that might not always be true. On the other hand, the pull model may be inefficient, because Observer classes must ascertain what changed without help from the Subject.
Je to v sekcii problemov, ktorym sa treba vyhnut. Zle citam.
Pull, je tahanie bez notifikacie.
Push je prave posielanie stavu subjektom (modelom).
Sorry, vraj sa to nema tak tobit.
Čtete špatně, notifikace je vždy, pull znamená, že si to tahá sám pozorovatel, protože mimo notifikace mu nic nepřišlo.
Pozrite si Odpověď #220 vas komentar bol zbytocny.
Odpověď #220
-
Ako pozeram, aj mate pravdu, existuju 2 pristupy k updatovaniu protokolu
K vzoru observer (vztah Model - View):
Avoiding observer-specific update protocols: the push and pull models. Implementations of the Observer pattern often have the subject broadcast additional information about the change. The subject passes this information as an argument to Update. The amount of information may vary widely.
At one extreme, which we call the push model, the subject sends observers detailed information about the change, whether they want it or not. At the other extreme is the pull model; the subject sends nothing but the most minimal notification, and observers ask for details explicitly thereafter.
The pull model emphasizes the subject’s ignorance of its observers, whereas the push model assumes subjects know something about their observers’ needs. The push model might make observers less reusable, because Subject classes make assumptions about Observer classes that might not always be true. On the other hand, the pull model may be inefficient, because Observer classes must ascertain what changed without help from the Subject.
Je to v sekcii problemov, ktorym sa treba vyhnut. Zle citam.
Pull, je tahanie bez notifikacie.
Push je prave posielanie stavu subjektom (modelom).
Sorry, vraj sa to nema tak tobit.
Čtete špatně, notifikace je vždy, pull znamená, že si to tahá sám pozorovatel, protože mimo notifikace mu nic nepřišlo.
Pozrite si Odpověď #220 vas komentar bol zbytocny.
Odpověď #220
U som zmotany, ziadny pull sa nedeje. Lebo pull je bez notifikacie o zmene, to je neziaduce.
-
Problem nastane, ked bude treba menit napr zdroj dat. Data neprijdu z db, ale trebarz z queue, alebo webservisu. Najlepsie ak by mohli prist zo vsetkych troch, podla konfiguracie.
Ak ma objekt privela zodpovednosti, miesto toho, aby sa zamenil objekt na pristup k udajom (ktory ma standardne rozhranie vracajuce structy), je treba spravit skaredu zmenu logiky vo vnutri objektu. Nie je to dobre zbytocne to zvysuje previazanost zalezitosti, ktore by az tak previazane byt nemuseli.
Problém nenastane, protože pro jiný zdroj dat napíši nový objekt se stejným rozhraním, ale jiným vnitřním chováním. Tím se rozdíly mezi těmito zdroji dat smáznou, budou se navenek chovat stejně.
To je priznak nedobreho navrhu mat tri objekty, ktore sa lisia len pristupom k datam a ine zalezitosti kopiruju. Pristup je jedna zalezitost. Povezme, ze dalsia zalezitost bude pristup do ERP kvoli fakturacii a tie ERP budu zasa 3. To uz sa zvysuje pocet konfiguracii objektu. To budete pisat x objektov, len preto, aby sa porusil nejaky princip "Tell don't ask", ktory nie je ani nikde poriadne zdokumentovany a preskunany?
Proč byste měl tři objekty? pro přístup k datům vložíte model se stejným rozhraním. To ten princip neporušuje, nebudete se ptát, jaký model zvolit, model prostě zvolíte. Celá aplikace bude pracovat s abstraktními rozhraními zpráv, reálná data se budou přesouvat teprve na úrovni modelu.
-
Problem nastane, ked bude treba menit napr zdroj dat. Data neprijdu z db, ale trebarz z queue, alebo webservisu. Najlepsie ak by mohli prist zo vsetkych troch, podla konfiguracie.
Ak ma objekt privela zodpovednosti, miesto toho, aby sa zamenil objekt na pristup k udajom (ktory ma standardne rozhranie vracajuce structy), je treba spravit skaredu zmenu logiky vo vnutri objektu. Nie je to dobre zbytocne to zvysuje previazanost zalezitosti, ktore by az tak previazane byt nemuseli.
Problém nenastane, protože pro jiný zdroj dat napíši nový objekt se stejným rozhraním, ale jiným vnitřním chováním. Tím se rozdíly mezi těmito zdroji dat smáznou, budou se navenek chovat stejně.
To je priznak nedobreho navrhu mat tri objekty, ktore sa lisia len pristupom k datam a ine zalezitosti kopiruju. Pristup je jedna zalezitost. Povezme, ze dalsia zalezitost bude pristup do ERP kvoli fakturacii a tie ERP budu zasa 3. To uz sa zvysuje pocet konfiguracii objektu. To budete pisat x objektov, len preto, aby sa porusil nejaky princip "Tell don't ask", ktory nie je ani nikde poriadne zdokumentovany a preskunany?
Proč byste měl tři objekty? pro přístup k datům vložíte model se stejným rozhraním. To ten princip neporušuje, nebudete se ptát, jaký model zvolit, model prostě zvolíte. Celá aplikace bude pracovat s abstraktními rozhraními zpráv, reálná data se budou přesouvat teprve na úrovni modelu.
Ok, idem radsej hulit, uz sa mi to neda rozmotat, co mi pisete. Zostal mi nejaky matros po reggae festivale.
-
Problém nenastane, protože pro jiný zdroj dat napíši nový objekt se stejným rozhraním, ale jiným vnitřním chováním. Tím se rozdíly mezi těmito zdroji dat smáznou, budou se navenek chovat stejně.
To je priznak nedobreho navrhu mat tri objekty, ktore sa lisia len pristupom k datam a ine zalezitosti kopiruju. Pristup je jedna zalezitost. Povezme, ze dalsia zalezitost bude pristup do ERP kvoli fakturacii a tie ERP budu zasa 3. To uz sa zvysuje pocet konfiguracii objektu. To budete pisat x objektov, len preto, aby sa porusil nejaky princip "Tell don't ask", ktory nie je ani nikde poriadne zdokumentovany a preskunany?
Ke všem třem objektům bude stejný přístup, protože budou mít stejné rozhraní. S každým datovým zdrojem však budou pracovat jinak. Dělám vždy tolik objektů, kolik potřebuji. Když přibude další datový zdroj, přidám další objekt, ale na předchozích třech nezměním ani čárku. Je to pouze využití polymorfismu.
Pokud potřebuji zkombinovat více objektů, stačí použít injekci závislostí.
Uniká mi, proč těch ERP bude zase 3. Má to nějakou souvislost s těmi třemi zdroji dat?
-
Problem nastane, ked bude treba menit napr zdroj dat. Data neprijdu z db, ale trebarz z queue, alebo webservisu. Najlepsie ak by mohli prist zo vsetkych troch, podla konfiguracie.
Ak ma objekt privela zodpovednosti, miesto toho, aby sa zamenil objekt na pristup k udajom (ktory ma standardne rozhranie vracajuce structy), je treba spravit skaredu zmenu logiky vo vnutri objektu. Nie je to dobre zbytocne to zvysuje previazanost zalezitosti, ktore by az tak previazane byt nemuseli.
Problém nenastane, protože pro jiný zdroj dat napíši nový objekt se stejným rozhraním, ale jiným vnitřním chováním. Tím se rozdíly mezi těmito zdroji dat smáznou, budou se navenek chovat stejně.
To je priznak nedobreho navrhu mat tri objekty, ktore sa lisia len pristupom k datam a ine zalezitosti kopiruju. Pristup je jedna zalezitost. Povezme, ze dalsia zalezitost bude pristup do ERP kvoli fakturacii a tie ERP budu zasa 3. To uz sa zvysuje pocet konfiguracii objektu. To budete pisat x objektov, len preto, aby sa porusil nejaky princip "Tell don't ask", ktory nie je ani nikde poriadne zdokumentovany a preskunany?
Proč byste měl tři objekty? pro přístup k datům vložíte model se stejným rozhraním. To ten princip neporušuje, nebudete se ptát, jaký model zvolit, model prostě zvolíte. Celá aplikace bude pracovat s abstraktními rozhraními zpráv, reálná data se budou přesouvat teprve na úrovni modelu.
V zadání jsou 3 zdroje dat, každý s jinou strukturou. Proto si k nim napíši 3 proxy se stejným rozhraním. Podle výběru zdroje pak v jedné proxy otevřu patřičný zdroj dat a tuto proxy injektuji do modelu. Aplikace pak bude pracovat pouze s modelem a nebude vůbec tušit, na který zdroj dat je navázán.
Dělám to tak zcela běžně. Je to velmi robustní řešení, které zjednodušuje model a umožňuje přidávat další zdroje dat bez zásahu do toho modelu.
-
No ale vtip OOP je přece v tom, že objekty svůj stav nekomunikují ven. A algoritmus na nich postavený se nemůže rozhodovat na základě znalosti stavů objektů, ale pouze na základě jimi zasílaných zpráv.
Asi si nerozumíme, ale objekt, ze kterého se nedostane ven vůbec nic, je k hovnu. Např. je v pořádku, kdy se optám na jméno pomocí Osoba.jmeno() a dostanu ho.
-
Problém nenastane, protože pro jiný zdroj dat napíši nový objekt se stejným rozhraním, ale jiným vnitřním chováním. Tím se rozdíly mezi těmito zdroji dat smáznou, budou se navenek chovat stejně.
To je priznak nedobreho navrhu mat tri objekty, ktore sa lisia len pristupom k datam a ine zalezitosti kopiruju. Pristup je jedna zalezitost. Povezme, ze dalsia zalezitost bude pristup do ERP kvoli fakturacii a tie ERP budu zasa 3. To uz sa zvysuje pocet konfiguracii objektu. To budete pisat x objektov, len preto, aby sa porusil nejaky princip "Tell don't ask", ktory nie je ani nikde poriadne zdokumentovany a preskunany?
Ke všem třem objektům bude stejný přístup, protože budou mít stejné rozhraní. S každým datovým zdrojem však budou pracovat jinak. Dělám vždy tolik objektů, kolik potřebuji. Když přibude další datový zdroj, přidám další objekt, ale na předchozích třech nezměním ani čárku. Je to pouze využití polymorfismu.
Pokud potřebuji zkombinovat více objektů, stačí použít injekci závislostí.
Uniká mi, proč těch ERP bude zase 3. Má to nějakou souvislost s těmi třemi zdroji dat?
Myslim, ze to nie je stastny priklad polymorfizmu. Polymorfizmus sluzi na vyjadrenie vlastnosti objektu, nie ako barlicka proti kopirovaniu kodu.
Pokud potřebuji zkombinovat více objektů, stačí použít injekci závislostí.
Tak by som to riesil aj ja, to je o com pisem. Princip "Tell don't ask" dostava na zadek a redukuje sa na "komponenty" (tzv zhluky objektov).
Uniká mi, proč těch ERP bude zase 3. Má to nějakou souvislost s těmi třemi zdroji dat?
So zdrojmi dat by to nemalo suvislost. To som uviedol ako priklad dalsej zalezitosti "fakturacia"
-
To máš pravdu, ale dnes je v módě udělat anemický objekt (což je vlastně obyčejná struktura "obohacená" o gettery a settery) a k tomu několik servisních tříd, které s touto strukturou pracují. Sám nevím, co ty programátory k oddělování programu a datových struktur vede, když OOP je hlavně o tom, že algoritmy a datové struktury jsou zapouzdřeny uvnitř objektu a s okolím komunikují co nejméně prostřednictvím zmíněných zpráv.
Co je k tomu vede? Vzpomínky na budoucnost, snaha vytvořit univerzální objekt, který nebude třeba nikdy upravovat, protože díky geterům a setterům je to složité.
Ale vůbec ne. Důvodem je zvyk ze strukturovaného programování, kdy data se válejí někde (nejlépe globálně dostupné) a operace k nim jinde, a neschopnost rozlišit rozsahy problémů a podproblémů a jejich rozčlenění do tříd - to především.
-
No ale vtip OOP je přece v tom, že objekty svůj stav nekomunikují ven. A algoritmus na nich postavený se nemůže rozhodovat na základě znalosti stavů objektů, ale pouze na základě jimi zasílaných zpráv.
Asi si nerozumíme, ale objekt, ze kterého se nedostane ven vůbec nic, je k hovnu. Např. je v pořádku, kdy se optám na jméno pomocí Osoba.jmeno() a dostanu ho.
Není to v pořádku. Objekt tě s tímto požadavkem může poslat do háje, pokud k tomu nemáš kompetenci.
-
Asi si nerozumíme, ale objekt, ze kterého se nedostane ven vůbec nic, je k hovnu. Např. je v pořádku, kdy se optám na jméno pomocí Osoba.jmeno() a dostanu ho.
Není to v pořádku. Objekt tě s tímto požadavkem může poslat do háje, pokud k tomu nemáš kompetenci.
Samozřejmě. Proto se ptám, zda si rozumíme, když tu někdo chce na druhou stranu vyrábět objekty, ze kterých nic neleze.
-
Asi si nerozumíme, ale objekt, ze kterého se nedostane ven vůbec nic, je k hovnu. Např. je v pořádku, kdy se optám na jméno pomocí Osoba.jmeno() a dostanu ho.
Není to v pořádku. Objekt tě s tímto požadavkem může poslat do háje, pokud k tomu nemáš kompetenci.
Samozřejmě. Proto se ptám, zda si rozumíme, když tu někdo chce na druhou stranu vyrábět objekty, ze kterých nic neleze.
To byla reakce na Osoba.jmeno() - ten zápis tedy vypadá hodně divně, protože porušuje nejméně 2 konvence.
Objekty, ze kterých nic neleze, mohou mít význam, pokud mají nějaký side-effect. Často však dělám objekty, které mají pouze jeden stringový výstup a víc jich ani nepotřebují. Takže v daném případě by místo Osoba.jmeno() bylo jen např.
echo $osoba;což by poskytlo právě požadované jméno osoby.
-
To byla reakce na Osoba.jmeno() - ten zápis tedy vypadá hodně divně, protože porušuje nejméně 2 konvence.
Které? Jestli máte na mysli chybějící get, tak upozorňuju, že tato konvence snižuje čitelnost, vizte Smalltalk, takže není lepší než jiné.
Tu druhou netuším.
Objekty, ze kterých nic neleze, mohou mít význam, pokud mají nějaký side-effect...
Pravda, na to jsem zapomněl - změna může být propagována do složených objektů, které již výstupy mají.
-
To byla reakce na Osoba.jmeno() - ten zápis tedy vypadá hodně divně, protože porušuje nejméně 2 konvence.
Které? Jestli máte na mysli chybějící get, tak upozorňuju, že tato konvence snižuje čitelnost, vizte Smalltalk, takže není lepší než jiné.
Tu druhou netuším.
- Názvy objektů se obvykle píší s malým písmenem na začátku, aby se to nepletlo s třídou.
- Názvy metod se obvykle volí ze sloves, aby se to nepletlo s objekty či atributy. Zápis tak vytváří holou větu.
- "get" mi opravdu nechybělo.
-
- Názvy objektů se obvykle píší s malým písmenem na začátku, aby se to nepletlo s třídou.
Zde jsem opravdu myslel třídu, za kterou někde bude instance.
- Názvy metod se obvykle volí ze sloves, aby se to nepletlo s objekty či atributy. Zápis tak vytváří holou větu.
- "get" mi opravdu nechybělo.
Konvenci nemá smysl rozebírat, existuje jich více. Smalltalk naopak z důvodu čitelnosti pro pasivní metody (bez postranních efektů) používá podstatná jména (tak, jak jsem to použil), pro operace slovesa, get pro čtení vlastností nepoužívá z důvodu nadbytečnosti vůbec.
-
No ale vtip OOP je přece v tom, že objekty svůj stav nekomunikují ven. A algoritmus na nich postavený se nemůže rozhodovat na základě znalosti stavů objektů, ale pouze na základě jimi zasílaných zpráv.
To máš pravdu, ale dnes je v módě udělat anemický objekt (což je vlastně obyčejná struktura "obohacená" o gettery a settery) a k tomu několik servisních tříd, které s touto strukturou pracují. Sám nevím, co ty programátory k oddělování programu a datových struktur vede, když OOP je hlavně o tom, že algoritmy a datové struktury jsou zapouzdřeny uvnitř objektu a s okolím komunikují co nejméně prostřednictvím zmíněných zpráv.
Já bych věděl, ale nebude se ti to líbit.
Jedním z důvodů je v tom, že drtivá většina vývojářů OOP prostě neovládá. Navrhnout aplikaci objektově dobře není vůbec triviální.
Další důvod proč používat anemické objekty a servisní třídy je snaha o vyřešení problémů které OOP přináší. Někdy, někdy často, je kód v OOP děsně pitomej.
-
Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer.
To je zase zaměnění příčiny a následku.
Posuzování, zda použiju konstruktor nebo setter podle toho, jak ten konsturktor bude dlouhej není programování, ale pohodlnost.
Konstruktor slouží k tomu, aby se vytvořil objekt.
Setter k tomu, aby se změnil stav objektu z jednoho validního stavu na jiný validní.
To, že v případě rozsáhlejch struktur jsou často většina hodnot volitelná je shoda okolností vedoucí k mylné představě, že settery jsou jen jinej způsob jak plnit objekt daty.
Druhej extrém je Kitova představa, že settery jsou nějakým specielním způsobem vždy špatné.
-
Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer.
To je zase zaměnění příčiny a následku.
Posuzování, zda použiju konstruktor nebo setter podle toho, jak ten konsturktor bude dlouhej není programování, ale pohodlnost.
Konstruktor slouží k tomu, aby se vytvořil objekt.
Setter k tomu, aby se změnil stav objektu z jednoho validního stavu na jiný validní.
To, že v případě rozsáhlejch struktur jsou často většina hodnot volitelná je shoda okolností vedoucí k mylné představě, že settery jsou jen jinej způsob jak plnit objekt daty.
Druhej extrém je Kitova představa, že settery jsou nějakým specielním způsobem vždy špatné.
Tak to je otázka filosofického rázu, zda do objektu injektovat fakta, tedy je vně objektu interpretovat a nebo mu předávat událostim či žádosti a jejich interpretaci nechat na něm. Myslím, že druhý způsob je vhodnější, protože neporušuje zapouzdření a vylepšuje flexibilitu systému omezením závislostí mezi objekty. Nestaráte se o to, co jak daný objekt dělá, ale o to, co po něm požadujete aby dělal.
-
Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer.
To je zase zaměnění příčiny a následku.
Posuzování, zda použiju konstruktor nebo setter podle toho, jak ten konsturktor bude dlouhej není programování, ale pohodlnost.
Konstruktor slouží k tomu, aby se vytvořil objekt.
Setter k tomu, aby se změnil stav objektu z jednoho validního stavu na jiný validní.
To, že v případě rozsáhlejch struktur jsou často většina hodnot volitelná je shoda okolností vedoucí k mylné představě, že settery jsou jen jinej způsob jak plnit objekt daty.
Druhej extrém je Kitova představa, že settery jsou nějakým specielním způsobem vždy špatné.
Tak to je otázka filosofického rázu, zda do objektu injektovat fakta, tedy je vně objektu interpretovat a nebo mu předávat událostim či žádosti a jejich interpretaci nechat na něm. Myslím, že druhý způsob je vhodnější, protože neporušuje zapouzdření a vylepšuje flexibilitu systému omezením závislostí mezi objekty. Nestaráte se o to, co jak daný objekt dělá, ale o to, co po něm požadujete aby dělal.
Narážím na toto:
Person obj = factory.get() // někde seber nějaký objekt, ať nemáme konstruktor
obj.toString() // -> "Jmeno: NULL, Příjmení: NULL"
Pokud si rozumíme, tak rozhodně nesouhlasím, že by tam byl nějaký prostor k více možným přístupům. Vytvářet nemocné objekty (nedejbože z důvodu pohodlnosti) není dobrý způsob.
-
To je zase zaměnění příčiny a následku.
Posuzování, zda použiju konstruktor nebo setter podle toho, jak ten konsturktor bude dlouhej není programování, ale pohodlnost.
Konstruktor slouží k tomu, aby se vytvořil objekt.
Setter k tomu, aby se změnil stav objektu z jednoho validního stavu na jiný validní.
To, že v případě rozsáhlejch struktur jsou často většina hodnot volitelná je shoda okolností vedoucí k mylné představě, že settery jsou jen jinej způsob jak plnit objekt daty.
Druhej extrém je Kitova představa, že settery jsou nějakým specielním způsobem vždy špatné.
Souhlasím.
-
Tak to je otázka filosofického rázu, zda do objektu injektovat fakta, tedy je vně objektu interpretovat a nebo mu předávat událostim či žádosti a jejich interpretaci nechat na něm. Myslím, že druhý způsob je vhodnější, protože neporušuje zapouzdření a vylepšuje flexibilitu systému omezením závislostí mezi objekty. Nestaráte se o to, co jak daný objekt dělá, ale o to, co po něm požadujete aby dělal.
O tom se nikdo nehádá (nebo si nerozumíme), od toho má objekt veřejné metody (včetně nadbytečných getterů a setterů), aby jimi přistrkoval informace sem a tam, případně je při tom přemlel - jeho věc. To je podstatou OOP (i když tu někteří budou vysvětlovat, jak vlastně zapouzdření není potřeba).
-
No ale vtip OOP je přece v tom, že objekty svůj stav nekomunikují ven. A algoritmus na nich postavený se nemůže rozhodovat na základě znalosti stavů objektů, ale pouze na základě jimi zasílaných zpráv.
To máš pravdu, ale dnes je v módě udělat anemický objekt (což je vlastně obyčejná struktura "obohacená" o gettery a settery) a k tomu několik servisních tříd, které s touto strukturou pracují. Sám nevím, co ty programátory k oddělování programu a datových struktur vede, když OOP je hlavně o tom, že algoritmy a datové struktury jsou zapouzdřeny uvnitř objektu a s okolím komunikují co nejméně prostřednictvím zmíněných zpráv.
Já bych věděl, ale nebude se ti to líbit.
Jedním z důvodů je v tom, že drtivá většina vývojářů OOP prostě neovládá. Navrhnout aplikaci objektově dobře není vůbec triviální.
Další důvod proč používat anemické objekty a servisní třídy je snaha o vyřešení problémů které OOP přináší. Někdy, někdy často, je kód v OOP děsně pitomej.
Naopak, ten první důvod se mi líbí.
Pro vyřešení druhého důvodu jsou dva způsoby, které se hodí v různých situacích. Prvním je vzor Messenger, druhým je myšlenkové spojení anemické a servisní třídy do jedné řádné třídy a patřičná úprava. V obou případech gettery zmizí.
Když prostě někde vidím gettery či settery, hned vidím příležitost pro refaktorování.
-
Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer.
To je zase zaměnění příčiny a následku.
Posuzování, zda použiju konstruktor nebo setter podle toho, jak ten konsturktor bude dlouhej není programování, ale pohodlnost.
Konstruktor slouží k tomu, aby se vytvořil objekt.
Setter k tomu, aby se změnil stav objektu z jednoho validního stavu na jiný validní.
To, že v případě rozsáhlejch struktur jsou často většina hodnot volitelná je shoda okolností vedoucí k mylné představě, že settery jsou jen jinej způsob jak plnit objekt daty.
Druhej extrém je Kitova představa, že settery jsou nějakým specielním způsobem vždy špatné.
I tohle se mi líbí. Svou představu možná prezentuji extrémisticky, ale pokud bych ji prezentoval příliš "fuzzy", tak by to bylo dlouhé a nepřehledné. Uznávám, že někdy mám tu Occamovu břitvu nabroušenou až moc.
-
Když prostě někde vidím gettery či settery, hned vidím příležitost pro refaktorování.
Co třeba něco praktického, místo akademických debat?
https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/Code/CryEngine/CryEntitySystem/Entity.h
nějakých 50 getterů a setterů v jedné třídě... Fakt bych chtěl vidět, jak to zrefaktoruješ, aniž by to stálo výkon nebo přehlednost...
-
Když prostě někde vidím gettery či settery, hned vidím příležitost pro refaktorování.
Co třeba něco praktického, místo akademických debat?
https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/Code/CryEngine/CryEntitySystem/Entity.h
nějakých 50 getterů a setterů v jedné třídě... Fakt bych chtěl vidět, jak to zrefaktoruješ, aniž by to stálo výkon nebo přehlednost...
Pro začátek by stačilo tu třídu rozdělit, protože 548 řádek a ta hromada atributů si o to vyloženě koledují. Troufám si tvrdit, že výkon by o něco vzrostl a přehlednost také.
Tohle však nemá s OOP mnoho společného. Je to v C++.
-
Pro začátek by stačilo tu třídu rozdělit, protože 548 řádek a ta hromada atributů si o to vyloženě koledují. Troufám si tvrdit, že výkon by o něco vzrostl a přehlednost také.
Jak rozdělit? Co bys dal kam? Je to entita, všechno k sobě logicky patří.
Tohle však nemá s OOP mnoho společného. Je to v C++.
Kecy v kleci.
-
Když prostě někde vidím gettery či settery, hned vidím příležitost pro refaktorování.
Co třeba něco praktického, místo akademických debat?
https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/Code/CryEngine/CryEntitySystem/Entity.h
nějakých 50 getterů a setterů v jedné třídě... Fakt bych chtěl vidět, jak to zrefaktoruješ, aniž by to stálo výkon nebo přehlednost...
Já tam např. vidím spoustu metod, které berou jako parametr index slotu (nSlot). To by stálo za to schovat třeba pod metodu slots(..), vracející interface, kde by stejné metody již nemusely obsahovat tento index, protože by pracovaly již s konkrétním slotem.
entity->slots(1)->IsSlotValid() místo entity->IsSlotValid(1)
-
Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer.
To je zase zaměnění příčiny a následku.
Posuzování, zda použiju konstruktor nebo setter podle toho, jak ten konsturktor bude dlouhej není programování, ale pohodlnost.
Konstruktor slouží k tomu, aby se vytvořil objekt.
Setter k tomu, aby se změnil stav objektu z jednoho validního stavu na jiný validní.
To, že v případě rozsáhlejch struktur jsou často většina hodnot volitelná je shoda okolností vedoucí k mylné představě, že settery jsou jen jinej způsob jak plnit objekt daty.
Druhej extrém je Kitova představa, že settery jsou nějakým specielním způsobem vždy špatné.
Posuzování, zda použiju konstruktor nebo setter podle toho, jak ten konsturktor bude dlouhej není programování, ale pohodlnost.
Nie pohodlnost, ale zdravy rozum. Vyplnit kilometrovy konstruktor, tam je trosku o hubu zistit poriadne, co kam ide.
Konstruktor sluzi predovsetkym na konfiguraciu objektu, to ze sa zhodou okolnosti pouziva aj na vytvorenie objeku je vedlajsia vec. Na vytvorenie objektu sa daju pouzit aj rozne factory metody/funkcie.
Jediny dovod konfigurovat vsetko v konstuktore je, ked je potrebny immutable objekt a vsetky fieldy su kvoli paranoji nastavene na filnal. (v jave)
Ja viem, ze som asi uchylny javista, ale bezny workflow je - Instancovat objekt, nakonfigurovat (nainjektovat), pustit init metodu objektu, ked je vsetko vo spravnom stave. Ak to nerobi uz framework, tak to takto spravim rucne.
Menenie "stavu" objektu by sa nemalo robit cez setter (pokial sa tym mysli nieco viac nez konfiguracia). Ale prihodne nazvanou metodou typu changeKillingState(State.NOT_KILLING)
-
Co třeba něco praktického, místo akademických debat?
https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/Code/CryEngine/CryEntitySystem/Entity.h
nějakých 50 getterů a setterů v jedné třídě... Fakt bych chtěl vidět, jak to zrefaktoruješ, aniž by to stálo výkon nebo přehlednost...
Já tam např. vidím spoustu metod, které berou jako parametr index slotu (nSlot). To by stálo za to schovat třeba pod metodu slots(..), vracející interface, kde by stejné metody již nemusely obsahovat tento index, protože by pracovaly již s konkrétním slotem.
entity->slots(1)->IsSlotValid() místo entity->IsSlotValid(1)
Tohle je na trochu delší refaktorování. Nejprve bych volání
if (m_slot == -1) {
m_slot = 0;
while (GetEntity()->IsSlotValid(m_slot))
m_slot++;
}převedl na jednodušší
m_slot = entity->getSlot();který mi dodá první validní slot.
Getter mi zůstal, takže pokračuji. Objekt entity bude obsahovat atribut slot třídy Slot. Třída Slot bude obsahovat metody pro vytvoření, změnu a případně i zánik slotu z nějakého poolu. Pool bude tyto sloty přidělovat.
Vše, co bude užívat metodu entity->getSlot() přesunu do třídy Slot. Takže například hromadu cyklů
for (int i = 0; i < pEnt->GetSlotCount(); ++i)
přemístím do třídy Slots a požadovanou operaci nad všemi sloty injektuji do nějakých metod dle potřeby.
Jak jsem již psal, je to na delší refaktorování, ale výsledkem by byl čistší, kratší, rychlejší, přehlednější a robustnější kód. Podstatné je, aby s atributem m_slot pracovala pouze třída Slot, o správu poolu slotů zase jen kolekce Slots.
... a to je vlastně jen refaktorování jednoho atributu.
-
Posuzování, zda použiju konstruktor nebo setter podle toho, jak ten konsturktor bude dlouhej není programování, ale pohodlnost.
Nie pohodlnost, ale zdravy rozum. Vyplnit kilometrovy konstruktor, tam je trosku o hubu zistit poriadne, co kam ide.
Konstruktor sluzi predovsetkym na konfiguraciu objektu, to ze sa zhodou okolnosti pouziva aj na vytvorenie objeku je vedlajsia vec. Na vytvorenie objektu sa daju pouzit aj rozne factory metody/funkcie.
Jediny dovod konfigurovat vsetko v konstuktore je, ked je potrebny immutable objekt a vsetky fieldy su kvoli paranoji nastavene na filnal. (v jave)
Ja viem, ze som asi uchylny javista, ale bezny workflow je - Instancovat objekt, nakonfigurovat (nainjektovat), pustit init metodu objektu, ked je vsetko vo spravnom stave. Ak to nerobi uz framework, tak to takto spravim rucne.
Menenie "stavu" objektu by sa nemalo robit cez setter (pokial sa tym mysli nieco viac nez konfiguracia). Ale prihodne nazvanou metodou typu changeKillingState(State.NOT_KILLING)
Co máš pořád s tím kilometrovým konstruktorem? Když má konstruktor obvykle 1-3 parametry, tak takový konstruktor má do kilometru hóódně daleko.
Atributy objektu mohou být finální a často je v této podobě používám. To abych si je náhodou nezměnil. Immutable objekty se hodí pro implementaci vzoru Messenger - nejsou pak potřebné gettery ani settery.
Metodu pro init objektu by měl volat už konstruktor. Neinicializovaný objekt zřejmě nebude validní a je tedy k ničemu.
Místo nevhodného
state->changeKillingState(State.NOT_KILLING)bych raději zvolil mnohem jednodušší
state->noKill()nebo něco podobného.
-
Tohle je na trochu delší refaktorování. Nejprve bych volání
Ty jsi nepochopil, k čemu ty sloty jsou, že? Primárně pro LUA skriptery, kteří si do nich strkají svoje věci. Vyhodit funkcionalitu ohledně slotů do zvlášní třídy na první pohled dává smysl, jenže skripteři to tak používat nechtějí. Oni chtěljí jednoduchý interface s číslem slotu na entitě. Jasně, můžeš tam mít dva různé interface, jeden pro skript a jiný pro C++ engine a mapovat to mezi sebou, ale nic to nepřinese, kód bude delší, složitější a pomalejší. Mimochodem po tom tvém "refaktoringu" by to nebylo ani rychlejší, ani jednodušší.
-
Tohle je na trochu delší refaktorování. Nejprve bych volání
Ty jsi nepochopil, k čemu ty sloty jsou, že? Primárně pro LUA skriptery, kteří si do nich strkají svoje věci. Vyhodit funkcionalitu ohledně slotů do zvlášní třídy na první pohled dává smysl, jenže skripteři to tak používat nechtějí. Oni chtěljí jednoduchý interface s číslem slotu na entitě. Jasně, můžeš tam mít dva různé interface, jeden pro skript a jiný pro C++ engine a mapovat to mezi sebou, ale nic to nepřinese, kód bude delší, složitější a pomalejší. Mimochodem po tom tvém "refaktoringu" by to nebylo ani rychlejší, ani jednodušší.
Proč se vlastně ve vláknu o Javascriptu zabývat jazyky C++ nebo Lua? Víš dobře, že v těch jazycích nedělám a přesto se mě ptáš, jak bych to v nich refaktoroval. Tak jsem ti napsal svůj názor. Ber nebo nechej být, klidně si to dál dělej jak chceš, ale příště sem dej raději příklad na Javascript.
-
Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer.
To je zase zaměnění příčiny a následku.
Posuzování, zda použiju konstruktor nebo setter podle toho, jak ten konsturktor bude dlouhej není programování, ale pohodlnost.
Konstruktor slouží k tomu, aby se vytvořil objekt.
Setter k tomu, aby se změnil stav objektu z jednoho validního stavu na jiný validní.
To, že v případě rozsáhlejch struktur jsou často většina hodnot volitelná je shoda okolností vedoucí k mylné představě, že settery jsou jen jinej způsob jak plnit objekt daty.
Druhej extrém je Kitova představa, že settery jsou nějakým specielním způsobem vždy špatné.
Posuzování, zda použiju konstruktor nebo setter podle toho, jak ten konsturktor bude dlouhej není programování, ale pohodlnost.
Nie pohodlnost, ale zdravy rozum. Vyplnit kilometrovy konstruktor, tam je trosku o hubu zistit poriadne, co kam ide.
Konstruktor sluzi predovsetkym na konfiguraciu objektu, to ze sa zhodou okolnosti pouziva aj na vytvorenie objeku je vedlajsia vec. Na vytvorenie objektu sa daju pouzit aj rozne factory metody/funkcie.
Jediny dovod konfigurovat vsetko v konstuktore je, ked je potrebny immutable objekt a vsetky fieldy su kvoli paranoji nastavene na filnal. (v jave)
Ja viem, ze som asi uchylny javista, ale bezny workflow je - Instancovat objekt, nakonfigurovat (nainjektovat), pustit init metodu objektu, ked je vsetko vo spravnom stave. Ak to nerobi uz framework, tak to takto spravim rucne.
Menenie "stavu" objektu by sa nemalo robit cez setter (pokial sa tym mysli nieco viac nez konfiguracia). Ale prihodne nazvanou metodou typu changeKillingState(State.NOT_KILLING)
OK. Nesouhlasím. Zásadně. S ničím.
Můžem se přesunout dál.
-
Posuzování, zda použiju konstruktor nebo setter podle toho, jak ten konsturktor bude dlouhej není programování, ale pohodlnost.
Nie pohodlnost, ale zdravy rozum. Vyplnit kilometrovy konstruktor, tam je trosku o hubu zistit poriadne, co kam ide.
Konstruktor sluzi predovsetkym na konfiguraciu objektu, to ze sa zhodou okolnosti pouziva aj na vytvorenie objeku je vedlajsia vec. Na vytvorenie objektu sa daju pouzit aj rozne factory metody/funkcie.
Jediny dovod konfigurovat vsetko v konstuktore je, ked je potrebny immutable objekt a vsetky fieldy su kvoli paranoji nastavene na filnal. (v jave)
Ja viem, ze som asi uchylny javista, ale bezny workflow je - Instancovat objekt, nakonfigurovat (nainjektovat), pustit init metodu objektu, ked je vsetko vo spravnom stave. Ak to nerobi uz framework, tak to takto spravim rucne.
Menenie "stavu" objektu by sa nemalo robit cez setter (pokial sa tym mysli nieco viac nez konfiguracia). Ale prihodne nazvanou metodou typu changeKillingState(State.NOT_KILLING)
Co máš pořád s tím kilometrovým konstruktorem? Když má konstruktor obvykle 1-3 parametry, tak takový konstruktor má do kilometru hóódně daleko.
Atributy objektu mohou být finální a často je v této podobě používám. To abych si je náhodou nezměnil. Immutable objekty se hodí pro implementaci vzoru Messenger - nejsou pak potřebné gettery ani settery.
Metodu pro init objektu by měl volat už konstruktor. Neinicializovaný objekt zřejmě nebude validní a je tedy k ničemu.
Místo nevhodného
state->changeKillingState(State.NOT_KILLING)bych raději zvolil mnohem jednodušší
state->noKill()nebo něco podobného.
robot.changeKillingState(State.NOT_KILLING)Neviem, co je na tom nevhodne. Je to pekna hodnota z ciselniku, velavravna, explicitna. Netreba mat na kazdy stav metodu.
Metodu pro init objektu by měl volat už konstruktor. Neinicializovaný objekt zřejmě nebude validní a je tedy k ničemu.
Objekt ktory nie je inicializovany (tj nevalidny) by sa nemal pouzivat. Spajat instanciaciu s inicializaciou je zarabanie si na problemy.
-
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.
-
robot.changeKillingState(State.NOT_KILLING)Neviem, co je na tom nevhodne. Je to pekna hodnota z ciselniku, velavravna, explicitna. Netreba mat na kazdy stav metodu.
Metodu pro init objektu by měl volat už konstruktor. Neinicializovaný objekt zřejmě nebude validní a je tedy k ničemu.
Objekt ktory nie je inicializovany (tj nevalidny) by sa nemal pouzivat. Spajat instanciaciu s inicializaciou je zarabanie si na problemy.
Metoda pro každý stav je docela výhodná. Umožňuje totiž měnit implementaci, aniž by se o tom okolní svět dozvěděl. Refaktorování takové třídy je mnohem snazší.
V každém konstruktoru mám inicializaci objektu. Konstruktor je krátký, problémy s tím nejsou žádné.
-
Proč se vlastně ve vláknu o Javascriptu zabývat jazyky C++ nebo Lua? Víš dobře, že v těch jazycích nedělám a přesto se mě ptáš, jak bych to v nich refaktoroval. Tak jsem ti napsal svůj názor. Ber nebo nechej být, klidně si to dál dělej jak chceš, ale příště sem dej raději příklad na Javascript.
To není věc jazyka, je úplně jedno, v čem to napíšeš. 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. Schválně sem dávám kód velkého projektu, který dělají docela schopní programátořii. A světe div se, getterů a setterů tam mají fakt hodně... Kdybys dělal herní engine, 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. Vzájemných závislostí mezi daty jednotlivých objektů je ve hře prostě přiliš moc, nenajdeš nějaký rozumný průnik. Mimochodem Unreal engine to stejné, taky spousta getterů a setterů:
https://docs.unrealengine.com/latest/INT/API/Runtime/Engine/GameFramework/AActor/index.html
-
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
-
Proč se vlastně ve vláknu o Javascriptu zabývat jazyky C++ nebo Lua? Víš dobře, že v těch jazycích nedělám a přesto se mě ptáš, jak bych to v nich refaktoroval. Tak jsem ti napsal svůj názor. Ber nebo nechej být, klidně si to dál dělej jak chceš, ale příště sem dej raději příklad na Javascript.
To není věc jazyka, je úplně jedno, v čem to napíšeš. 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. Schválně sem dávám kód velkého projektu, který dělají docela schopní programátořii. A světe div se, getterů a setterů tam mají fakt hodně... Kdybys dělal herní engine, 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. Vzájemných závislostí mezi daty jednotlivých objektů je ve hře prostě přiliš moc, nenajdeš nějaký rozumný průnik. Mimochodem Unreal engine to stejné, taky spousta getterů a setterů:
https://docs.unrealengine.com/latest/INT/API/Runtime/Engine/GameFramework/AActor/index.html
Příště si raději vyber příklad, který je napsán objektově.
-
Příště si raději vyber příklad, který je napsán objektově.
Aha, takže odtud vítr vane... Oni vlasně autoři herních enginů nepíšou objektově. Chybí jim Kit, který jim to správné "objektové" programování vysvětlí...
-
Příště si raději vyber příklad, který je napsán objektově.
Aha, takže odtud vítr vane... Oni vlasně autoři herních enginů nepíšou objektově. Chybí jim Kit, který jim to správné "objektové" programování vysvětlí...
Píší imperativně, protože mají představu, že jim to zvedne výkon toho enginu. Tak jim to necháme, ne?
-
Příště si raději vyber příklad, který je napsán objektově.
Aha, takže odtud vítr vane... Oni vlasně autoři herních enginů nepíšou objektově. Chybí jim Kit, který jim to správné "objektové" programování vysvětlí...
Autory hernych enginov nepisu objektovo, lebo je to pomale. Preto sa uz nejake to destrocie razi multiparadigmovy vyvoj ako "zlata stredna cesta". Tym sa zaoberal Jim Coplien https://www.amazon.com/Multi-Paradigm-Design-C-James-Coplien/dp/0201824671 (teraz robi scrum.)
-
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.
-
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.
Ok, nesuhlasim, zrejme som narazil na "praktika". Radsej necham diskusiu tak, lebo s tymto sa uz neda ani polemizovat.
-
Píší imperativně, protože mají představu, že jim to zvedne výkon toho enginu. Tak jim to necháme, ne?
Máš docela zmatek v pojmech, imperatní programování se s objektovým vůbec nevylučuje, naopak. Chtěl jsi napsat procedurální, místo imperativní, že? Ale i tak se mýlíš, procedurální kód to není.
-
Autory hernych enginov nepisu objektovo, lebo je to pomale. Preto sa uz nejake to destrocie razi multiparadigmovy vyvoj ako "zlata stredna cesta". Tym sa zaoberal Jim Coplien https://www.amazon.com/Multi-Paradigm-Design-C-James-Coplien/dp/0201824671 (teraz robi scrum.)
Ale prosímtě? Herní enginy samozřejmě objektové jsou, jak navenek, tak uvnitř. Nicméně pokud chceš řešit definici toho "jediného správného (TM) objektového programování" podle balkiho, Kita, já nevím koho... tak z toho mě prosím vynech, na nesmysly nemám čas.
-
Píší imperativně, protože mají představu, že jim to zvedne výkon toho enginu. Tak jim to necháme, ne?
Máš docela zmatek v pojmech, imperatní programování se s objektovým vůbec nevylučuje, naopak. Chtěl jsi napsat procedurální, místo imperativní, že? Ale i tak se mýlíš, procedurální kód to není.
Pracují s objekty jako se strukturou, což je typické právě pro procedurální programování. Gettery a settery zde slouží pouze jako maska, aby to nebylo vidět na první pohled.
-
Autory hernych enginov nepisu objektovo, lebo je to pomale. Preto sa uz nejake to destrocie razi multiparadigmovy vyvoj ako "zlata stredna cesta". Tym sa zaoberal Jim Coplien https://www.amazon.com/Multi-Paradigm-Design-C-James-Coplien/dp/0201824671 (teraz robi scrum.)
Ale prosímtě? Herní enginy samozřejmě objektové jsou, jak navenek, tak uvnitř. Nicméně pokud chceš řešit definici toho "jediného správného (TM) objektového programování" podle balkiho, Kita, já nevím koho... tak z toho mě prosím vynech, na nesmysly nemám čas.
Ide o to, ze byvaju multiparadigmove :) Ale ok, neberiem vam to, myslite si bars aj blbosti.
-
Příště si raději vyber příklad, který je napsán objektově.
Aha, takže odtud vítr vane... Oni vlasně autoři herních enginů nepíšou objektově. Chybí jim Kit, který jim to správné "objektové" programování vysvětlí...
Autory hernych enginov nepisu objektovo, lebo je to pomale. Preto sa uz nejake to destrocie razi multiparadigmovy vyvoj ako "zlata stredna cesta". Tym sa zaoberal Jim Coplien https://www.amazon.com/Multi-Paradigm-Design-C-James-Coplien/dp/0201824671 (teraz robi scrum.)
Objektové programování není pomalé. Spíš je pomalé nadužívání getterů a setterů. Pokud by byly privátní, tak by to překladač optimalizoval expanzí, ale veřejné se moc optimalizovat nedají.
-
Pracují s objekty jako se strukturou, což je typické právě pro procedurální programování. Gettery a settery zde slouží pouze jako maska, aby to nebylo vidět na první pohled.
Ne nepracují s objekty jako se strukturou, máš tam dědičnost a pozdní vazbu logicky použité. K tomu navíc tam máš gettery a settery, proti kterým vedeš nějakou tvoji osobní válku a automaticky to řadíš do kolonky "procedurální podle Kita". Mysli si to dál, je to tvůj boj.
-
Píší imperativně, protože mají představu, že jim to zvedne výkon toho enginu. Tak jim to necháme, ne?
Máš docela zmatek v pojmech, imperatní programování se s objektovým vůbec nevylučuje, naopak. Chtěl jsi napsat procedurální, místo imperativní, že? Ale i tak se mýlíš, procedurální kód to není.
Pracují s objekty jako se strukturou, což je typické právě pro procedurální programování. Gettery a settery zde slouží pouze jako maska, aby to nebylo vidět na první pohled.
Su dva pristupy
- imperativne
- deklarativne
V imperativnom pises jednotlive kroky.
V deklarativnom skor pises, ako by mali data vyzerat pred a po operacii, bez toho aby si presne hovoril, co sa ma presne vykonat.
OOP napodiv byva vacsinou imperativne. Ale moze byt aj deklarativne.
-
Příště si raději vyber příklad, který je napsán objektově.
Aha, takže odtud vítr vane... Oni vlasně autoři herních enginů nepíšou objektově. Chybí jim Kit, který jim to správné "objektové" programování vysvětlí...
Autory hernych enginov nepisu objektovo, lebo je to pomale. Preto sa uz nejake to destrocie razi multiparadigmovy vyvoj ako "zlata stredna cesta". Tym sa zaoberal Jim Coplien https://www.amazon.com/Multi-Paradigm-Design-C-James-Coplien/dp/0201824671 (teraz robi scrum.)
Objektové programování není pomalé. Spíš je pomalé nadužívání getterů a setterů. Pokud by byly privátní, tak by to překladač optimalizoval expanzí, ale veřejné se moc optimalizovat nedají.
Najpomalsia byva vzdy instanciacia. Volania metod byvaju prdy v hurikane.
-
Najpomalsia byva vzdy instanciacia. Volania metod byvaju prdy v hurikane.
Instanciaci tady neřešíme a když je těch prdů příliš mnoho, tak dokáží i hurikán otočit...
-
Instanciaci tady neřešíme a když je těch prdů příliš mnoho, tak dokáží i hurikán otočit...
Blbost, gettery bývají inlinované případně devirtualizované, dělá to překladač, přeloží se to typicky na jednu instrukci, nic rychlejšího nevymyslíš. I proto se to používá, je to prostě rychlé...
-
Najpomalsia byva vzdy instanciacia. Volania metod byvaju prdy v hurikane.
Instanciaci tady neřešíme a když je těch prdů příliš mnoho, tak dokáží i hurikán otočit...
Ked neriesime instanciaciu, dalsim problemom byvaju vstupno-vystupne operacie, tie brzdia najviac. Preto je dobre s nimi pracu co najviac optimalizovat.
-
Instanciaci tady neřešíme a když je těch prdů příliš mnoho, tak dokáží i hurikán otočit...
Blbost, gettery bývají inlinované případně devirtualizované, dělá to překladač, přeloží se to typicky na jednu instrukci, nic rychlejšího nevymyslíš. I proto se to používá, je to prostě rychlé...
To platí jen pro privátní gettery/settery.
-
Instanciaci tady neřešíme a když je těch prdů příliš mnoho, tak dokáží i hurikán otočit...
Blbost, gettery bývají inlinované případně devirtualizované, dělá to překladač, přeloží se to typicky na jednu instrukci, nic rychlejšího nevymyslíš. I proto se to používá, je to prostě rychlé...
To platí jen pro privátní gettery/settery.
o jakém jazyce mluvíte?
-
To platí jen pro privátní gettery/settery.
Mýliš se, platí to i pro public gettery a settery. Po pravdě Kite, mě to už moc nebaví. Nemáš moc představu o časové složitosti, nevíš na jaký kód co vede, ale jedeš si svoji mantru každý gettery/setter je špatný. Pro mě za mě si to dělej jak chceš, ale necpi to prosím ostatním.
-
To platí jen pro privátní gettery/settery.
Mýliš se, platí to i pro public gettery a settery. Po pravdě Kite, mě to už moc nebaví. Nemáš moc představu o časové složitosti, nevíš na jaký kód co vede, ale jedeš si svoji mantru každý gettery/setter je špatný. Pro mě za mě si to dělej jak chceš, ale necpi to prosím ostatním.
Gettery ani settery prostě do OOP nepatří. Tečka.
-
To platí jen pro privátní gettery/settery.
Mýliš se, platí to i pro public gettery a settery. Po pravdě Kite, mě to už moc nebaví. Nemáš moc představu o časové složitosti, nevíš na jaký kód co vede, ale jedeš si svoji mantru každý gettery/setter je špatný. Pro mě za mě si to dělej jak chceš, ale necpi to prosím ostatním.
Gettery ani settery prostě do OOP nepatří. Tečka.
a nějaký argument by nebyl? výkon to nebude a "já to tak dělám a funguje mi to" není nic moc argument
-
...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í.
-
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í.
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.
-
...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ý.
-
...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í.
napsal jste to IMHO celkem dobře, jenom dvě výtky, nikdo, myslím, netvrdil, že to něco zrychlí a pak jste nezmínil, že se používají kvůli tzv. zapouzdření
-
Ale prosímtě? Herní enginy samozřejmě objektové jsou, jak navenek, tak uvnitř. Nicméně pokud chceš řešit definici toho "jediného správného (TM) objektového programování" podle balkiho, Kita, já nevím koho... tak z toho mě prosím vynech, na nesmysly nemám čas.
Mam cim dal vetsi pocit, ze OOP bylo vymysleno jenom proto, aby se lidi mohli hadat o to, co je spravny OOP navrh. Takovehle zabomysi valky jsem kolem zadneho jineho paradihmatu nezazil...
-
Ale prosímtě? Herní enginy samozřejmě objektové jsou, jak navenek, tak uvnitř. Nicméně pokud chceš řešit definici toho "jediného správného (TM) objektového programování" podle balkiho, Kita, já nevím koho... tak z toho mě prosím vynech, na nesmysly nemám čas.
Mam cim dal vetsi pocit, ze OOP bylo vymysleno jenom proto, aby se lidi mohli hadat o to, co je spravny OOP navrh. Takovehle zabomysi valky jsem kolem zadneho jineho paradihmatu nezazil...
žejo?
-
Ale prosímtě? Herní enginy samozřejmě objektové jsou, jak navenek, tak uvnitř. Nicméně pokud chceš řešit definici toho "jediného správného (TM) objektového programování" podle balkiho, Kita, já nevím koho... tak z toho mě prosím vynech, na nesmysly nemám čas.
Mam cim dal vetsi pocit, ze OOP bylo vymysleno jenom proto, aby se lidi mohli hadat o to, co je spravny OOP navrh. Takovehle zabomysi valky jsem kolem zadneho jineho paradihmatu nezazil...
A taky proto, aby se novej HW dobre prodaval, protoze nikdy sem nevidel zprasenejsi kousky kodu, nez prave ty "OOP exclusive". Vetsina tvurcu totiz nema ani paru, co se stim, jejich kodem nasledne deje.
-
Ale prosímtě? Herní enginy samozřejmě objektové jsou, jak navenek, tak uvnitř. Nicméně pokud chceš řešit definici toho "jediného správného (TM) objektového programování" podle balkiho, Kita, já nevím koho... tak z toho mě prosím vynech, na nesmysly nemám čas.
Mam cim dal vetsi pocit, ze OOP bylo vymysleno jenom proto, aby se lidi mohli hadat o to, co je spravny OOP navrh. Takovehle zabomysi valky jsem kolem zadneho jineho paradihmatu nezazil...
A taky proto, aby se novej HW dobre prodaval, protoze nikdy sem nevidel zprasenejsi kousky kodu, nez prave ty "OOP exclusive". Vetsina tvurcu totiz nema ani paru, co se stim, jejich kodem nasledne deje.
Kolem strukturovaného programováná byly ty samé, assembler versus C jakbysmet.
-
...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í.
To je ono, vtip je v tom, že tudy ty informace téct nemají.
-
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).
-
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ý.
Supr. A metody to samé nezvládnou?
-
napsal jste to IMHO celkem dobře, jenom dvě výtky, nikdo, myslím, netvrdil, že to něco zrychlí a pak jste nezmínil, že se používají kvůli tzv. zapouzdření
Ano, to jsem asi taky nepochopil, zda se to má teda jako zrychlit, nebo zpomalit.
To ale metody taky.
-
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).
getter/setter je zvláštní případ metody
-
Supr. A metody to samé nezvládnou?
To byla ironie...
-
Mam cim dal vetsi pocit, ze OOP bylo vymysleno jenom proto, aby se lidi mohli hadat o to, co je spravny OOP navrh. Takovehle zabomysi valky jsem kolem zadneho jineho paradihmatu nezazil...
A které OOP máte na mysli? OOP se dnes říká kdečemu, i structu v C.
-
getter/setter je zvláštní případ metody
Supr, už se blížíme... Zkuste to prosím upřesnit.
-
...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ý.
https://en.wikipedia.org/wiki/Straw_man
-
getter/setter je zvláštní případ metody
Supr, už se blížíme... Zkuste to prosím upřesnit.
umožňují kontrolovaný přístup k členským proměnným a krom toho nic jiného
-
Supr. A metody to samé nezvládnou?
To byla ironie...
...a mně to přišlo nějaký podezřele vlezdozadekezecký... :-\
-
Supr. A metody to samé nezvládnou?
To byla ironie...
...a mně to přišlo nějaký podezřele vlezdozadekezecký... :-\
To bol straw man
https://en.wikipedia.org/wiki/Straw_man
-
getter/setter je zvláštní případ metody
Supr, už se blížíme... Zkuste to prosím upřesnit.
umožňují kontrolovaný přístup k členským proměnným a krom toho nic jiného
Taky vidí všechny metody objektu. Skoro jako samy metody, ne?
-
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...
-
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...
Trolli mavaju dutu palicu, takze vam to nehrozi :P
-
getter/setter je zvláštní případ metody
Supr, už se blížíme... Zkuste to prosím upřesnit.
umožňují kontrolovaný přístup k členským proměnným a krom toho nic jiného
Taky vidí všechny metody objektu. Skoro jako samy metody, ne?
už jsem psal, že gettery/settery jsou metody (pokud neignorujemene properties tak těžko říct)
-
už jsem psal, že gettery/settery jsou metody (pokud neignorujemene properties tak těžko říct)
To jako metody s trochu jiným zápisem?
-
už jsem psal, že gettery/settery jsou metody (pokud neignorujemene properties tak těžko říct)
To jako metody s trochu jiným zápisem?
myslíte properties? asi ano, ale nepoužívám jazyky, které je mají, nepřemýšlím o nich, gettery a settery jsou metody
-
už jsem psal, že gettery/settery jsou metody (pokud neignorujemene properties tak těžko říct)
To jako metody s trochu jiným zápisem?
myslíte properties? asi ano, ale nepoužívám jazyky, které je mají, nepřemýšlím o nich, gettery a settery jsou metody
Z filozofického hlediska je jedno co jsou, důležitý je pouze únik stavu z objektu. Respektive, jeho potencinální zneužití.
-
už jsem psal, že gettery/settery jsou metody (pokud neignorujemene properties tak těžko říct)
To jako metody s trochu jiným zápisem?
myslíte properties? asi ano, ale nepoužívám jazyky, které je mají, nepřemýšlím o nich, gettery a settery jsou metody
Z filozofického hlediska je jedno co jsou, důležitý je pouze únik stavu z objektu. Respektive, jeho potencinální zneužití.
můžete uvést příklad?
-
už jsem psal, že gettery/settery jsou metody (pokud neignorujemene properties tak těžko říct)
To jako metody s trochu jiným zápisem?
myslíte properties? asi ano, ale nepoužívám jazyky, které je mají, nepřemýšlím o nich, gettery a settery jsou metody
Z filozofického hlediska je jedno co jsou, důležitý je pouze únik stavu z objektu. Respektive, jeho potencinální zneužití.
můžete uvést příklad?
proboha radeji ne ...
-
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).
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 :-)))
-
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).
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ě?
-
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ě?
Nebylo by nejlepší ty objekty raději zavřít do krabice? I s tou kočkou, a neotvírat!?
-
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íš.
-
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.)
-
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?
-
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 (https://forum.root.cz/index.php?topic=13741.msg176803#msg176803)
-
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 (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.
-
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?
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.
-
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?
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.
to je docela legrační :)) všechny instance stringu jsou v určitém kontextu nevalidní ;)
-
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ý.
-
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).
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ě?
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.
Samozřejmě když jste zvyklý na vše nadefinovat setter a getter, abyste to měl po ruce, tak ten model taky zveřejníte, protože se určitě někde bude hodit. 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.
-
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?
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.
to je docela legrační :)) všechny instance stringu jsou v určitém kontextu nevalidní ;)
Jedine immutable objekty su stale validne. Tzn, po kazdej zmene, stary zahodit a vytvorit novy. Ale ved co, ramky vela, procesoru vela, mozme si to dovolit. Pripadne pristavame dalsiu jadrovku a bude vsecko fporadku.
-
Jedine immutable objekty su stale validne. Tzn, po kazdej zmene, stary zahodit a vytvorit novy. Ale ved co, ramky vela, procesoru vela, mozme si to dovolit. Pripadne pristavame dalsiu jadrovku a bude vsecko fporadku.
ani ty ne, tak jak to uetoyo napsal
-
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).
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ě?
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.
Samozřejmě když jste zvyklý na vše nadefinovat setter a getter, abyste to měl po ruce, tak ten model taky zveřejníte, protože se určitě někde bude hodit. 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.
pokud je to špatně, tak metody můžou vracet jenom "nic", konstantu nebo náhodné číslo
-
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íš.
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.
-
Jedine immutable objekty su stale validne. Tzn, po kazdej zmene, stary zahodit a vytvorit novy. Ale ved co, ramky vela, procesoru vela, mozme si to dovolit. Pripadne pristavame dalsiu jadrovku a bude vsecko fporadku.
ani ty ne, tak jak to uetoyo napsal
Viem si taku vec predstavit. Zavola sa konstruktor objektu, ten sa vytvori, len ak vsetky argumenty maju spravne parametre. Ak nemaju, tak konstruktor vyhodi vynimku.
Kazda metoda toho objektu vrati novy immutable objekt, ktory je kopiou povodneho, len so zmenenymi vlastnostami, ktore ma dana metoda menit. Ak by hrozilo, ze vznikne nevalidny objekt, metoda by vyhodila vynimku.
-
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íš.
-
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).
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ě?
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.
Samozřejmě když jste zvyklý na vše nadefinovat setter a getter, abyste to měl po ruce, tak ten model taky zveřejníte, protože se určitě někde bude hodit. 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.
pokud je to špatně, tak metody můžou vracet jenom "nic", konstantu nebo náhodné číslo
Návratová hodnota metody by měla souviset s modelovanou realitou, nikoliv s implementací toho modelování, a to obecně gettery a settery nesplňují. Ve speciálních případech to splňovat mohou.
-
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).
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ě?
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.
Samozřejmě když jste zvyklý na vše nadefinovat setter a getter, abyste to měl po ruce, tak ten model taky zveřejníte, protože se určitě někde bude hodit. 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.
pokud je to špatně, tak metody můžou vracet jenom "nic", konstantu nebo náhodné číslo
Návratová hodnota metody by měla souviset s modelovanou realitou, nikoliv s implementací toho modelování, a to obecně gettery a settery nesplňují. Ve speciálních případech to splňovat mohou.
fajn, začínáte to chápat :)
-
Jedine immutable objekty su stale validne. Tzn, po kazdej zmene, stary zahodit a vytvorit novy. Ale ved co, ramky vela, procesoru vela, mozme si to dovolit. Pripadne pristavame dalsiu jadrovku a bude vsecko fporadku.
ani ty ne, tak jak to uetoyo napsal
Viem si taku vec predstavit. Zavola sa konstruktor objektu, ten sa vytvori, len ak vsetky argumenty maju spravne parametre. Ak nemaju, tak konstruktor vyhodi vynimku.
Kazda metoda toho objektu vrati novy immutable objekt, ktory je kopiou povodneho, len so zmenenymi vlastnostami, ktore ma dana metoda menit. Ak by hrozilo, ze vznikne nevalidny objekt, metoda by vyhodila vynimku.
uetoyo ale psal o omezení, které objekt nezná, "kontextu"
-
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.
-
Jedine immutable objekty su stale validne. Tzn, po kazdej zmene, stary zahodit a vytvorit novy. Ale ved co, ramky vela, procesoru vela, mozme si to dovolit. Pripadne pristavame dalsiu jadrovku a bude vsecko fporadku.
ani ty ne, tak jak to uetoyo napsal
Viem si taku vec predstavit. Zavola sa konstruktor objektu, ten sa vytvori, len ak vsetky argumenty maju spravne parametre. Ak nemaju, tak konstruktor vyhodi vynimku.
Kazda metoda toho objektu vrati novy immutable objekt, ktory je kopiou povodneho, len so zmenenymi vlastnostami, ktore ma dana metoda menit. Ak by hrozilo, ze vznikne nevalidny objekt, metoda by vyhodila vynimku.
uetoyo ale psal o omezení, které objekt nezná, "kontextu"
Vzdy je nieco validne v kontexte. Niekde bol spomenuty string, ale ten je validny, ked splna parametre pre string. Ked sa stane fieldom (atributom) objektu, tak si to skontroluje objekt, ci sa mu tam necpu blbosti. Pripadne, ked sa pouzije ako argument metody.
Priklady z realneho zivota nemusim uvadzat. Baba moze byt aj pekna aj skareda, zalezi kto ju posudzuje.
-
fajn, začínáte to chápat :)
Když si prohlídnete objektové návrhové vzory, gettery a settery se v nich většinou nevyskytují, přesto že implementují relativně složité chování.
-
fajn, začínáte to chápat :)
Když si prohlídnete objektové návrhové vzory, gettery a settery se v nich většinou nevyskytují, přesto že implementují relativně složité chování.
Gamma and spol - "Design Patterns: Elements of Reusable Object-Oriented Software"
Priklad na vzor observer:
#include <iostream>
#include <vector>
#include <time.h>
#include <sys/types.h>
#include <sys/timeb.h>
#include <string.h>
using namespace std ;
class Subject;
class Observer
{
public:
Observer() {};
~Observer() {};
virtual void Update(Subject* theChangeSubject) = 0;
};
class Subject
{
public:
Subject() {};
virtual ~Subject() {};
virtual void Attach(Observer*);
virtual void Detach(Observer*);
virtual void Notify();
private:
vector<Observer*> _observers;
};
void Subject::Attach (Observer* o)
{
_observers.push_back(o);
}
void Subject::Detach (Observer* o)
{
int count = _observers.size();
int i;
for (i = 0; i < count; i++) {
if(_observers[i] == o)
break;
}
if(i < count)
_observers.erase(_observers.begin() + i);
}
void Subject::Notify ()
{
int count = _observers.size();
for (int i = 0; i < count; i++)
(_observers[i])->Update(this);
}
class ClockTimer : public Subject
{
public:
ClockTimer() { _strtime( tmpbuf ); };
int GetHour();
int GetMinute();
int GetSecond();
void Tick();
private:
char tmpbuf[128];
};
/* Set time zone from TZ environment variable. If TZ is not set,
* the operating system is queried to obtain the default value
* for the variable.
*/
void ClockTimer::Tick()
{
_tzset();
// Obtain operating system-style time.
_strtime( tmpbuf );
Notify();
}
int ClockTimer::GetHour()
{
char timebuf[128];
strncpy(timebuf, tmpbuf, 2);
timebuf[2] = NULL;
return atoi(timebuf);
}
int ClockTimer::GetMinute()
{
char timebuf[128];
strncpy(timebuf, tmpbuf+3, 2);
timebuf[2] = NULL;
return atoi(timebuf);
}
int ClockTimer::GetSecond()
{
char timebuf[128];
strncpy(timebuf, tmpbuf+6, 2);
timebuf[2] = NULL;
return atoi(timebuf);
}
class DigitalClock: public Observer
{
public:
DigitalClock(ClockTimer *);
~DigitalClock();
void Update(Subject *);
void Draw();
private:
ClockTimer *_subject;
};
DigitalClock::DigitalClock (ClockTimer *s)
{
_subject = s;
_subject->Attach(this);
}
DigitalClock::~DigitalClock ()
{
_subject->Detach(this);
}
void DigitalClock::Update (Subject *theChangedSubject)
{
if(theChangedSubject == _subject)
Draw();
}
void DigitalClock::Draw ()
{
int hour = _subject->GetHour();
int minute = _subject->GetMinute();
int second = _subject->GetSecond();
cout << "Digital time is " << hour << ":"
<< minute << ":"
<< second << endl;
}
class AnalogClock: public Observer
{
public:
AnalogClock(ClockTimer *);
~AnalogClock();
void Update(Subject *);
void Draw();
private:
ClockTimer *_subject;
};
AnalogClock::AnalogClock (ClockTimer *s)
{
_subject = s;
_subject->Attach(this);
}
AnalogClock::~AnalogClock ()
{
_subject->Detach(this);
}
void AnalogClock::Update (Subject *theChangedSubject)
{
if(theChangedSubject == _subject)
Draw();
}
void AnalogClock::Draw ()
{
int hour = _subject->GetHour();
int minute = _subject->GetMinute();
int second = _subject->GetSecond();
cout << "Analog time is " << hour << ":"
<< minute << ":"
<< second << endl;
}
int main(void)
{
ClockTimer timer;
DigitalClock digitalClock(&timer;);
AnalogClock analogClock(&timer;);
timer.Tick();
return 0;
}
Upriamujem pozornost na tento kus kodu:
class ClockTimer : public Subject
{
public:
ClockTimer() { _strtime( tmpbuf ); };
int GetHour();
int GetMinute();
int GetSecond();
void Tick();
private:
char tmpbuf[128];
};
Podobne je na tom mediator. To su dva vzory, ktore si pamatam, ze su tam getre. Lebo z podstaty musia byt. Cele je to prave o zistovani vnutorneho stavu objektu, co by sa podla tunajsich diskuterov nemalo robit. Takze akekolvek obicyklovanie getrov by bolo len zistovanie vnutorneho stavu aj tak.
Mozno, ked si prezriem ine vzory, nedopadnu lepsie. Taky builder je o setroch, len v bledoruzovom.
-
Inb4 vzory su cargokult, som zvedavy, kto to napise :)
-
Hodně častý je prostě jednoduchý objekt Person {name: String, surname: String}. Na tom toho moc nevymyslíš.
To je náhodou velmi dobrý příklad! Předávat ven stav objektu by bylo zlo. Správně se objekt má umět sám prezentovat. Takže by měl mít třeba metodu asHtml, asCsv apod. No ale protože v OOP děláme vše univerzálně a znovupoužitelně, tyhle metody implementovat nebudeme a místo toho uděláme obecnou metodu formattedWith(formatter). Ovšem formater taky dovnitř objektu šahat nesmí. Proto je potřeba mu předat abstraktní reprezentaci objektu - strom, kde každý uzel implementuje rozhraní IFormattable. Zároveň ale tuto abstraktní reprezentaci použijeme pro serializaci! A nejenom pro serializaci, ale COKOLI! Takže abysme zajistili, že všechny uzly budou dědit z naší třídy, která vše potřebné obsahuje, použijeme pattern Factory. Čili máme singleton AbstractObjectFormattableRepresentationFactory pomocí kterého potom uzel reprezentace vytvoříme velice snadno:
AbstractObjectFormattableRepresentationFactory.makeAsbstractFormattableRepresenstationNode(string)
- pochopitelně metoda je přetížená pro všechny typy, které by mohly připadat v úvahu a volá se **uvnitř objektu**.
Ovšem nesmíme zapomenout na eventualitu, že daná část stavu objektu není v daném formátu reprezentovatelná. K tomu slouží validátor IAbstractObjectFormattableRepresentationValidator.isFormattableAs, kterému se formát předává jako objekt (nějaké stringové konstanty a podobné prasárny v OOP nevedeme!). Příslušný objekt je pochopitelně opět singleton, čili k němu máme factory, to snad není potřeba zdůrazňovat.
No nic, abych to neprotahoval - chceme-li správně objektově implementovat výpis jména do HTML, budeme potřebovat tak dvacet až stošedesáttři tříd. Shoda na tom ale nepanuje. Někteří programátoři např. tvrdí, že IAbstractObjectFormattableRepresentationValidator je nepřístojné jméno rozhraní, protože neobsahuje písmeno Z.
-
Hodně častý je prostě jednoduchý objekt Person {name: String, surname: String}. Na tom toho moc nevymyslíš.
To je náhodou velmi dobrý příklad! Předávat ven stav objektu by bylo zlo. Správně se objekt má umět sám prezentovat. Takže by měl mít třeba metodu asHtml, asCsv apod. No ale protože v OOP děláme vše univerzálně a znovupoužitelně, tyhle metody implementovat nebudeme a místo toho uděláme obecnou metodu formattedWith(formatter). Ovšem formater taky dovnitř objektu šahat nesmí. Proto je potřeba mu předat abstraktní reprezentaci objektu - strom, kde každý uzel implementuje rozhraní IFormattable. Zároveň ale tuto abstraktní reprezentaci použijeme pro serializaci! A nejenom pro serializaci, ale COKOLI! Takže abysme zajistili, že všechny uzly budou dědit z naší třídy, která vše potřebné obsahuje, použijeme pattern Factory. Čili máme singleton AbstractObjectFormattableRepresentationFactory pomocí kterého potom uzel reprezentace vytvoříme velice snadno:
AbstractObjectFormattableRepresentationFactory.makeAsbstractFormattableRepresenstationNode(string)
- pochopitelně metoda je přetížená pro všechny typy, které by mohly připadat v úvahu a volá se **uvnitř objektu**.
Ovšem nesmíme zapomenout na eventualitu, že daná část stavu objektu není v daném formátu reprezentovatelná. K tomu slouží validátor IAbstractObjectFormattableRepresentationValidator.isFormattableAs, kterému se formát předává jako objekt (nějaké stringové konstanty a podobné prasárny v OOP nevedeme!). Příslušný objekt je pochopitelně opět singleton, čili k němu máme factory, to snad není potřeba zdůrazňovat.
No nic, abych to neprotahoval - chceme-li správně objektově implementovat výpis jména do HTML, budeme potřebovat tak dvacet až stošedesáttři tříd. Shoda na tom ale nepanuje. Někteří programátoři např. tvrdí, že IAbstractObjectFormattableRepresentationValidator je nepřístojné jméno rozhraní, protože neobsahuje písmeno Z.
Tak ono stačí místo Person, to pojmenovat PersonStruct a je to vyřešeno. Hned bude patrné, že nejde o objekt ale o strukturu implementovanou objektem. Mimochodem, chybu máte hned na začátku, formattedWith není objektově, je to ten samý případ jako settery/gettery, taky nepřímo zveřejňuje vnitřní stav. asHtml je ok, kdy objekt HtmlFormatter se do objektu injektuje. Fakticky tedy počet objektů zůstává ve vazbě 1:1 na reálnou činnost, v tomto případě daný typ formátování. Znovupoužitelnost není definována přes metody, jako v procedurálním programování, ale přes objekty, tedy v našem případě přes HtmlFormatter. V celé aplikaci pak pro implementaci html formátování vystačíte s jednou třídou, která implementuje metodu asHTML.
-
Inb4 vzory su cargokult, som zvedavy, kto to napise :)
Vzory jsou to cargo z cargocultu.
-
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.
-
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.
-
...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ě.
-
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 (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ě.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.).
-
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
-
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.
-
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.
-
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 :)
-
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?!
-
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...".
-
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?
-
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)".
-
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.
-
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.
-
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'?
-
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 :)
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;
}
}
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
Ok, strata casu, hrajte sa tu na validity nevalidneho. A nevaliditu validneho. Proste si vymyslate teorie a tie si obhajujete. Prosim, uz sa neodvolavajte na mna, aby som sa tu nemusel ozyvat.
-
Ok, strata casu, hrajte sa tu na validity nevalidneho. A nevaliditu validneho. Proste si vymyslate teorie a tie si obhajujete. Prosim, uz sa neodvolavajte na mna, aby som sa tu nemusel ozyvat.
IMHO čistě jazykový problém, pro mě je příklad nevalidního objektu třeba "dangling pointer" (nepoznám, že použití způsobí problém), příklad validního, ale "neinicializovaného" či nepoužitelného pak NULL pointer (umím zjistit, že to nejde použít pro žádanou činnost)
-
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 :)
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;
}
}
OK, hezký. Pokud to chápu dobře, tak sousto je (třeba) int, a to není, nemůže být objekt? Nelze mu měnit stav? (Teď myslím ideově, dle OOP, nikoliv fakticky. To abych tě dobře pochopil.)
A ještě druhá otázka: Pomeranč má metody pro ukousni, což je jen něco lépe vymyšleného pro to moje extrahuj-cukr (je mi úplně jasný, že sis představoval, že bych to dělal tak, že getterem vezmu hodnotu, odečtu, a pak ji setterem vrátím). Pak by se ale dalo očekávat, že panáček nebude jíst zelené (nezralé) pomeranče. Že si bude trhat jen pomeranče, které mají nějakou minimální váhu. Tedy chování panáčka ovlivňuje stav objektu. Jak by si na to šel?
-
Ok, strata casu, hrajte sa tu na validity nevalidneho. A nevaliditu validneho. Proste si vymyslate teorie a tie si obhajujete. Prosim, uz sa neodvolavajte na mna, aby som sa tu nemusel ozyvat.
IMHO čistě jazykový problém, pro mě je příklad nevalidního objektu třeba "dangling pointer" (nepoznám, že použití způsobí problém), příklad validního, ale "neinicializovaného" či nepoužitelného pak NULL pointer (umím zjistit, že to nejde použít pro žádanou činnost)
Jak jsem se pokoušel popsat
Person obj = factory.get() // někde seber nějaký objekt, ať nemáme konstruktor
obj.toString() // -> "Jmeno: NULL, Příjmení: NULL"
dá se celkem dobře prohlásit, že objekt Person, který nemá vyplněno ani jméno a příjmení, nemá co existovat: "Znám člověka, sice nevím jak se jmenuje, nevím jaké má rodné číslo, ani jak vypadá, vlastně o něm nevím vůbec nic. Ale zcela jistě existuje."
Zatímco třeba:
Person obj = factory.get() // někde seber nějaký objekt, ať nemáme konstruktor
obj.toString() // -> "Jmeno: Petr, Příjmení: Novák, Adresa: neuvedena"
se použít dá, páč adresu prostě můžeme neznat.
A tohle třeba už ne:
Person obj = factory.get() // někde seber nějaký objekt, ať nemáme konstruktor
obj.toString() // -> "Jmeno: Petr, Příjmení: Novák, Adresa: ulice: NULL, město: NULL, stát: NULL"
-
OK, hezký. Pokud to chápu dobře, tak sousto je (třeba) int, a to není, nemůže být objekt? Nelze mu měnit stav? (Teď myslím ideově, dle OOP, nikoliv fakticky. To abych tě dobře pochopil.)
A ještě druhá otázka: Pomeranč má metody pro ukousni, což je jen něco lépe vymyšleného pro to moje extrahuj-cukr (je mi úplně jasný, že sis představoval, že bych to dělal tak, že getterem vezmu hodnotu, odečtu, a pak ji setterem vrátím). Pak by se ale dalo očekávat, že panáček nebude jíst zelené (nezralé) pomeranče. Že si bude trhat jen pomeranče, které mají nějakou minimální váhu. Tedy chování panáčka ovlivňuje stav objektu. Jak by si na to šel?
Třeba takto:
class Osatka
{
private pomerance = [...]
function najdiZralyPomeranc()
{
for (pomeranc in pomerance)
if (pomeranc.jeZraly())
return pomeranc;
}
}
class Panacek
{
function snezPomeranc(osatka)
{
pomeranc = vezmiPomeranc(osatka);
do {
sousto = pomeranc.ukousni(rand(12))
} while(sousto.jeStavnate())
}
function vezmiPomeranc(osatka)
{
return osatka.najdiZralyPomeranc()
}
}
class Sousto
{
private hmotnost = 0;
construct(hmotnost)
{
this.hmotnost = hmotnost;
}
function jeStavnate()
{
return true;
}
}
class SkusNaprazdno extends Sousto
{
construct() {}
function jeStavnate()
{
return false;
}
}
class Pomeranc
{
private hmotnost = 1;
private barva = 'zelena';
construct(barva)
{
this.barva = barva;
}
function ukousni(apetit)
{
sousto = min(hmotnost, 0.9*(hmotnost/(12-min(11, apetit))));
if (hmotnost > 0)
{
hmotnost = hmotnost - sousto;
return new Sousto(sousto);
}
else
return new SkusNaprazdno();
}
function jeZraly()
{
if (barva == 'cervena')
return true;
else
return false;
}
}
-
OK, hezký. Pokud to chápu dobře, tak sousto je (třeba) int, a to není, nemůže být objekt? Nelze mu měnit stav? (Teď myslím ideově, dle OOP, nikoliv fakticky. To abych tě dobře pochopil.)
A ještě druhá otázka: Pomeranč má metody pro ukousni, což je jen něco lépe vymyšleného pro to moje extrahuj-cukr (je mi úplně jasný, že sis představoval, že bych to dělal tak, že getterem vezmu hodnotu, odečtu, a pak ji setterem vrátím). Pak by se ale dalo očekávat, že panáček nebude jíst zelené (nezralé) pomeranče. Že si bude trhat jen pomeranče, které mají nějakou minimální váhu. Tedy chování panáčka ovlivňuje stav objektu. Jak by si na to šel?
Třeba takto:
class Osatka
{
private pomerance = [...]
function najdiZralyPomeranc()
{
for (pomeranc in pomerance)
if (pomeranc.jeZraly())
return pomeranc;
}
}
class Panacek
{
function snezPomeranc(osatka)
{
pomeranc = vezmiPomeranc(osatka);
do {
sousto = pomeranc.ukousni(rand(12))
} while(sousto.jeStavnate())
}
function vezmiPomeranc(osatka)
{
return osatka.najdiZralyPomeranc()
}
}
class Sousto
{
private hmotnost = 0;
construct(hmotnost)
{
this.hmotnost = hmotnost;
}
function jeStavnate()
{
return true;
}
}
class SkusNaprazdno extends Sousto
{
construct() {}
function jeStavnate()
{
return false;
}
}
class Pomeranc
{
private hmotnost = 1;
private barva = 'zelena';
construct(barva)
{
this.barva = barva;
}
function ukousni(apetit)
{
sousto = min(hmotnost, 0.9*(hmotnost/(12-min(11, apetit))));
if (hmotnost > 0)
{
hmotnost = hmotnost - sousto;
return new Sousto(sousto);
}
else
return new SkusNaprazdno();
}
function jeZraly()
{
if (barva == 'cervena')
return true;
else
return false;
}
}
Pro samou sradnu s ošatkou jsi vynechal tu část s minimální váhou.
Šťavnatost je vlastností Pomeranče. Ale chutnost třeba už ne.
-
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 :)
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;
}
}
OK, hezký. Pokud to chápu dobře, tak sousto je (třeba) int, a to není, nemůže být objekt? Nelze mu měnit stav? (Teď myslím ideově, dle OOP, nikoliv fakticky. To abych tě dobře pochopil.)
A ještě druhá otázka: Pomeranč má metody pro ukousni, což je jen něco lépe vymyšleného pro to moje extrahuj-cukr (je mi úplně jasný, že sis představoval, že bych to dělal tak, že getterem vezmu hodnotu, odečtu, a pak ji setterem vrátím). Pak by se ale dalo očekávat, že panáček nebude jíst zelené (nezralé) pomeranče. Že si bude trhat jen pomeranče, které mají nějakou minimální váhu. Tedy chování panáčka ovlivňuje stav objektu. Jak by si na to šel?
pomeranc ma metodu ukousni? vy ste zabijaci :)
-
pomeranc ma metodu ukousni? vy ste zabijaci :)
Otázka blbého názvosloví. To neprožívám. Si to překládám jako že ten pomeranč má schopnost se rozpadnou na ty měsíčky.
-
pomeranc ma metodu ukousni? vy ste zabijaci :)
Otázka blbého názvosloví. To neprožívám. Si to překládám jako že ten pomeranč má schopnost se rozpadnou na ty měsíčky.
Pokud objekt nemá žádnou logicky vymyslitelnou akci, prostě místo něj pošlu mapu (či objekt s pouze datovými sloty). Metoda ukousni na pomeranči je padlá na hlavu. Pomeranč sám o sobě není schopen interakce, takže by neměl mít ani schopnost někam posílat/přímat zprávy.
-
to co sem chtel vedet je pekne shrnuto tady:
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.ht36vu3kg (https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.ht36vu3kg)
:}
-
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).
Liší se tím, že zveřejňují vnitřní stav objektu, což je špatně. Ovšem je to ale příjemnév a zjednodušuje to práci, asi jako příkaz GOTO :-)))
Ani goto neni zlo, zle je len jeho nadpouzivanie. Goto maju najviac v zuboch ludia, ktori ho nikdy neboli nuteni pouzivat a nemaju predstavu ako dokaze skutocne doprasit kod. kedysi ked som programoval na 8bity a basic nepoznal procedury ani funkcie, len goto a gosub / return, vsetko bolo globalne, kazdy riadok zacinal cislom (navestie) a príkazom goto sa dalo skocit doslova hocikam, tak z toho vznikali strasny bordel. Ale v dnesnych jazykoch je goto implementovane celkom rozumne da sa pouzivat iba v ramci jednej metody (neda sa vyskocit von z metody alebo skocit do inej metody). Niekedy dokaze tento prikaz dost zrychlit vykonavamy kod. inak aj cyklus a procesura je len vylepsene goto.
Objekt je syntakticky ocukrovana struktura, anemicke objekty aka struktury sa tiez casto hodia, aj ked objektami sa zvyknu nazyvat referencne typy a strukturami value typy, struktury tiez patria k programovaniu ziadna presna hranica medzi objektom a strukturou nie je.
Getter a seter vôbec nemusi sluzit na zmenu jedneho konkrétneho atributu, setter je jednoducho metoda ktora sa tvari ako premenna nemusia sa pisat uvozdovky pise sa rovnitko, a da sa aj overridnut. Je to podobny cukor ako pretazovanie operatorov, alebo indexery, malo by sa to pouzivat tam kde sa to hodi.
-
Dlouhodobě mě děsí představa, že se v IT pohybují lidé jako vy.
-
Dlouhodobě mě děsí představa, že se v IT pohybují lidé jako vy.
Loki's positive relations with the gods end with his role in engineering the death of the god Baldr and Loki is eventually bound by the gods with the entrails of one of his sons.