Postřehy ohledně architektury JavaScriptu

[Ivan Nový]

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.

[Reklama]

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

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.

[Ivan Nový]

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

[SB]

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

[balki]

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.

[Reklama]

[SB]

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.

[SB]

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.

[Kit]

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.

[Ivan Nový]

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

[balki]

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.

[Kit]

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

[Kit]

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

[balki]

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

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

[Ivan Nový]

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()