Postřehy ohledně architektury JavaScriptu

YF

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #180 kdy: 27. 08. 2016, 23:22:55 »
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 ...


YF

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #181 kdy: 27. 08. 2016, 23:23:57 »
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 ...

YF

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #182 kdy: 27. 08. 2016, 23:25:59 »
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 :)

Ivan Nový

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #183 kdy: 28. 08. 2016, 08:26:28 »
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.

čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #184 kdy: 28. 08. 2016, 10:19:50 »
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 ...


čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #185 kdy: 28. 08. 2016, 10:23:11 »
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() ...

balki

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #186 kdy: 28. 08. 2016, 11:13:04 »
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.

Ivan Nový

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #187 kdy: 28. 08. 2016, 11:16:06 »
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.

YF


Kit

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #189 kdy: 28. 08. 2016, 12:14:05 »
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í.

čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #190 kdy: 28. 08. 2016, 12:21:38 »
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 ...

Inkvizitor

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #191 kdy: 28. 08. 2016, 12:36:51 »
Nechci bejt rejpal, ale setName je taky příklad zprávy ...

Z oblasti cargo kultu... ;-)

javaman ))

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #192 kdy: 28. 08. 2016, 12:58:00 »
To jsi neměl dělat. Právě jsi spustil lavinu hoven.

+1

balki

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #193 kdy: 28. 08. 2016, 13:19:23 »
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.

Ivan Nový

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #194 kdy: 28. 08. 2016, 13:40:43 »
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á :-)))