Dědičnost dnes

[javaman ()]

OMG, singleton je v Javě antipattern. Ale to nebyl point Šlo jen o to, že ty běžné OOP návrhové vzory se úplně pro dynamické jazyky nehodí, protože to nedává smysl, když je vše dynamické a my dospělí.

[Reklama]

[Kiwi]

Spíše jestli to nechápeš špatně ty. Proč se teda ten tvůj Smalltalk a dynamické typování skoro na nic nepoužívá? Pochybuju, že tvůrci C++ a Javy byli úplně mimo a nic nechápali. Neříkám, že musejí být lepší než ty, ale podle těch tvých hlášek tady pochybuju, že bys uměl programovat. Pokud máš problém jen s tím, že Java je OOP, tak je na čase si to tu pro tu debatu trochu změnit.

Takže ještě jednou, proč se používá skoro na všechno Java, když je tak špatná? Dyť by ti podnikatelé raději mohli ušetřit a prodávat luxusní věci, ne? Neříkám, že je úžasná na všechno, ale ty máš určitě hromadu lepších přístupů, které plno problémů odstraní. A nebo jsi jen nic pořádného nedělal, nevím.

Na druhou stranu nemám moc rád dnešní vývoj, kdy plno lidí umí návrhové vzory a patlání. Většina vzorů je totiž fakt jen opruz navíc, který to spíše zkomplikuje. Jak kdy, ale obecně Java se píše daleko složitější a nedá se pak ani číst. Což je škoda. Takže možná na tom něco bude.

Přesně stejný dojem to budí i ve mně.

Právě třeba to Ruby je přesně ono. Pro mě je to dynamický shit, který nelze stejně na nic použít. Frčí to hlavně kvůli webům. To je jako PHP. Takže beru, že je populární, ale ne u pořádného vývoje. Proto pořád zůstává otázka, jestli lze tyhle dynamické "hračky" použít na seriozní vývoj.

Stáhni si Pharo, k tomu třeba pdf-knížku Pharo by Example a ve volných chvílích si s tím hraj. Čistě jen pro zažití, že to OOP se dá dělat i trochu jinak, než je člověk zvyklý. Ne snad kvůli tomu, abys pak dělal v něčem jiném, ale ono to člověka ovlivní. Pak najednou sám sebe přistihne, že by spoustu věcí i v té Javě dělal trochu jinak než vídá, nebo dokonce jinak, než mu radí knížky. Mirek už ti tu doporučoval Elixir, s tím si taky tak můžeš hrát. Ne snad kvůli zahození Javy, ale k tomu, aby člověk uzřel, že na jednu a tu samou věc, jeden problém, se dá dívat z různých stran a že různé problémy vypadají z různých stran různě příjemně/nepříjemně. A podle toho se pak umět lépe rozhodnout, z jaké strany bude nejvhodnější do toho ty vidle vrazit. Připadá mi to mnohem užitečnější než všelijaké ty knížky "Jak se naučit psát super dokonalý kód za 30 dní" apod.

A jsem rád, že to probíráme, takže to není nic proti nikomu. Možná ale embedded je právě o menších a přesných programech? Tam bych si dovedl představit dynamické typování, protože ta velikost nemusí být tak velká. Ale nevím, třeba je to velké i tak.

Bývají to i docela rozsáhlé věci. V této branži ale spíš platí opak - čím méně dynamické, tím lépe, statická typová kontrola, kde to jen jde, mít stále na paměti omezené prostředky, časové nároky více či méně realtimové... Přestože objektové programování tady dostává reálný význam jako málo kde jinde, protože ty objekty budou často představovat opravdu objekty reálného světa, ty černé krabičky jsou opravdu nějaké krabičky, s kterými se komunikuje po nějakých drátech, tak z praktického hlediska se tu "OOP" (i to C++kové, natož něco dynamického) spíše nadužívá. Když neustále hrozí hláška linkeru "out of memory", tak se s tím moc rozumně objektově programovat nedá.

[javaman ()]

