Postřehy ohledně architektury JavaScriptu

[SB]

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.

[Reklama]

[balki]

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?

[balki]

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

[balki]

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.

[Ivan Nový]

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.

[Reklama]

[balki]

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.

[Kit]

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?

[Kit]

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.

[SB]

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.

[balki]

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"

[SB]

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.

[Kit]

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.

[SB]

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.

[Kit]

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

Kód: [Vybrat]

echo $osoba;což by poskytlo právě požadované jméno osoby.

[SB]

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