Postřehy ohledně architektury JavaScriptu

[Kit]

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.

[Reklama]

[SB]

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

[BoneFlute]

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.

[BoneFlute]

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

[Ivan Nový]

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.

[Reklama]

[BoneFlute]

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:

Kód: [Vybrat]

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.

[SB]

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.

[SB]

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

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

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

[Kit]

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.

[gamer]

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

[Kit]

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

[gamer]

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.

[Honza]

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.

Kód: [Vybrat]

entity->slots(1)->IsSlotValid() místo

Kód: [Vybrat]

entity->IsSlotValid(1)

[balki]

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)