Kdy jsou Eventy anti-pattern rubrika: Návrh

8 Občan
položil/-a 20.2.2016

Občas se setkávám s OOP kódem, kde jsou eventy natolik nadužívany, že na to vyznat se kam co lítá by bylo potřeba schéma. A celé mě to pak přijde jako návrat ke GOTO. Otázka je, zda existuje nějaká obecná poučka, kde je použití "drátování" pomocí eventů antipattern, když to lze napsat čistě OOP a kdy to dává smysl. Zatím se držím pouze systému: Používat eventy, co nejméně.

Komentáře

  • harrison314 : Tesim sa na Kitov prispevok o OOP a DDD :D 20.2.2016
  • harrison314 : Este poznamka: Eventy su len syntakticky cukor na vzorom Observer. Skus sa pozriet aj nan. 20.2.2016
  • Taco : @harrison314: Já se obávám, že toto většina z nás ví. Jde spíše o to, zda je tento vzor užitečnej, a kdy začíná škodit. 20.2.2016
odkaz
10 jiri.knesl
odpověděl/-a 21.2.2016

Eventy jsou side-effect. Protože side effecty způsobují to, že kód je hůř pochopitelný, tak bych stanovil následující pravidlo:

"Tam, kde lze napsat kód bez eventů pomocí pure funkcí, napiš ho pomocí pure funkcí. Pokud to nejde, využij side effect."

Pozn. Proč je kód s eventy hůř pochopitelný?

Mám třeba objekt (ale všechno tohle platí i v neobjektovém kódu).

abc.def();
 
// nekde jinde
onEventX(function() { /* ... */ });
onEventY(function() { /* ... */ });

A dokud se nepodívám pořádně do kódu, tak mi nedojde, že abc.def odpálí event, který úplně někde jinde zachytí jiný kus aplikace.

var result = abc.def();
result.match({
  "x": function() { /* ... */ },
  "y": function() { /* ... */ }});

Tento kód sice interně používá eventy (jinak v JS asynchronnosti nedosáhneš), ale pevně drží tu vazbu. Zavolání abc.def je ref. transparentní, vždy vrátí stejný objekt, dá se testovat a díky předanému resultu je ve zdrojáku zjevné, o co jde. Pokud by byl kód synchronní, bez eventů by se kód obešel úplně. Finta je i v tom, že pak jde překlopit naprosto stejný kód, ať už funguje synchronně nebo asynchronně jen výměnou vraceného objektu. Samozřejmě za cenu toho, že člověk bude všude používat nějakou monádu (JS vývojář by použil všude Promise).

Komentáře

  • Taco : S tvrzením, že eventy jsou side-effect nemohu souhlasit. Ne, že by to nebyla pravda, ale není to ta pointa. Eventy jsou side-effect shodou okolností, důsledkem obecného konceptu, ne z principu. S tím, že upřednostňovat pure-funkce souhlas, ale s eventy to imho nesouvisí. 21.2.2016
  • jiri.knesl : Každá forma komunikace je side effect. Event je komunikace. Někdy se dá tohle zamaskovat (právě do monád apod.), ale pořád to tak je. Event se imho v pure funkcích vyjádřit nedá. 21.2.2016
  • Taco : To výpis na výstup, nebo čtení ze souboru taky ne. A máš-li jazyk, který podporuje systém effectů (nezaměňovat s pojmem side-effect), tak to dokonce uděláš i pure. I event. 22.2.2016
  • jiri.knesl : Systém efektů je právě to "něco jako monáda", o čem tady celou dobu mluvím. 22.2.2016
  • Občan : Efekty snad jsou jen [IO] monada, ktera impure case vyzene jenom na kraj aplikace, ne? Kazdopadne pro firemni praxi by mel zajimalo, jak je myslena ta "vymena vraceneho modelu", tu se priznam jsem nejak neprolouskal. 22.2.2016
  • Jakub Zapletal : Rozhodne souhlasim s tim co Jirka napsal. Kazdy design pattern by se mel pouzit tam, kde vyresi nejaky problem, a ne hledat zpusob jak situaci "nadratovat" na konkretni pattern. 26.2.2016

Pro zobrazení všech 6 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.