Jasný, Elixír už mám na seznamu. Mám rád experimenty, proto jsem zkoušel třeba Scalu a čisté FP jazyky. Proč ne, jen zatím nikam nepřecházím. Ono tyhle teoretické debaty většinou nikdo moc rád nemá, takže souhlasím, že je to daleko lepší než jasné kuchařky. Každý by rád měl jasná řešení, která se jen naučí. Tak to ale nefunguje.

Hmmm, tak těžko říct. Mám rád vše statické, protože jinak se mi tam vkrádají další problémy, které mě nezajímají. Typicky co poslat někomu. Takhle se podívám a vím. Jasně, omezuje mě to, ale to je právě ta výhoda.

[balki]

OMG, singleton je v Javě antipattern. Ale to nebyl point Šlo jen o to, že ty běžné OOP návrhové vzory se úplně pro dynamické jazyky nehodí, protože to nedává smysl, když je vše dynamické a my dospělí.

Singleton ide v pythone spravit. A to, ze to nedava v dynamickych jazykoch zmysel, je dufam ironia

Singleton nie je antipattern, je to velmi sikovny pattern.

[javaman ()]

Jde, asi tak jako tam jde mít private přístup a nebo typy. Proč? Většina jich tam nedává smysl, protože jsou právě na to, abys nějak statické typy vhodně postavil.

Ani ne, v Javě se už dávno nepoužívá. Možná jinde je pořád cool.

[Reklama]

[Honza]

Ani ne, v Javě se už dávno nepoužívá. Možná jinde je pořád cool.

Pokud se v Javě dávno nepoužívá, jenom dobře. Pokud tedy jde o tu variantu s private konstruktorem, to bych jako anti-pattern bral.

[javaman ()]

Ani ne, v Javě se už dávno nepoužívá. Možná jinde je pořád cool.

Pokud se v Javě dávno nepoužívá, jenom dobře. Pokud tedy jde o tu variantu s private konstruktorem, to bych jako anti-pattern bral.

Přesně tak. Jde o všechny varianty. Vtipné je, že většina lidí, když se ptá na pohovorech, ani neumí všechny a zároveň umí jen ty nepoužitelné. Ale pořád se na to ptají Alespoň člověk ví, co tam bude za lidi.

[balki]

Ani ne, v Javě se už dávno nepoužívá. Možná jinde je pořád cool.

Pokud se v Javě dávno nepoužívá, jenom dobře. Pokud tedy jde o tu variantu s private konstruktorem, to bych jako anti-pattern bral.

Přesně tak. Jde o všechny varianty. Vtipné je, že většina lidí, když se ptá na pohovorech, ani neumí všechny a zároveň umí jen ty nepoužitelné. Ale pořád se na to ptají Alespoň člověk ví, co tam bude za lidi.

Singleton sa nezvykne pouzivat, ak je k dispozicii dependency injection framework. Ale inac neviem si predstavit, ako by sa riesila jedna jedina zdielana instancia pre celu aplikaciu v plain jave ... 

A private constructor sluzi na znemoznenie instancovania zvonka. Cize nie je to antipattern, ak z nejakeho dovodu chcete nekontrolovanemu instancovaniu zabranit. V tom pripade sa instancuje cez factory method.

[gll]

Ale inac neviem si predstavit, ako by sa riesila jedna jedina zdielana instancia pre celu aplikaciu v plain jave ... 

Často nepotřebujete vytvářet instanci. Stačila by vám statická třída, která si drží stav.

[balki]

Ale inac neviem si predstavit, ako by sa riesila jedna jedina zdielana instancia pre celu aplikaciu v plain jave ... 

Často nepotřebujete vytvářet instanci. Stačila by vám statická třída, která si drží stav.

Staticke metody patria classe, nie instancii, z coho potom vyplyvaju rozne neprijemnosti. Napriklad nemoznost pouzitia polymorfizmu pre classu. Nemoznost pouzitia classy ako parametra metody. (musel by sa teoreticky vytvorit fejkovy objekt, ktory by bol kripel alebo to riesit cez reflexivne samanizmy) Ked sa clovek rozhodne pre staticku classu, ze predsa len potrebuje z nejakeho dovodu viac instancii, tak to musi cele prepisat, atd ...

