Online IDE pro Javu s možností debugování

[Anonymous]

Čím přesně property v C# porušují OOP? Jde jen o syntaktický cukr a přeloženy jsou jako standartní get/set funkce.

Property porušují zapouzdření objektu. Programátor jejich prostřednictvím manipuluje s atributy objektu mimo ten objekt místo toho, aby ty algoritmy byly zapouzdřeny uvnitř toho objektu společně s daty.

Metody get/set nejsou standardní, do OOP nepatří.

To ale tedy není problém property, stejně tak, jak můžete využít funkce k porušení OOP můžete stejně špatně využít property. Jen si ve spoustě případů zajistíte s property "hezčí" zápis.

[Reklama]

[noef]

Zapis je hezci, ale treba v tom JavaScriptu me to neprijde tak skvele. Navic si kazdy pouziva co chce - setThing a getThing, nebo getter thing() a setter thing(value) a nebo ty property thing= a thing. V C# to bude asi trochu pouzitelnejsi, kdyz je jednotny styl. Podobne ve Scale, kde lze zamnenovat promenne a settery/gettery. V Jave je na me prilis mnoho boilerplate kodu.

Zda se maji pouzivat je asi trochu jina otazka, ale IMO je to velmi bezne. Posledni dobou zacinam znacne preferovat FP pristup, tj. immutable objekty, v podstate jen nosice dat a k tomu pure funkce, ktere s nimi pracuji. Nehodi se to uplne na vse (napr. GUI u hry), ale testy se na to pisi uplne skvele.

[Kit]

Zapis je hezci, ale treba v tom JavaScriptu me to neprijde tak skvele. Navic si kazdy pouziva co chce - setThing a getThing, nebo getter thing() a setter thing(value) a nebo ty property thing= a thing. V C# to bude asi trochu pouzitelnejsi, kdyz je jednotny styl. Podobne ve Scale, kde lze zamnenovat promenne a settery/gettery. V Jave je na me prilis mnoho boilerplate kodu.

Podle mne by se accesory v Javascriptu vůbec neměly používat. I v Javě se dá v pohodě programovat bez nich. Třídy vychází mnohem jednodušší, mají jednodušší rozhraní a jsou i kratší. Aplikace vypadá mnohem čistěji, když nikdo kromě objektu samotného nezná jeho atributy.

Zda se maji pouzivat je asi trochu jina otazka, ale IMO je to velmi bezne. Posledni dobou zacinam znacne preferovat FP pristup, tj. immutable objekty, v podstate jen nosice dat a k tomu pure funkce, ktere s nimi pracuji. Nehodi se to uplne na vse (napr. GUI u hry), ale testy se na to pisi uplne skvele.

Accessory jsou bohužel běžné, ale naštěstí jen v některých jazycích. V PHP je nepoužívám a domnívám se, že v Pythonu je také skoro nikdo nedělá.

[gl]

Zapis je hezci, ale treba v tom JavaScriptu me to neprijde tak skvele. Navic si kazdy pouziva co chce - setThing a getThing, nebo getter thing() a setter thing(value) a nebo ty property thing= a thing. V C# to bude asi trochu pouzitelnejsi, kdyz je jednotny styl. Podobne ve Scale, kde lze zamnenovat promenne a settery/gettery. V Jave je na me prilis mnoho boilerplate kodu.

Zda se maji pouzivat je asi trochu jina otazka, ale IMO je to velmi bezne. Posledni dobou zacinam znacne preferovat FP pristup, tj. immutable objekty, v podstate jen nosice dat a k tomu pure funkce, ktere s nimi pracuji. Nehodi se to uplne na vse (napr. GUI u hry), ale testy se na to pisi uplne skvele.

Pokud si vzpomínám, tak immutable objekty jsou doporučovány i v Effective Java z roku 2001. Settery mohou vracet změněnou kopii objektu nebo alespoň this. Pak se dají řetězit. Takový styl se mi docela líbí v JS.

O objektech jako nosičích dat pěkně mluví Rich Hickey. Dává to smysl, ale při použití klasických objektů a metod se dá lépe využít autodoplňování. V jazycích, které nemají něco jako threading makro z Clojure mi přijde řetězení metod lepší než vnořování funkcí. Navíc v pythonu není problém sdílení metod mezi objekty různých typů.

[noef]

Pokud jsem spravne pochopil to threading macro, tak jde o vyspelejsi formu aplikace funkci.

Jsou nejake navrhy operatoru pro forward application (casto znaceny jako |> nebo |) pro dalsi verzi JS. Existuje i nejake makro pro SweetJS, ale tam bude problem s podporou v IDE. Napr. Lodash umi urcitou formu retezeni, ale neni to uplne ono - hodnoty se musi nejdrive obalit a pak ziskavat vysledek, navic na to neni tak uplne staveny. Treba takovy Option ze Scaly (Haskelli Maybe) nevim jestli jde vubec nejak rozumne simulovat (tim myslim aby pracoval napr. s map a forEach; mozna opatchovat stavajici funkce, ale to nezni moc ciste).

V Haskellu je zajimava knihovna Flow, kterou teda komunita pry moc dobre neprijala. Nevim, zapis me prijde hezky, ale mozna je to jen tim, ze Haskell nemam vubec zazity. V podstate elegentne resi to, co nekterym lidem (myslim i panu Prymkovi) vadi - ze cteni vyrazu v Haskellu muze byt "rozeskakane".

[Reklama]

[gl]