Osobne nemam rad classy a pridelovanie viac kompetencii classam, by ma bolelo (moj nazor)

[JS]

Ahoj,
mrkni na přednášku https://www.youtube.com/watch?v=Rmer37g9AZM , mohlo by to být pro tebe zajímavé.

Diky, to je docela dobre.

[JS]

Proč se teda ten tvůj Smalltalk a dynamické typování skoro na nic nepoužívá? Pochybuju, že tvůrci C++ a Javy byli úplně mimo a nic nechápali.

Sranda je, ze on by se mozna pouzival, kdyby Java nevznikla.. Zacatkem 90.let to byla pomerne silna konkurence C++ a psaly se v tom i business aplikace (IBM do toho treba hodne investovala).

Ale Java prisla a byla zdarma.. a jak uz to tak v IT byva, otevrene veci zvitezi, i kdyz jsou horsi. S kvalitou to nema moc co delat.

[javaman ()]

Přece těm nesmyslům sám nevěříš. Kdyby byla Java tak špatná, tak se toho už někdo všiml. Já v ní dělám řadu let a nevšiml jsem si, že by byla špatná.

Už tu byl i Biebr, který prý není dobrý. To je taky dost divný. Jak neni dobrý?

[JS]

Jeho odpovědi nedávají smysl, se slávou to nemá co dělat. Koncept rozdělení dat a funkcí jsem pochopil, neměnitelné stavy dosud neviděl. To tvrdíte vy.
Matici a vektor rozepište.
Možná by bylo vhodné připomenout nevýhody rozdělení ve FP.
V čem spočívá ta chyba tříd?

Nekomu kdo nezna FP, asi nedavaji smysl. To se neda nic delat.

V FP funkce a data nejsou fakticky az tak rozdelene, jak podotkl BoneFlute. Oboji jsou hodnoty nejakeho typu, jediny rozdil je v tom, ze funkci muzeme aplikovat na hodnoty nejakeho daneho typu.

Problem v tridach je v tom, ze pokud se praktikuje FP, jsou proste zbytecne. Tridy fakticky jen zaobaluji promenne (nebo jejich skupiny), abychom zarucili jejich konzistentni stav. Jelikoz v FP promenne nejsou, pouze hodnoty, neni potreba je zaobalovat. Konzistence stavu se vynucuje predevsim pomoci imutability, typovymi omezenimi, a eventualne, jak tu opakovane podotkl v, skrytim konstruktoru.

[zboj]

Jeho odpovědi nedávají smysl, se slávou to nemá co dělat. Koncept rozdělení dat a funkcí jsem pochopil, neměnitelné stavy dosud neviděl. To tvrdíte vy.
Matici a vektor rozepište.
Možná by bylo vhodné připomenout nevýhody rozdělení ve FP.
V čem spočívá ta chyba tříd?

Nekomu kdo nezna FP, asi nedavaji smysl. To se neda nic delat.

V FP funkce a data nejsou fakticky az tak rozdelene, jak podotkl BoneFlute. Oboji jsou hodnoty nejakeho typu, jediny rozdil je v tom, ze funkci muzeme aplikovat na hodnoty nejakeho daneho typu.

Problem v tridach je v tom, ze pokud se praktikuje FP, jsou proste zbytecne. Tridy fakticky jen zaobaluji promenne (nebo jejich skupiny), abychom zarucili jejich konzistentni stav. Jelikoz v FP promenne nejsou, pouze hodnoty, neni potreba je zaobalovat. Konzistence stavu se vynucuje predevsim pomoci imutability, typovymi omezenimi, a eventualne, jak tu opakovane podotkl v, skrytim konstruktoru.

Ono to souvisí trochu víc, v OOP s generickými třídami jsou v podstatě funktory a v FP se právě funktory používají na to samé, jen OOP se drbe levou rukou za pravým uchem a FP pravou za levým.