Pokud jsem spravne pochopil to threading macro, tak jde o vyspelejsi formu aplikace funkci.

Jsou nejake navrhy operatoru pro forward application (casto znaceny jako |> nebo |) pro dalsi verzi JS. Existuje i nejake makro pro SweetJS, ale tam bude problem s podporou v IDE. Napr. Lodash umi urcitou formu retezeni, ale neni to uplne ono - hodnoty se musi nejdrive obalit a pak ziskavat vysledek, navic na to neni tak uplne staveny. Treba takovy Option ze Scaly (Haskelli Maybe) nevim jestli jde vubec nejak rozumne simulovat (tim myslim aby pracoval napr. s map a forEach; mozna opatchovat stavajici funkce, ale to nezni moc ciste).

V Haskellu je zajimava knihovna Flow, kterou teda komunita pry moc dobre neprijala. Nevim, zapis me prijde hezky, ale mozna je to jen tim, ze Haskell nemam vubec zazity. V podstate elegentne resi to, co nekterym lidem (myslim i panu Prymkovi) vadi - ze cteni vyrazu v Haskellu muze byt "rozeskakane".

existuje some-> makro. To se zastaví na první hodnotě nil. Určitě jdou v Clojure implementovat i monády a něco jako do notace z haskellu, ale nikdy jsem se s tím nesetkal.

[noef]

...
existuje some-> makro. To se zastaví na první hodnotě nil. Určitě jdou v Clojure implementovat i monády a něco jako do notace z haskellu, ale nikdy jsem se s tím nesetkal.

To zacina byt celkem popularni - podpora preruseni retezeni na nil/null primo v jazyce. Jsem nedavno neco podobneho zahledl v Kotlinu (LiveScript ma myslim to same):

Kód: [Vybrat]

bob?.department?.head?.name

Such a chain returns null if any of the properties in it is null.
Ve Scale (a asi dost podobne i v Haskellu) se to bude resit pres Option a map/flatMap nebo lepe pres for-comprehension:

Kód: [Vybrat]

case class A(b:Option[Bool])
val optA = Some(A(Some(true)))
optA.flatMap(_.b).foreach(println) // true
for(a <- optA; x <- a.b) println(x) // true

Netusi nekdo, jak je na tom Java?

[Filip Jirsák]

Netusi nekdo, jak je na tom Java?

Uvažovalo se o tom při přípravě Javy 8, ale moc daleko se to nedostalo. Jako taková lehká náhrada je v Javě 8 třída Optional, ale syntaktický cukr pro to žádný není.

[gl]

Netusi nekdo, jak je na tom Java?

Uvažovalo se o tom při přípravě Javy 8, ale moc daleko se to nedostalo. Jako taková lehká náhrada je v Javě 8 třída Optional, ale syntaktický cukr pro to žádný není.

Použití třídy Optional je komplikovanější než zachytávání vyjímek.

[Ondra Satai Nekola]

Použití třídy Optional je komplikovanější než zachytávání vyjímek.

To zalezi. Jak si navyknes na pouziti map()a a flatMap()u, tak to zacne davat podstatne vetsi smysl.

Nemluve o tom, ze zachytavani (ne jen) NPE pro rizeni behu aplikace je dost velky humus. M.j. protoze si vetsinou nemuzes byt jisty, zda pochazi prave z te derefernce, ze ktere bys to cekal.

[Kolemjdoucí]

Netusi nekdo, jak je na tom Java?

Uvažovalo se o tom při přípravě Javy 8, ale moc daleko se to nedostalo. Jako taková lehká náhrada je v Javě 8 třída Optional, ale syntaktický cukr pro to žádný není.

Použití třídy Optional je komplikovanější než zachytávání vyjímek.

Jak pro koho - možná pro líného programátora, ale rozhodně pro JVM je použití Optional efektivnější než práce s výjimkami.

[gl]

Nemluve o tom, ze zachytavani (ne jen) NPE pro rizeni behu aplikace je dost velky humus. M.j. protoze si vetsinou nemuzes byt jisty, zda pochazi prave z te derefernce, ze ktere bys to cekal.

Při použití ?. také nevím, na které dereferenci to skončilo. Vědět to nepotřebuju.

[gl]

Jestli jsem to správně pochopil, tak flatMap s Optional funguje jen pro metody bez parametru, které vrací Optional.

[gl]

Nebylo by jednodušší z toho streamu odfiltrovávat hodnoty null?

[Ondra Satai Nekola]

Jestli jsem to správně pochopil, tak flatMap s Optional funguje jen pro metody bez parametru, které vrací Optional.

Tak to jsi pochopil spatne. Muzes pouzit libovolnou lambdu.

Kód: [Vybrat]

o.flatMap(a -> foo.bar(1, a, 2))

Nemluve o tom, ze zachytavani (ne jen) NPE pro rizeni behu aplikace je dost velky humus. M.j. protoze si vetsinou nemuzes byt jisty, zda pochazi prave z te derefernce, ze ktere bys to cekal.

Při použití ?. také nevím, na které dereferenci to skončilo. Vědět to nepotřebuju.

Kód: [Vybrat]

a?.foo(c)?.bar(d)
Kdyz tam zacnes chytat NPE a myslis si, ze tim osetrujes situace kdy a je null nebo foo vrati null... tak se pak seredne divis, ze jsi zamaskoval chybu uvnitr foo, kde je vyhozena NPE trebas protoze c je null nebo to nekdo nejak jinak pokazil...