Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: Ran 15. 08. 2016, 11:50:56

Název: Zdroje k rozvoji OOP myšlení
Přispěvatel: Ran 15. 08. 2016, 11:50:56
Ahojte,

hledám nějaké vhodné zdroje k rozvoji OO myšlení... Nechci žádný flame jestli je lepší funkcionální nebo OO paradigma.
Celkem mě zaujali talky od Sandi Metz, která má dlouholeté zkušenosti ze smalltalku (aktuálně přednáší v souvislosti s Ruby, ale jazyk nehraje roli...)

Četl jsem Gang of Four, ale spíše by mě zajímali nějaké "reálnější" příklady toho jak se na architekturu dívat. Celkově se mi zdá, že všichni v mém okolí používají procedurální postupy obalené do tříd na místo modulů.

No pokud někoho něco napadne, tak budu rád.

Díky
Název: Re:OOP - zdroje
Přispěvatel: Youda 15. 08. 2016, 12:20:09
Pokud jsi precetl a pochopil GoF, umis dost.

Nejhorsi co muzes udelat, je snazit se puristicky cpat OOP prvky do kodu, jenom proto, ze je to OOP.

Slesky rozum.

To co chces je kod bez spaget, ktery dokaze precist i clovek co s danym jazykem primo nedela a zna zaklady C, co se da snadno testovat - takze rozsekat do pomerne malych self contained classes, zadne obri obludy. Boilerplate vubec nevadi, pokud zvysuje citelnost, stejne to generuje IDE.
Nejhorsi jsou krypticke zapisy, ktere nejaky idiot, hrdy, ze zna kazdou kravinu jazyka, pouzije.

Treba perl je v tom slavny, neco ve stylu $_->$@["nasr*at"] = 'a rozmazat';

Obecne kazdy nastroj ma smysl pouzit tam, kde smysl dava. Osobne jsem v Jave uz dloooouho nepouzil dedeni (pouze interfaces) ani treba anonymous classes.

Dale plati, use google, Luke. Hromadu veci uz nekdo neky resil a na stackoverflow je hromada velmi kvalitni inspirace.
Název: Re:OOP - zdroje
Přispěvatel: hawran diskuse 15. 08. 2016, 13:06:29
...
Slesky rozum.
...

Tak hlavně ten slesky rozum.
Baňýk, p...!

Podle toho GoF soudím, že třeba takový Eckel už je pasé.
https://en.wikipedia.org/wiki/Bruce_Eckel (https://en.wikipedia.org/wiki/Bruce_Eckel)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 15. 08. 2016, 13:31:21
Na rozvoj OOP se hodí Robert C. Martin a jeho kniha Clean Code.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ran 15. 08. 2016, 13:46:48
Eckel mi přiznám se nic neříká. Nikdy jsem se nijak zvlášť nesetkal s C++, tak asi proto. Podívám se na něketeré knihy od něj.

Clean Code mám aktuálně rozečtený.

Selský rozum je určitě potřeba, ale když už se mi na x-tém místě opakuje ta stejná podmínka, tak si říkám, že je asi něco špatně...

Za nepoužívání/zneužívání dědičnosti palec nahoru.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 15. 08. 2016, 14:22:50
Bruce Eckel napsal dobrou knihu Thinking in Java, u kterých se prvních cca 100 stránek věnuje právě OOP.

Když se někde vyskytne nějaká podmínka, která má jiný účel než integritní omezení dat, tak je to vždy k zamyšlení, zda raději nepoužít polymorfismus.

Dědičnost má smysl, pokud dodržíš LSP.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: balki 15. 08. 2016, 15:47:20
"Refactoring: Improving the Design of Existing Code od M.fowlera"   je podla mna tiez sucast povinnej jazdy, co sa tyka oop.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Honza 15. 08. 2016, 16:11:12
mrkni na "Head first design patterns", dá se stáhnout PDF
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: citanus006 15. 08. 2016, 16:37:24
http://www.martinfowler.com/books/
Název: Re:OOP - zdroje
Přispěvatel: gl 15. 08. 2016, 19:40:27
...
Slesky rozum.
...

Tak hlavně ten slesky rozum.
Baňýk, p...!

Podle toho GoF soudím, že třeba takový Eckel už je pasé.
https://en.wikipedia.org/wiki/Bruce_Eckel (https://en.wikipedia.org/wiki/Bruce_Eckel)

Myslíme v C++ je hodně špatná kniha. Zejména první díl jsou jen obecné řeči a hloupé příklady.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Inkvizitor 15. 08. 2016, 19:44:10
Selský rozum je určitě potřeba, ale když už se mi na x-tém místě opakuje ta stejná podmínka, tak si říkám, že je asi něco špatně...

Proč i myslíš, že to znamená nedostatečně objektové myšlení?
Název: Re:OOP - zdroje
Přispěvatel: Kit 15. 08. 2016, 19:45:25
Myslíme v C++ je hodně špatná kniha. Zejména první díl jsou jen obecné řeči a hloupé příklady.

Neřešíme C++, ale OOP.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 15. 08. 2016, 19:47:55
Selský rozum je určitě potřeba, ale když už se mi na x-tém místě opakuje ta stejná podmínka, tak si říkám, že je asi něco špatně...

Proč i myslíš, že to znamená nedostatečně objektové myšlení?

Třeba protože stejné podmínky se v OOP téměř nevyskytují?
Název: Re:OOP - zdroje
Přispěvatel: gl 15. 08. 2016, 19:53:11
Treba perl je v tom slavny, neco ve stylu $_->$@["nasr*at"] = 'a rozmazat';

Kde jste se konkrétně s tímhle řádkem setkal? Když už chcete kritizovat, pošlete alespoň reaálný kód.
Název: Re:OOP - zdroje
Přispěvatel: gl 15. 08. 2016, 19:58:40
Myslíme v C++ je hodně špatná kniha. Zejména první díl jsou jen obecné řeči a hloupé příklady.

Neřešíme C++, ale OOP.

Lepší je se učit OOP používáním dobrých knihoven, než čtením hloupých příkladů.
Název: Re:OOP - zdroje
Přispěvatel: Kit 15. 08. 2016, 20:06:25
Lepší je se učit OOP používáním dobrých knihoven, než čtením hloupých příkladů.

Ani dobré knihovny nám toho o OOP mnoho neřeknou. Dobré příklady jsou lepší.
Název: Re:OOP - zdroje
Přispěvatel: balki 15. 08. 2016, 20:55:31
Myslíme v C++ je hodně špatná kniha. Zejména první díl jsou jen obecné řeči a hloupé příklady.

Neřešíme C++, ale OOP.

Lepší je se učit OOP používáním dobrých knihoven, než čtením hloupých příkladů.

Nie je to dobre tak riesit, lebo v knizniciach byva pomiesanej vela roznej  nesuvisiacej funkcionality a clovek potom nevidi potom priklady v ich cistej forme. V knihach to byva explicitne pomenovane, cistejsie a nemusi byt v prikladoch nagrcane, z dovodu, aby to chodilo. V libkach tiez nezvyknu rozoberat vhodne a nevhodne sposoby pouzitia, tam to proste nakodia. (bud dobre, alebo zle)


Inac, eckel sa mi tiez tazsie cital, lebo je tak trosku grafoman.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Inkvizitor 15. 08. 2016, 22:34:22
Selský rozum je určitě potřeba, ale když už se mi na x-tém místě opakuje ta stejná podmínka, tak si říkám, že je asi něco špatně...

Proč i myslíš, že to znamená nedostatečně objektové myšlení?

Třeba protože stejné podmínky se v OOP téměř nevyskytují?

Na tom není nic objektového. Každý dostatečně bohatý jazyk kteréhokoli paradigmatu lze používat tak, aby se neduplikoval kód. A každý rozumný člověk píše programy tak, aby pokud možno nedocházelo k duplicitám.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 16. 08. 2016, 00:32:49
"Refactoring: Improving the Design of Existing Code od M.fowlera"   je podla mna tiez sucast povinnej jazdy, co sa tyka oop.

Tak Refaktorování je určitě povedená knížka, ale je spíše o organizaci kódu, dokonce některé úpravy nesouvisejí s OOP.
Ale co jsem používal a doporučil bych, tak Patterns of Enterprise Application Architecture (http://www.martinfowler.com/books/eaa.html) - zde jsou ukázky: http://www.martinfowler.com/eaaCatalog/. Kdo dělá nějakou obchodní aplikaci (a není patlal), hodně z toho použije (když teda nevyužije nějaký pochybný framework).
Každopádně Fowler je opravdový objektář, jeden z nejlepších, o tom žádná.
Název: Re:OOP - zdroje
Přispěvatel: SB 16. 08. 2016, 00:44:00
Myslíme v C++ je hodně špatná kniha. Zejména první díl jsou jen obecné řeči a hloupé příklady.

Neřešíme C++, ale OOP.

Nechci tu vyvolávat flamewár, už se to řešilo jinde, ale osobně(!) si myslím, že vysvětlovat OOP na C++ je krajně nevhodné, na to jsou jiné jazyky, takže knihám kombinujícím C++ a OOP bych se osobně(!) zdaleka vyhnul.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 16. 08. 2016, 00:56:30
Třeba protože stejné podmínky se v OOP téměř nevyskytují?

Na tom není nic objektového. Každý dostatečně bohatý jazyk kteréhokoli paradigmatu lze používat tak, aby se neduplikoval kód. A každý rozumný člověk píše programy tak, aby pokud možno nedocházelo k duplicitám.

Neříkáte to přesně - čím abstraktnější jazyk máte, tím znovupoužitelnější konstrukce můžete psát. Neboli duplicitám můžete zabránit jen na takové úrovni, na které vám to dovolí jazyk. Samo OOP má taky nástroje pro obecné konstrukce, např. dependency injection, dědičnost (ne nutně), delegování, ...
Název: Re:OOP - zdroje
Přispěvatel: Kit 16. 08. 2016, 01:01:22
Myslíme v C++ je hodně špatná kniha. Zejména první díl jsou jen obecné řeči a hloupé příklady.

Neřešíme C++, ale OOP.

Nechci tu vyvolávat flamewár, už se to řešilo jinde, ale osobně(!) si myslím, že vysvětlovat OOP na C++ je krajně nevhodné, na to jsou jiné jazyky, takže knihám kombinujícím C++ a OOP bych se osobně(!) zdaleka vyhnul.

Nakoukl jsem do ní a zjistil jsem, že na začátku se ani moc nezabývá C++, jako spíš OOP v obecné rovině. Takže celkově ta kniha může být docela dobrá zejména kvůli: "... první díl jsou jen obecné řeči a hloupé příklady".

Právě ty obecné řeči a "hloupé" příklady jsou při výuce OOP nejdůležitější. Jinak to programátor začne mydlit procedurálně, protože C++ k tomu silně svádí.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 16. 08. 2016, 01:06:31
Selský rozum je určitě potřeba, ale když už se mi na x-tém místě opakuje ta stejná podmínka, tak si říkám, že je asi něco špatně...

Proč i myslíš, že to znamená nedostatečně objektové myšlení?

Třeba protože stejné podmínky se v OOP téměř nevyskytují?

Na tom není nic objektového. Každý dostatečně bohatý jazyk kteréhokoli paradigmatu lze používat tak, aby se neduplikoval kód. A každý rozumný člověk píše programy tak, aby pokud možno nedocházelo k duplicitám.

Pokud je ta podmínka zapouzdřena v objektu společně s testovaným atributem, tak k duplicitě téměř dojít nemůže.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Inkvizitor 16. 08. 2016, 08:23:18
Pokud je ta podmínka zapouzdřena v objektu společně s testovaným atributem, tak k duplicitě téměř dojít nemůže.

Podmínka je v metodě a může být v té samé metodě kolikrát chce, může být v jiné metodě dané třídy (pokud má jazyk třídy a metody) a může být i v kterémkoli jiném objektu. Chtělo by to konkrétní příklady, kde OOP pomáhá nebo dokonce příklad, kde by to bez OOP rozumně nešlo.

A taky by mě zajímalo, v kterém konkrétním jazyce autor původního příspěvku ten neobjektový kód vidí. Protože by se mohlo ukázat, že to je třeba C++, které se bez objektů docela dobře obejde a pořád je možné přitom psát DRY kód.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Inkvizitor 16. 08. 2016, 08:25:26
Třeba protože stejné podmínky se v OOP téměř nevyskytují?

Na tom není nic objektového. Každý dostatečně bohatý jazyk kteréhokoli paradigmatu lze používat tak, aby se neduplikoval kód. A každý rozumný člověk píše programy tak, aby pokud možno nedocházelo k duplicitám.

Neříkáte to přesně - čím abstraktnější jazyk máte, tím znovupoužitelnější konstrukce můžete psát. Neboli duplicitám můžete zabránit jen na takové úrovni, na které vám to dovolí jazyk. Samo OOP má taky nástroje pro obecné konstrukce, např. dependency injection, dědičnost (ne nutně), delegování, ...

Chtělo by to příklad. Už i "blbé" C umožňuje používání callbacků, které toho vládnou pořešit opravdu hodně.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zmija 16. 08. 2016, 08:36:42
panove a com je rec? vzdyt C++ je jazyk kde sa da s OOP poradne vyhrat. Aspon nas na skole ucili, ze je to OOP jazyk. jste si jisti ze opravdu myslite OOP?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gamer 16. 08. 2016, 09:19:56
panove a com je rec? vzdyt C++ je jazyk kde sa da s OOP poradne vyhrat. Aspon nas na skole ucili, ze je to OOP jazyk. jste si jisti ze opravdu myslite OOP?

C++ je jedna z konkrétních implementací OOP a má svoje probémy. Namátkou nepodpora nativních interfaces, musí se to dělat přes abstraktní třídu, což vadí třeba když chci objekt implementující dva různé interface, vede to na vícenásobnou dědičnost se všemi negativními důsledky. V C++ je taky velice jednoduché střelit se do nohy, zapomenutý virtuální destructor v bázové třídě může být docela zábavný. Ze stejného důvodu není ani tohle dobrý nápad:
Kód: [Vybrat]
class MyVector : public std::vector
Pokud se OOP učím, nechci takové věci řešit.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zmija 16. 08. 2016, 09:28:04
ono nic neni dokonale a taky na 100%.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gamer 16. 08. 2016, 09:32:30
ono nic neni dokonale a taky na 100%.
Dokonalé není nic, ale na učení není dobrý jazyk, ve kterém nesmím dědit ze std::vector (a obecně žádné třídy, která nemá virtuální destructor), protože mi to může nedefinovaně rozbít aplikaci...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zmija 16. 08. 2016, 09:50:40
co tedy radis?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gamer 16. 08. 2016, 09:57:12
co tedy radis?
Když to sem napíšu, tak to skončí jako nekonečný flamewar, jestli je lepší A nebo B. Ať si každý používá co chce. Každopádně C++ je na učení OOP dobré jen pro člověka, který C++ velmi dobře ovládá. Což se tak trochu navzájem vylučuje...
Název: Re:OOP - zdroje
Přispěvatel: SB 16. 08. 2016, 13:58:40

Nakoukl jsem do ní a zjistil jsem, že na začátku se ani moc nezabývá C++, jako spíš OOP v obecné rovině. Takže celkově ta kniha může být docela dobrá zejména kvůli: "... první díl jsou jen obecné řeči a hloupé příklady".

Právě ty obecné řeči a "hloupé" příklady jsou při výuce OOP nejdůležitější. Jinak to programátor začne mydlit procedurálně, protože C++ k tomu silně svádí.

Zcela souhlasím, OOP je myšlenka, ne implementace. Ale pořád si nejsem jistý tou následnou implementací v C++. :)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 16. 08. 2016, 14:05:42
Neříkáte to přesně - čím abstraktnější jazyk máte, tím znovupoužitelnější konstrukce můžete psát. Neboli duplicitám můžete zabránit jen na takové úrovni, na které vám to dovolí jazyk. Samo OOP má taky nástroje pro obecné konstrukce, např. dependency injection, dědičnost (ne nutně), delegování, ...

Chtělo by to příklad. Už i "blbé" C umožňuje používání callbacků, které toho vládnou pořešit opravdu hodně.

Příklad: Chcete provést nějaký výpočet...
něco jako jazyk Karel: Téměř žádná abstrakce => můžete explicitně sečíst 4+5, obecnější zápis nejde;
něco jako Basic: abstrakce hodnoty proměnnou => už můžete vytvořit obecný výpočet a + b;
jazyk s funkcemi jako členy nebo uzávěrami => můžete do operace vstřikovat i postup výpočtu;
atd.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 16. 08. 2016, 14:10:13
panove a com je rec? vzdyt C++ je jazyk kde sa da s OOP poradne vyhrat. Aspon nas na skole ucili, ze je to OOP jazyk. jste si jisti ze opravdu myslite OOP?

...a učil vás to céčkař, ne?
Plno jazyků je OOP, ale některé jsou prostě víc OOP nebo se v nich jednodušeji OOP modeluje. Je to jasné?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 16. 08. 2016, 14:16:43
C++ je jedna z konkrétních implementací OOP a má svoje probémy. Namátkou nepodpora nativních interfaces, musí se to dělat přes abstraktní třídu, což vadí třeba když chci objekt implementující dva různé interface, vede to na vícenásobnou dědičnost se všemi negativními důsledky. V C++ je taky velice jednoduché střelit se do nohy, zapomenutý virtuální destructor v bázové třídě může být docela zábavný. Ze stejného důvodu není ani tohle dobrý nápad:
Kód: [Vybrat]
class MyVector : public std::vector
Pokud se OOP učím, nechci takové věci řešit.

A jste u toho - interface, abstraktní třída, dědičnost, virtuálnost, třída obecně - nic z toho není pro OOP nezbytné, je to způsob implementace v C++.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zmija 16. 08. 2016, 15:10:36
panove a com je rec? vzdyt C++ je jazyk kde sa da s OOP poradne vyhrat. Aspon nas na skole ucili, ze je to OOP jazyk. jste si jisti ze opravdu myslite OOP?

...a učil vás to céčkař, ne?
Plno jazyků je OOP, ale některé jsou prostě víc OOP nebo se v nich jednodušeji OOP modeluje. Je to jasné?

Ucil me to pan Ing. Peter Peringer, kterej je fakt trida v C/C++. To se mu musi uznat. Kdo studoval na FIT VUT, tak ho urcite zna.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 16. 08. 2016, 15:19:19
panove a com je rec? vzdyt C++ je jazyk kde sa da s OOP poradne vyhrat. Aspon nas na skole ucili, ze je to OOP jazyk. jste si jisti ze opravdu myslite OOP?

...a učil vás to céčkař, ne?
Plno jazyků je OOP, ale některé jsou prostě víc OOP nebo se v nich jednodušeji OOP modeluje. Je to jasné?

Ucil me to pan Ing. Peter Peringer, kterej je fakt trida v C/C++. To se mu musi uznat. Kdo studoval na FIT VUT, tak ho urcite zna.

Peringera znám velmi dobře. Určitě jsi ho pochopil špatně. V C++ se dá objektově programovat, ale pokud někdo programuje v C++, tak to vůbec nemusí znamenat, že skutečně objektově programuje, i když objekty používá.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: expert 16. 08. 2016, 15:44:53
Peringera znám velmi dobře. Určitě jsi ho pochopil špatně. V C++ se dá objektově programovat, ale pokud někdo programuje v C++, tak to vůbec nemusí znamenat, že skutečně objektově programuje, i když objekty používá.

Programuji v C++ a používám objekty, ale jak poznám, jestli programuji objektově? Mohl by ses rozepsat?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 16. 08. 2016, 15:50:30
Ucil me to pan Ing. Peter Peringer, kterej je fakt trida v C/C++. To se mu musi uznat. Kdo studoval na FIT VUT, tak ho urcite zna.

Beru, že je třeba dobrý v C++, ale o OOP to nic nevypovídá (céčkařů jsem viděl mraky, ale OOP nechápal snad ani jeden). Ať je to jakkoli, pro výuku OOP si vyberte jiný jazyk, nepřidělávejte si práci hned na začátku.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gl 16. 08. 2016, 15:54:01
Beru, že je třeba dobrý v C++, ale o OOP to nic nevypovídá (céčkařů jsem viděl mraky, ale OOP nechápal snad ani jeden). Ať je to jakkoli, pro výuku OOP si vyberte jiný jazyk, nepřidělávejte si práci hned na začátku.

Co znamená chápat OOP? Přijde mi, že z toho děláte zbytečně vědu.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Inkvizitor 16. 08. 2016, 15:55:00
Neříkáte to přesně - čím abstraktnější jazyk máte, tím znovupoužitelnější konstrukce můžete psát. Neboli duplicitám můžete zabránit jen na takové úrovni, na které vám to dovolí jazyk. Samo OOP má taky nástroje pro obecné konstrukce, např. dependency injection, dědičnost (ne nutně), delegování, ...

Chtělo by to příklad. Už i "blbé" C umožňuje používání callbacků, které toho vládnou pořešit opravdu hodně.

Příklad: Chcete provést nějaký výpočet...
něco jako jazyk Karel: Téměř žádná abstrakce => můžete explicitně sečíst 4+5, obecnější zápis nejde;
něco jako Basic: abstrakce hodnoty proměnnou => už můžete vytvořit obecný výpočet a + b;
jazyk s funkcemi jako členy nebo uzávěrami => můžete do operace vstřikovat i postup výpočtu;
atd.

OK, ale "neco jako Karel" ani "neco jako Basic" se v praxi nepouziva, takze se bavime minimalne o "jazyce s funkcemi jako cleny". Tam uz se da DRY velmi slusne pouzivat i bez "objektoveho mysleni".

Mne nejde o flamewar, pokud chce Ran delat OOP, at ho dela, ale zajima me, jestli jeho otazka nema falesny motiv, napr. zda si nemysli, ze OOP magicky vyresi problemy, ktere nejsou zpusobene tim, ze je kod "malo objektovy".
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ondra Satai Nekola 16. 08. 2016, 16:05:45
Co znamená chápat OOP? Přijde mi, že z toho děláte zbytečně vědu.

Mno, mozna to neni veda, ale spis takova kombinace vedy, umeni a remesla ;)

Clovek ma vetsinou po prvnim seznameni s OOP (nebo jinym paradigmem) tendenci ho pouzivat... ne uplne stastne.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gl 16. 08. 2016, 16:26:05
Co znamená chápat OOP? Přijde mi, že z toho děláte zbytečně vědu.

Mno, mozna to neni veda, ale spis takova kombinace vedy, umeni a remesla ;)

Clovek ma vetsinou po prvnim seznameni s OOP (nebo jinym paradigmem) tendenci ho pouzivat... ne uplne stastne.

Za to IMHO částečně mohou jazyky jako Java a C#, kde se objekty používají i pro strukturování kódu. Lidi se to potom snaží cpát všude.

Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ondra Satai Nekola 16. 08. 2016, 16:34:33
Co znamená chápat OOP? Přijde mi, že z toho děláte zbytečně vědu.

Mno, mozna to neni veda, ale spis takova kombinace vedy, umeni a remesla ;)

Clovek ma vetsinou po prvnim seznameni s OOP (nebo jinym paradigmem) tendenci ho pouzivat... ne uplne stastne.

Za to IMHO částečně mohou jazyky jako Java a C#, kde se objekty používají i pro strukturování kódu. Lidi se to potom snaží cpát všude.

To neni zas takovy problem, ve Smalltalku je to jeste duslednejsi...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kiwi 16. 08. 2016, 20:14:33
Bohužel, OOP je dnes příliš široký pojem. Takže bych možná volil opačnou cestu - jazyk a s ním i "jeho" pojetí OOP. Člověk zvyklý na "objektové" programování v C++ bude mít potíže s Javou a Ruby nerozdejchá vůbec. Buď uzná, že to nedává a půjde od toho (ta lepší varianta), nebo se bude pokoušet "objektově" programovat tak, jak je zvyklý z C++. A až to po něm bude číst javista resp. rubista, to bude takových nadávek...

Jinak co se mě týče, tak jsem céčkař, který se pak učil C++ a s ním i OOP, ale nějak jsem to tenkrát nepochopil a nic mi to neříkalo, co učebnice a jiní c++kaři považovali za úžasné, mi připadalo jako celkem zbytečné, ne-li přímo otravné, neustále mi unikaly ty úžasné výhody OOP. Zdrojáky programů v C++ mi připadaly delší a nepřehlednější než odpovídající kód v C, aniž by to přinášelo nějaké významné výhody, a tohoto dojmu jsem se nezbavil dodnes.
Po nějakém čase jsem se - na základě doporučení vyvolaném podobným žehráním, jako jsem napsal k C++ tady, ale před zkušenějším kolegou - dostal ke Smalltalku, u něhož si živě vzpomínám na ten moment, kdy by člověk vykřikl "heuréka!" Tím byl můj pohled na OOP zformován a tím jsem odsouzen k jazykům jako Objective C, Ruby, Python apod., chci-li psát objektově, aniž bych přitom musel nadávat jak špaček, jako je tomu u Javy nebo nedej bože u C++.
Když bych se ale zamyslel, kolik projektů bylo C++ a kolik Python, tak bych musel říct, že na chleba jsem si vydělával tím C++. A vydělávat si prací, kterou od srdce nesnášíte...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 16. 08. 2016, 20:28:45
Po nějakém čase jsem se ... dostal ke Smalltalku, u něhož si živě vzpomínám na ten moment, kdy by člověk vykřikl "heuréka!" Tím byl můj pohled na OOP zformován a tím jsem odsouzen k jazykům jako Objective C, Ruby, Python apod., chci-li psát objektově, aniž bych přitom musel nadávat jak špaček, jako je tomu u Javy nebo nedej bože u C++.

To bude asi ono. Mnoho z těch, kteří chválí OOP v C++ si jednoduše nevyzkoušelo, jak je to s OOP v jiných jazycích, např. ve jmenovaném Smalltalku. Vždyť i v proklínaném PHP je OOP na mnohem vyšším levelu než v C++.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zmija 16. 08. 2016, 21:30:12
no pockat. srovnavat C++ a PHP to je teda katastrofa. Ne ne. To nedelejte.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ran 16. 08. 2016, 21:48:21

Citace
Mne nejde o flamewar, pokud chce Ran delat OOP, at ho dela, ale zajima me, jestli jeho otazka nema falesny motiv, napr. zda si nemysli, ze OOP magicky vyresi problemy, ktere nejsou zpusobene tim, ze je kod "malo objektovy".

Nemyslím, že jde o falešný motiv. Pouze jsem jako většina lidí začínal s procedurálním programováním a tak nějak "cítím", že jsem se od něj ještě úplně neodprostil. Teď jsem viděl nějaké přednášky, většinou od lidí co vyrostli na smalltalku a přišlo mi že se mám ještě hodně co učit, tak jsem se jen zeptal na nějaké materiály co se osvědčili vám všem...

Citace
Po nějakém čase jsem se - na základě doporučení vyvolaném podobným žehráním, jako jsem napsal k C++ tady, ale před zkušenějším kolegou - dostal ke Smalltalku, u něhož si živě vzpomínám na ten moment, kdy by člověk vykřikl "heuréka!"

I tak nějak by se to dalo popsat, akorát jsem zatím stále před tím "heuréka"...

Citace
Za to IMHO částečně mohou jazyky jako Java a C#, kde se objekty používají i pro strukturování kódu.

+1

Tzn. chci se jen učit... :)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 16. 08. 2016, 21:49:22
no pockat. srovnavat C++ a PHP to je teda katastrofa. Ne ne. To nedelejte.

Srovnávám OOP v C++ vs. OOP v PHP.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 16. 08. 2016, 21:53:09
Nemyslím, že jde o falešný motiv. Pouze jsem jako většina lidí začínal s procedurálním programováním a tak nějak "cítím", že jsem se od něj ještě úplně neodprostil. Teď jsem viděl nějaké přednášky, většinou od lidí co vyrostli na smalltalku a přišlo mi že se mám ještě hodně co učit, tak jsem se jen zeptal na nějaké materiály co se osvědčili vám všem...

Tak na chvíli odlož C++, nainstaluj si Smalltalk a zkoušej si příklady. I když se pak vrátíš k C++, to objektové myšlení ti zůstane.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ran 16. 08. 2016, 21:56:07
Citace
Tak na chvíli odlož C++, nainstaluj si Smalltalk a zkoušej si příklady.

Asi to bude nejlepší možnost.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: balki 16. 08. 2016, 22:42:05
Bohužel, OOP je dnes příliš široký pojem. Takže bych možná volil opačnou cestu - jazyk a s ním i "jeho" pojetí OOP. Člověk zvyklý na "objektové" programování v C++ bude mít potíže s Javou a Ruby nerozdejchá vůbec. Buď uzná, že to nedává a půjde od toho (ta lepší varianta), nebo se bude pokoušet "objektově" programovat tak, jak je zvyklý z C++. A až to po něm bude číst javista resp. rubista, to bude takových nadávek...

Jinak co se mě týče, tak jsem céčkař, který se pak učil C++ a s ním i OOP, ale nějak jsem to tenkrát nepochopil a nic mi to neříkalo, co učebnice a jiní c++kaři považovali za úžasné, mi připadalo jako celkem zbytečné, ne-li přímo otravné, neustále mi unikaly ty úžasné výhody OOP. Zdrojáky programů v C++ mi připadaly delší a nepřehlednější než odpovídající kód v C, aniž by to přinášelo nějaké významné výhody, a tohoto dojmu jsem se nezbavil dodnes.
Po nějakém čase jsem se - na základě doporučení vyvolaném podobným žehráním, jako jsem napsal k C++ tady, ale před zkušenějším kolegou - dostal ke Smalltalku, u něhož si živě vzpomínám na ten moment, kdy by člověk vykřikl "heuréka!" Tím byl můj pohled na OOP zformován a tím jsem odsouzen k jazykům jako Objective C, Ruby, Python apod., chci-li psát objektově, aniž bych přitom musel nadávat jak špaček, jako je tomu u Javy nebo nedej bože u C++.
Když bych se ale zamyslel, kolik projektů bylo C++ a kolik Python, tak bych musel říct, že na chleba jsem si vydělával tím C++. A vydělávat si prací, kterou od srdce nesnášíte...

Myslim si opak, ked sa clovek nauci principy oop, potom mu bude lahsie sa adaptovat na obmedzenia jazykov. OOP je len jedno, je otazka, ako ho kto zhovadi :)

Staci zacat v niecom inom, ako C++ a vsetko vporadku.

Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kiwi 17. 08. 2016, 01:51:43
To bude asi ono. Mnoho z těch, kteří chválí OOP v C++ si jednoduše nevyzkoušelo, jak je to s OOP v jiných jazycích, např. ve jmenovaném Smalltalku. Vždyť i v proklínaném PHP je OOP na mnohem vyšším levelu než v C++.
Vyhovuje-li jim to, nemají důvod zkoušet jiné přístupy, ba dokonce by se jim IMHO zdály nesprávné. A je známá věc, že přístup, jenž si člověk osvojí jako první, se pro něj stane velmi svazující.

Pouze jsem jako většina lidí začínal s procedurálním programováním a tak nějak "cítím", že jsem se od něj ještě úplně neodprostil.
Nemyslím si, že by procedurální programování bylo ve sporu s objektovým. OOP je abstrakčně výš. Řeší principy, jakými se zachází s jednotlivými elementy programu, jak spolu interagují data a algoritmy. Procedurální přístup tuto problematiku vůbec neřeší, to je na autorovi programu, aby si to sám specifikoval. Jestliže strukturované programování přináší principy a nástroje k abstraktivizaci a interpretaci dat a k organizaci kódu (místo aby to musel dělat programátor "ručně"), tak OOP se snaží pomoci rozlousknout problém, jak to zařídit, aby si data vždy našla cestu k tomu správnému algoritmu, který je zpracuje (místo aby to musel dělat programátor "ručně"). Na jakém substrátu je to celé vybudované, jestli procedurálním či jiném, není nijak zvlášť podstatné. Čímž netvrdím, že ten substrát nebude mít na výslednou podobu mechanismů OOP žádný vliv.

Citace
I tak nějak by se to dalo popsat, akorát jsem zatím stále před tím "heuréka"...
Ten moment přijde, když najednou člověk vidí, že to, co jsem o OOP napsal v odstavci výše, mu pod rukama opravdu funguje a že k tomu, aby stejnou funkcionalitu implementoval v neobjektovém prostředí, musel by napsat násobně více kódu. Alespoň teda u mě to tak bylo.

I když se pak vrátíš k C++, to objektové myšlení ti zůstane.
Myslim si opak, ked sa clovek nauci principy oop, potom mu bude lahsie sa adaptovat na obmedzenia jazykov.
Tím si právě nejsem tak úplně jist. Člověk si snadněji zvyká na komfort než na omezení.

Citace
OOP je len jedno
Jenže různí lidé si ho představují různě a obvykle jsou přesvědčeni o správnosti té své představy (včetně mě  :) ). A protože nerad ztrácím čas hádkami, tak se podobně kategorickým výrokům raději vyhýbám. Jestli má někdo pocit, že objektový program se získá tak, že se funkce a proměnné (nějak) natlačí do tříd a zařídí se, aby to bylo (za každou cenu) v dědické hierarchii a napíše se getInstance, protože to tak přece měli v tej brožuře "Pepek Vyskoč: Jak se naučit psát ten nejvíc dokonalej objektovej kód za 10 dnů", tak je to jeho věc.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: balki 17. 08. 2016, 02:35:50
Citace
OOP je len jedno
Jenže různí lidé si ho představují různě a obvykle jsou přesvědčeni o správnosti té své představy (včetně mě  :) ). A protože nerad ztrácím čas hádkami, tak se podobně kategorickým výrokům raději vyhýbám. Jestli má někdo pocit, že objektový program se získá tak, že se funkce a proměnné (nějak) natlačí do tříd a zařídí se, aby to bylo (za každou cenu) v dědické hierarchii a napíše se getInstance, protože to tak přece měli v tej brožuře "Pepek Vyskoč: Jak se naučit psát ten nejvíc dokonalej objektovej kód za 10 dnů", tak je to jeho věc.

Pokial si clovek mysli o OOP kraviny a kasle na autority v tomto obore, tak je tych objektovych programovani aj 750.38 . Podobnym vyhlaseniam sa nevyhybam, lebo o "paradigmach" (hlupy nazov, ale pouziva sa)  som mal bakalarku, diplomovku a (bohuzial) aj nedokoncenu dizertacku. Su univerzalne principy, ktore vymysleli mudri ludia, ked sa zanedba ich vyuka, clovek potom objavuje znova koleso.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 17. 08. 2016, 09:24:21
Co znamená chápat OOP? Přijde mi, že z toho děláte zbytečně vědu.

Chápat způsob modelování (struktury, organizace) a výpočtu.
Koncept OOP je poměrně jednoduchý, skutečnou vědu z něj udělaly právě až jazyky jako Java, C++ aj., vizte https://forum.root.cz/index.php?topic=13697.msg175279#msg175279 .
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 17. 08. 2016, 09:29:43
OK, ale "neco jako Karel" ani "neco jako Basic" se v praxi nepouziva, takze se bavime minimalne o "jazyce s funkcemi jako cleny". Tam uz se da DRY velmi slusne pouzivat i bez "objektoveho mysleni".

Mne nejde o flamewar, pokud chce Ran delat OOP, at ho dela, ale zajima me, jestli jeho otazka nema falesny motiv, napr. zda si nemysli, ze OOP magicky vyresi problemy, ktere nejsou zpusobene tim, ze je kod "malo objektovy".

Jasně, nebudeme tu řešit kde kolik, chtěl jsem tím jen ukázat, že hodně abstraktní jazyky dokážou značně zmenšit velikost kódu a zvýšit znovupoužitelnost komponent. Sice (skoro) ve všech jazycích jde (skoro) všechno, ale v každých jinak složitě. Už jen proto si jazyky nikdy nebudou rovny (jak někteří tvrdí).

A to souvisí s druhou částí odpovědi - záleží, co chce tazatel dělat, OOP je vhodné pouze na omezenou skupinu problémů.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 17. 08. 2016, 09:46:47
Bohužel, OOP je dnes příliš široký pojem. Takže bych možná volil opačnou cestu - jazyk a s ním i "jeho" pojetí OOP. Člověk zvyklý na "objektové" programování v C++ bude mít potíže s Javou a Ruby nerozdejchá vůbec. Buď uzná, že to nedává a půjde od toho (ta lepší varianta), nebo se bude pokoušet "objektově" programovat tak, jak je zvyklý z C++. A až to po něm bude číst javista resp. rubista, to bude takových nadávek...

Jinak co se mě týče, tak jsem céčkař, který se pak učil C++ a s ním i OOP, ale nějak jsem to tenkrát nepochopil a nic mi to neříkalo, co učebnice a jiní c++kaři považovali za úžasné, mi připadalo jako celkem zbytečné, ne-li přímo otravné, neustále mi unikaly ty úžasné výhody OOP. Zdrojáky programů v C++ mi připadaly delší a nepřehlednější než odpovídající kód v C, aniž by to přinášelo nějaké významné výhody, a tohoto dojmu jsem se nezbavil dodnes.
Po nějakém čase jsem se - na základě doporučení vyvolaném podobným žehráním, jako jsem napsal k C++ tady, ale před zkušenějším kolegou - dostal ke Smalltalku, u něhož si živě vzpomínám na ten moment, kdy by člověk vykřikl "heuréka!" Tím byl můj pohled na OOP zformován a tím jsem odsouzen k jazykům jako Objective C, Ruby, Python apod., chci-li psát objektově, aniž bych přitom musel nadávat jak špaček, jako je tomu u Javy nebo nedej bože u C++.
Když bych se ale zamyslel, kolik projektů bylo C++ a kolik Python, tak bych musel říct, že na chleba jsem si vydělával tím C++. A vydělávat si prací, kterou od srdce nesnášíte...

Zažil jsem téměř to samé: Od mala mě lámali myšlení do imperativního, OOP mi začalo dávat smysl (opět po několika letech těžkého lámání mysli) až (klidně ať se někteří naserou) se Smalltalkem, přišlo něco jako prohlédnutí. Když se k tomu časem přidalo pochopení prototypování (je snad ještě jednodušší než třídně-instanční implementace), je to ono.

K jazykům: Osobně(!) jazyk, který nepodporuje velmi pozdní vazbu (very late binding), nepovažuju za objektový. Takových moc není.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 17. 08. 2016, 10:32:30
Nemyslím, že jde o falešný motiv. Pouze jsem jako většina lidí začínal s procedurálním programováním a tak nějak "cítím", že jsem se od něj ještě úplně neodprostil. Teď jsem viděl nějaké přednášky, většinou od lidí co vyrostli na smalltalku a přišlo mi že se mám ještě hodně co učit, tak jsem se jen zeptal na nějaké materiály co se osvědčili vám všem...

...

I tak nějak by se to dalo popsat, akorát jsem zatím stále před tím "heuréka"...

Tzn. chci se jen učit... :)

Tak vám to zkrátím: O OOP bylo vymláceno už hodně prázdné slámy (převážně těmi, co tom nic nevědí).

Buďto chcete používat OOP v mainstreamových jazycích - s tím vám radit nebudu,
nebo chcete OOP pochopit - stáhněte si z http://pharo.org/ celé prostředí (stačí rozbalit a spustit) a můžete začít.
Z literatury doporučuju jeden z nejlepších textů pro začátečníky, a to 201EVojtěch Merunka: Objektové metody a přístupy -  Smalltalk-80 (učební text)201C, bohužel si ho budete muset opatřit legálně např. dotazem autorovi. Případně je možno dohledat jeho volně dostupné texty, např. z konference Objekty (konané v ČR).
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 17. 08. 2016, 10:34:19
Tak na chvíli odlož C++, nainstaluj si Smalltalk a zkoušej si příklady. I když se pak vrátíš k C++, to objektové myšlení ti zůstane.

Zůstane, akorát zjistí, že to, co šlo ve Smalltalku, už jinde nejde a bude nasraný.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: podlesh 17. 08. 2016, 11:06:24
Já osobně zastávám názor, že každý OOP programátor má mít nějaké zkušenosti s funkcionálním programováním. Jinak zůstane stále svázán v imperativním světě.  Zmiňovaný smalltalk samozřejmě také pomůže, ale FP je IMHO lepší na uvědomění si užitku dekompozice/kompozice (což je dle mých praktických zkušeností hlavní problém s imperativním programováním).

Bohužel z nějakého nepochopitelného důvodu hodně VŠ kompletně FP přeskakují :-( Přitom od toho studium na VŠ je, aby si člověk vyzkoušel ty "v praxi nepoužívané" věci.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: v 17. 08. 2016, 11:16:06
Bohužel z nějakého nepochopitelného důvodu hodně VŠ kompletně FP přeskakují :-( Přitom od toho studium na VŠ je, aby si člověk vyzkoušel ty "v praxi nepoužívané" věci.
VŠ slouží jako "soustavná příprava na budoucí povolání", je tedy nesmysl tam učit věci, které se v praxi nepoužívají
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 17. 08. 2016, 11:19:12
panove a com je rec? vzdyt C++ je jazyk kde sa da s OOP poradne vyhrat. Aspon nas na skole ucili, ze je to OOP jazyk. jste si jisti ze opravdu myslite OOP?
Chraň nás bůh před takovou školou ;)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 17. 08. 2016, 11:21:32
Beru, že je třeba dobrý v C++, ale o OOP to nic nevypovídá (céčkařů jsem viděl mraky, ale OOP nechápal snad ani jeden). Ať je to jakkoli, pro výuku OOP si vyberte jiný jazyk, nepřidělávejte si práci hned na začátku.

Co znamená chápat OOP? Přijde mi, že z toho děláte zbytečně vědu.
To je neobratná fráze znamenající, že dotyčný zná koncepci a abstrakce skrývající se za OOP. Podobně "chápat FP" je jen nešikovná fráze pro hlubokou znalost teorie typů a monád.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ondra Satai Nekola 17. 08. 2016, 11:23:38
Bohužel z nějakého nepochopitelného důvodu hodně VŠ kompletně FP přeskakují :-( Přitom od toho studium na VŠ je, aby si člověk vyzkoušel ty "v praxi nepoužívané" věci.
VŠ slouží jako "soustavná příprava na budoucí povolání", je tedy nesmysl tam učit věci, které se v praxi nepoužívají

1) FP a FP-inspired se v praxi pouziva, cim dal vice. Viz trebas zmeny v Jave 8.
2) i kdyby ne - pripravou na povolani neni jenom to, co se v praxi pouziva. Muze to byt i kontext, ktery neaplikujes primo, ale pomaha ti.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: balki 17. 08. 2016, 11:32:42
Bohužel z nějakého nepochopitelného důvodu hodně VŠ kompletně FP přeskakují :-( Přitom od toho studium na VŠ je, aby si člověk vyzkoušel ty "v praxi nepoužívané" věci.
VŠ slouží jako "soustavná příprava na budoucí povolání", je tedy nesmysl tam učit věci, které se v praxi nepoužívají

Na fiit stuba sa funkcionalne programovanie aspon za mojich cias ucilo, urcite sa uci aj teraz. VS nie je len o tom, co sa pouziva v praxi, ale o sirsom vzdelani.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: podlesh 17. 08. 2016, 13:34:59
Bohužel z nějakého nepochopitelného důvodu hodně VŠ kompletně FP přeskakují :-( Přitom od toho studium na VŠ je, aby si člověk vyzkoušel ty "v praxi nepoužívané" věci.
VŠ slouží jako "soustavná příprava na budoucí povolání", je tedy nesmysl tam učit věci, které se v praxi nepoužívají

1) FP a FP-inspired se v praxi pouziva, cim dal vice. Viz trebas zmeny v Jave 8.
2) i kdyby ne - pripravou na povolani neni jenom to, co se v praxi pouziva. Muze to byt i kontext, ktery neaplikujes primo, ale pomaha ti.
+10

Tohle je právě typický případ: stykem s "v praxi nepoužívanou věci" se hodně naučí i člověk který pak celý život bude používat Javu, C++ nebo třeba python. A v praxi je to znát.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 17. 08. 2016, 14:24:25
+10

Tohle je právě typický případ: stykem s "v praxi nepoužívanou věci" se hodně naučí i člověk který pak celý život bude používat Javu, C++ nebo třeba python. A v praxi je to znát.

Hlavním smyslem přece je, aby zjistil, že to třeba jde lépe než s Javou, C++ a Pythonem!
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: BoneFlute 17. 08. 2016, 15:57:24
Pochopení OOP mi nejvíce přineslo když jsem začal psát v Haskellu a v Erlangu. Taky mi hodně pomohlo nastudovat teorii objektů, aktorů, a agentů. Zjistil jsem, že spousta věcí je jinak. Ve výsledku to pociťuji v kvalitě mého kódu. I když zrovna OOP se v tom zrovna moc nevyznamenal.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 17. 08. 2016, 18:24:15
Pochopení OOP mi nejvíce přineslo když jsem začal psát v Haskellu a v Erlangu. Taky mi hodně pomohlo nastudovat teorii objektů, aktorů, a agentů. Zjistil jsem, že spousta věcí je jinak. Ve výsledku to pociťuji v kvalitě mého kódu. I když zrovna OOP se v tom zrovna moc nevyznamenal.
Pohled z jiného úhlu je vždy prospěšný. Smalltalk, Haskell apod. by měl znát (na základní úrovni) každý.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 17. 08. 2016, 18:41:41
Pochopení OOP mi nejvíce přineslo když jsem začal psát v Haskellu a v Erlangu. Taky mi hodně pomohlo nastudovat teorii objektů, aktorů, a agentů. Zjistil jsem, že spousta věcí je jinak. Ve výsledku to pociťuji v kvalitě mého kódu. I když zrovna OOP se v tom zrovna moc nevyznamenal.
Pohled z jiného úhlu je vždy prospěšný. Smalltalk, Haskell apod. by měl znát (na základní úrovni) každý.

Podobně by každý programátor měl znát i Lisp, i když v něm programovat nebude. Jeho vnitřní jednoduchost je prostě úžasná.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gl 17. 08. 2016, 19:17:55
Pohled z jiného úhlu je vždy prospěšný. Smalltalk, Haskell apod. by měl znát (na základní úrovni) každý.

Používáte někdo Smalltalk na něco praktického?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Honza 17. 08. 2016, 20:23:34
Pohled z jiného úhlu je vždy prospěšný. Smalltalk, Haskell apod. by měl znát (na základní úrovni) každý.

Používáte někdo Smalltalk na něco praktického?

Ano, webovky - intranet, informační systémy, evidence
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zmija 17. 08. 2016, 20:45:54
a kde to pouzivaji? protoze ja jsem na profesii a ani na jobs.cz nevidel zadne ponuky na smalltalk. Co delate ve volnym case, nas nezajima..
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ondra Satai Nekola 17. 08. 2016, 20:54:14
Pohled z jiného úhlu je vždy prospěšný. Smalltalk, Haskell apod. by měl znát (na základní úrovni) každý.

Používáte někdo Smalltalk na něco praktického?

Odpoved "ne" by stejne byla irelevantni k otazce, zda je dobre se s nim obeznamit.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zmija 17. 08. 2016, 20:56:02
ja delam 6 let jenom v C#. je to spatny nebo? zkusil jsem c/c++, perl, python, pascal, delphi. Ale to jenom ve skole. nic komercniho. ted jen C#
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gl 17. 08. 2016, 21:03:05
Odpoved "ne" by stejne byla irelevantni k otazce, zda je dobre se s nim obeznamit.

Na co se hodí nejlépe? Na jakém typu úloh je nejlepší si ho vyzkoušet?

Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Honza 17. 08. 2016, 21:09:28
a kde to pouzivaji? protoze ja jsem na profesii a ani na jobs.cz nevidel zadne ponuky na smalltalk. Co delate ve volnym case, nas nezajima..
Jedno řešení ve Smalltalku používá třeba ČSOB, (lze dohledat jako success story) ale to jsem nedělal já, a jako freelancera mě zase nezajímá, jaké nabídky nejsou na jobs.cz...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 17. 08. 2016, 21:12:51
ja delam 6 let jenom v C#. je to spatny nebo? zkusil jsem c/c++, perl, python, pascal, delphi. Ale to jenom ve skole. nic komercniho. ted jen C#

C# špatný není, na desktopové aplikace pro Windows asi nejlepší. Dokonce v něm někteří programují i objektově.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gl 17. 08. 2016, 21:20:17
C# špatný není, na desktopové aplikace pro Windows asi nejlepší. Dokonce v něm někteří programují i objektově.

Pokud ti nevadí, že ty aplikace vyžadují správnou verzi .NET frameworku a žerou velké množství paměti. Oproti Delphi dost diskutabilní přínos.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zmija 17. 08. 2016, 21:38:35
jo tak kdyz vyuzivas veci z nejakych knihoven, ktere nemas k dispozici nebo nejsou aktualni, tak se nediv. jako muzu delat neco v jave 8, ale kdyz ji nemam nainstalovanou a bezi mi tam jenom java 5, tak to asi  nepojede, ne? taky kombinace c++ a qt. neni o cem. lepsi nez C# ve spojeni s WPF pro windows nenajdes. to je proste poradnej kalibr.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 17. 08. 2016, 21:47:48
C# špatný není, na desktopové aplikace pro Windows asi nejlepší. Dokonce v něm někteří programují i objektově.

Pokud ti nevadí, že ty aplikace vyžadují správnou verzi .NET frameworku a žerou velké množství paměti. Oproti Delphi dost diskutabilní přínos.

Nevadí, protože je nepoužívám. Chtěl jsem jen dát uživatelům Windows trochu optimismu.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gl 17. 08. 2016, 21:49:50
jo tak kdyz vyuzivas veci z nejakych knihoven, ktere nemas k dispozici nebo nejsou aktualni, tak se nediv. jako muzu delat neco v jave 8, ale kdyz ji nemam nainstalovanou a bezi mi tam jenom java 5, tak to asi  nepojede, ne? taky kombinace c++ a qt. neni o cem. lepsi nez C# ve spojeni s WPF pro windows nenajdes. to je proste poradnej kalibr.

K čemu potřebuješ pořádný kalibr? Dá se .NET zakompilovat do aplikace jako qt?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gl 17. 08. 2016, 21:52:53
Nevadí, protože je nepoužívám. Chtěl jsem jen dát uživatelům Windows trochu optimismu.

Uživatelé Windows by byly šťastnější, kdyby .NET neexistoval.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Mirek Prýmek 17. 08. 2016, 21:57:08
Uživatelé Windows by byly šťastnější, kdyby .NET neexistoval.
Chtěl jsi říct "uživatelky", ne? :)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gl 17. 08. 2016, 22:09:37
Uživatelé Windows by byly šťastnější, kdyby .NET neexistoval.
Chtěl jsi říct "uživatelky", ne? :)

Proč uživatelky? Stačí porovnat rychlost a paměťové nároky Visual Studia 2008 a 2010. Pokud vím, za zpomalení z velké části může používání .NET a WPF. Windows už pravidelně nepoužívám a desktopové aplikace jsem nikdy profesionálně nedělal. Možná se pletu.

Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zmija 17. 08. 2016, 22:14:29
jo tak kdyz vyuzivas veci z nejakych knihoven, ktere nemas k dispozici nebo nejsou aktualni, tak se nediv. jako muzu delat neco v jave 8, ale kdyz ji nemam nainstalovanou a bezi mi tam jenom java 5, tak to asi  nepojede, ne? taky kombinace c++ a qt. neni o cem. lepsi nez C# ve spojeni s WPF pro windows nenajdes. to je proste poradnej kalibr.

K čemu potřebuješ pořádný kalibr? Dá se .NET zakompilovat do aplikace jako qt?
jakej ucel by to melo mit? kdyz delam pro windows nejakou aplikaci, tak se to nemusi kompilovat do aplikace, protoze ta aplikace pojede na windowsech a tam ten .NET je. nebo by mel byt. win10 ma .NET 4.6. jiste, kdyz pojede aplikace na .NET 4.6 a ja ji pustim na stroji, kde je .NET 4.0, tak to nepojede. sorry kamo, ale jako clovek, kterej dela kazdej den se C#, tak ti muzu rict, ze lepsi appku ve spojeni C#+WPF pro windows neudelas. muzes psat kolik chces, ze Qt je multiplatformni a podobne kravoviny, jednoducho je to neprustrelnej fakt. A je jen otazka casu, kdyz i .NET se rozsiri na linux a dal. uz ted vysel .NET Core 1.0.
Kdysi jsem instaloval Qt, protoze to bylo potrebny pro jeden projekt ve skole. Asi 4 hodiny to instalovalo a ono se to zaseklo!!! dal jsem to od zacatku a dalsi 4 hodiny. Bylo to uspesny, konecne! Vyvoj nic moc. Ty signaly a sloty, to mi moc nesedlo.
Ja chapu, ze tady je plno linux fans, jenom dost z nich ma problem uznat, ze nektery veci jsou proste lepsi na windows, nebo se daji udelat daleko lip s nejakou MS technologii.
Sam jsem pouzival linux na skole. System dobrej pro servry, nebo pro takove to obycejni vyuziti PC. Jenomze jako OS, kde mam neco vyvijet, no hruza.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: balki 17. 08. 2016, 22:34:44
Ja poufivam jedine swift. Uf pol roka :) Niefom zmija fom ftefan :) Fwift bude vfade.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gl 17. 08. 2016, 22:35:05
jo tak kdyz vyuzivas veci z nejakych knihoven, ktere nemas k dispozici nebo nejsou aktualni, tak se nediv. jako muzu delat neco v jave 8, ale kdyz ji nemam nainstalovanou a bezi mi tam jenom java 5, tak to asi  nepojede, ne? taky kombinace c++ a qt. neni o cem. lepsi nez C# ve spojeni s WPF pro windows nenajdes. to je proste poradnej kalibr.

K čemu potřebuješ pořádný kalibr? Dá se .NET zakompilovat do aplikace jako qt?
jakej ucel by to melo mit? kdyz delam pro windows nejakou aplikaci, tak se to nemusi kompilovat do aplikace, protoze ta aplikace pojede na windowsech a tam ten .NET je. nebo by mel byt. win10 ma .NET 4.6. jiste, kdyz pojede aplikace na .NET 4.6 a ja ji pustim na stroji, kde je .NET 4.0, tak to nepojede. sorry kamo, ale jako clovek, kterej dela kazdej den se C#, tak ti muzu rict, ze lepsi appku ve spojeni C#+WPF pro windows neudelas. muzes psat kolik chces, ze Qt je multiplatformni a podobne kravoviny, jednoducho je to neprustrelnej fakt. A je jen otazka casu, kdyz i .NET se rozsiri na linux a dal. uz ted vysel .NET Core 1.0.
Kdysi jsem instaloval Qt, protoze to bylo potrebny pro jeden projekt ve skole. Asi 4 hodiny to instalovalo a ono se to zaseklo!!! dal jsem to od zacatku a dalsi 4 hodiny. Bylo to uspesny, konecne! Vyvoj nic moc. Ty signaly a sloty, to mi moc nesedlo.
Ja chapu, ze tady je plno linux fans, jenom dost z nich ma problem uznat, ze nektery veci jsou proste lepsi na windows, nebo se daji udelat daleko lip s nejakou MS technologii.
Sam jsem pouzival linux na skole. System dobrej pro servry, nebo pro takove to obycejni vyuziti PC. Jenomze jako OS, kde mam neco vyvijet, no hruza.

Pořád jsem se nedozvěděl, v čem jsou ty výsledné aplikace pro koncového uživatele lepší.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 17. 08. 2016, 22:56:07
Ja poufivam jedine swift. Uf pol roka :) Niefom zmija fom ftefan :) Fwift bude vfade.
Co hulíš?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: balki 17. 08. 2016, 23:01:35
Ja poufivam jedine swift. Uf pol roka :) Niefom zmija fom ftefan :) Fwift bude vfade.
Co hulíš?

Ano :)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 17. 08. 2016, 23:16:07
Ja poufivam jedine swift. Uf pol roka :) Niefom zmija fom ftefan :) Fwift bude vfade.
Co hulíš?

Ano :)

I s EET a Čapím hnízdem? To musí být matroš!
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: BoneFlute 18. 08. 2016, 02:04:34
tak ti muzu rict, ze lepsi appku ve spojeni C#+WPF pro windows neudelas. muzes psat kolik chces, ze Qt je multiplatformni a podobne kravoviny, jednoducho je to neprustrelnej fakt.
Kdybych měl euro za každé takové sebejisté prohlášení, tak jsem Elon Musc.

A je jen otazka casu, kdyz i .NET se rozsiri na linux a dal. uz ted vysel .NET Core 1.0.
Řekl bych že Foundation byl větší kalibr, a nechytlo se to. Takže nás nevystrašíš.

Sam jsem pouzival linux na skole. System dobrej pro servry, nebo pro takove to obycejni vyuziti PC. Jenomze jako OS, kde mam neco vyvijet, no hruza.
Tak já ti mohu jen popřát, ať ti to nadšení vydrží. Ostatně proč ne.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zmija 18. 08. 2016, 08:08:07
Citace
Kdybych měl euro za každé takové sebejisté prohlášení, tak jsem Elon Musc.
Chtel bys to snad poprit? Nestojim o to srat se s instalovanim a rozchozenim Qt, kdyz muzu pouzit lepsi nastroj a primo pro to urceny. Samozrejme, kdyz delam pro windows.

Citace
Řekl bych že Foundation byl větší kalibr, a nechytlo se to. Takže nás nevystrašíš.
.NET pojede jeste dal ;)

Citace
Tak já ti mohu jen popřát, ať ti to nadšení vydrží. Ostatně proč ne.
Jo, takze na linuxu, kterej jsem vyzkousel, by bylo me nadseni obrovsky a nechtel bych nic jinyho. :D Proc bych se mal jako zajimat o platformu, ktera je beztak mrtva a nabidky na linux jsou beztak jenom sami administratori?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gamer 18. 08. 2016, 08:34:37
Jo, takze na linuxu, kterej jsem vyzkousel, by bylo me nadseni obrovsky a nechtel bych nic jinyho. :D Proc bych se mal jako zajimat o platformu, ktera je beztak mrtva a nabidky na linux jsou beztak jenom sami administratori?

Tak záleží na tom, co chceš dělat. Pokud tě baví aplikace typu informační/účetní systém 100x jinak, tak se o ostatní platformy nezajímej, vystačíš si s C# a Windows. Kdybys chtěl dělat něco zajímavějšího, jako třeba big data, machine learning, AI, hry (ne PS4 opravdu není Windows), velké server backendy..., tak se s C# ani Windows vůbec nechytáš.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zmija 18. 08. 2016, 08:44:21
Citace
Tak záleží na tom, co chceš dělat. Pokud tě baví aplikace typu informační/účetní systém 100x jinak, tak se o ostatní platformy nezajímej, vystačíš si s C# a Windows. Kdybys chtěl dělat něco zajímavějšího, jako třeba big data, machine learning, AI, hry (ne PS4 opravdu není Windows), velké server backendy..., tak se s C# ani Windows vůbec nechytáš.

nemas pravdu, co se tyce her. herni studio neni odkazano jenom na linux. pouziva ruzne OS (OSx, Windows, Linux). AI a big data muzes delat taky na windowsu.
Proc si vsichni mysli, ze se na windowsu delaji jenom IS nebo ucetni systemy? To jsou ti lidi tak obmezeni? Nejlepsi, kdyz do toho keca linux administrator :D
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gamer 18. 08. 2016, 09:00:44
nemas pravdu, co se tyce her. herni studio neni odkazano jenom na linux. pouziva ruzne OS (OSx, Windows, Linux). AI a big data muzes delat taky na windowsu.

Herní studio, pokud chce přežít, tak nesmí vyvíjet primárně pro Windows, tam se prodá minimum her. 90% prodejů dělají konzole, PC je jen 10%. V konzolích momentálně PS4 docela válcuje XBOX One, takže Windows je minoritní platforma. Co se týká mobilních her, má smysl uvažovat jen o Androidu a iPhone, Windows jsou úplně mimo.

AI je hodně široký pojem, něco se dá určitě dělat i na Windows, ale třeba tohle: https://en.wikipedia.org/wiki/TensorFlow pod Windows nativně nebeží (ano, dá se to rozchodit, ale je to dost opruz).

I pro big data je Windows minoritní platforma, i když tady se musí Microsoftu nechat, že se snaží, Hadoop jde provozovat i v Azure :).
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 18. 08. 2016, 11:34:28
Nabídky na Windows jsou také jen na administraci, v tom rozdíl nevidím.

Pokud zrovna nevyvíjím v C#, tak je vcelku jedno, který OS použiji, ne? Například pro vývoj v PHP mi linuxové systémy připadají praktičtější.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: balki 18. 08. 2016, 11:35:00
Citace
Tak záleží na tom, co chceš dělat. Pokud tě baví aplikace typu informační/účetní systém 100x jinak, tak se o ostatní platformy nezajímej, vystačíš si s C# a Windows. Kdybys chtěl dělat něco zajímavějšího, jako třeba big data, machine learning, AI, hry (ne PS4 opravdu není Windows), velké server backendy..., tak se s C# ani Windows vůbec nechytáš.

nemas pravdu, co se tyce her. herni studio neni odkazano jenom na linux. pouziva ruzne OS (OSx, Windows, Linux). AI a big data muzes delat taky na windowsu.
Proc si vsichni mysli, ze se na windowsu delaji jenom IS nebo ucetni systemy? To jsou ti lidi tak obmezeni? Nejlepsi, kdyz do toho keca linux administrator :D

Ja sa do windows nevyznam, ale problem je ten, ze zakaznici su konzervativni a chcu UNIX (Solaris, AIX, HP-UX), ti co su menej konzervativni, tak prechadzaju na linux. Pri tychto veciach byva dlhodoba podpora.

Zatial by som povedal, ze je to zvyk, lebo microsoft sa v poslednom case usiluje. Uvidime, mozno prijde cas, kedy bude migracia na nove windows zriedkava,  rutinna a nudna zalezitost.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: BoneFlute 18. 08. 2016, 12:14:27
Citace
Tak já ti mohu jen popřát, ať ti to nadšení vydrží. Ostatně proč ne.
Jo, takze na linuxu, kterej jsem vyzkousel, by bylo me nadseni obrovsky a nechtel bych nic jinyho. :D Proc bych se mal jako zajimat o platformu, ktera je beztak mrtva a nabidky na linux jsou beztak jenom sami administratori?
To chápeš špatně. Mě je celkem jedno co tě baví. A tvé názory si sice vyslechnu, ale to je tak zatím asi všechno.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: BoneFlute 18. 08. 2016, 12:21:34
Citace
Kdybych měl euro za každé takové sebejisté prohlášení, tak jsem Elon Musc.
Chtel bys to snad poprit? Nestojim o to srat se s instalovanim a rozchozenim Qt, kdyz muzu pouzit lepsi nastroj a primo pro to urceny. Samozrejme, kdyz delam pro windows.
Tak to je zásadní rozdíl že jo. A ještě zásadnější je v tom, že nepracuješ v mém týmu. Když by ano, tak bych očekával určitou kvalitu výsledku. Na čem to vytvoříš by mě nezajímalo. A tvé názory by museli být zhodnotitelné. Nestačí jen něco plácnout. Musíš si za tím stát. Svou výplatou samozřejmě.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 18. 08. 2016, 15:12:29
Ano, webovky - intranet, informační systémy, evidence

Mohl byste mi prosím napsat na bordel007(na)centrum(v)cz? Děkuji.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 18. 08. 2016, 15:29:25
C# špatný není, na desktopové aplikace pro Windows asi nejlepší. Dokonce v něm někteří programují i objektově.

V C# jsem dělal 3 roky, je to víceméně to samé jak Java. Rovnou si přihřeju polívku - vedle Smalltalku je to ubožáček - typový systém při složitějších strukturách je na posrání (přetypovávání a překrývání metod pouze z důvodu typu do naprostého vyčerpání), deklarativní třídy způsobující chybějící polymorfismus na třídní straně, podtypový polymorfismus, slabá reflexivita, chybně implementované zapouzdření (instance stejné třídy do sebe vidí!!!), KURRRRREVSKY nabujelá syntaxe, moloch, vynucené volání primitivního konstruktoru, málo pozdní vazba (neumí doesNotUnderstand), ...

K původní otázce: C# pro pochopení(!) OOP ne, jsou lepší.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 18. 08. 2016, 15:37:45
C# špatný není, na desktopové aplikace pro Windows asi nejlepší. Dokonce v něm někteří programují i objektově.

V C# jsem dělal 3 roky, je to víceméně to samé jak Java. Rovnou si přihřeju polívku - vedle Smalltalku je to ubožáček - typový systém při složitějších strukturách je na posrání (přetypovávání a překrývání metod pouze z důvodu typu do naprostého vyčerpání), deklarativní třídy způsobující chybějící polymorfismus na třídní straně, podtypový polymorfismus, slabá reflexivita, chybně implementované zapouzdření (instance stejné třídy do sebe vidí!!!), KURRRRREVSKY nabujelá syntaxe, moloch, vynucené volání primitivního konstruktoru, málo pozdní vazba (neumí doesNotUnderstand), ...

K původní otázce: C# pro pochopení(!) OOP ne, jsou lepší.

Nemáš pocit, že uživatelé Windows si nic lepšího než C# prostě nezaslouží? Přejme jim ho! Dobře jim tak!
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zmija 18. 08. 2016, 15:39:47
radsi delat v necem poradnem, nez v neporadnem jako Qt ;) vim, zazil jsem. ne dekuji, neprosim.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: ivan_bb 18. 08. 2016, 16:22:49
zmija:
ani ich nepocuvaj. tu sa to hemzi linuxakmi. co cakas na linuxovom fore? Ked si pozries, tak vacsina z nich travi cas na roote a to je asi tak vsetko. Tlacia ti kaleraby do hlavy, ake je kde OOP, alebo zas na inom vlakne tlacia ine kaleraby. Root nemozes povazovat za seriozne diskusne forum, pretoze tu nechodia seriozni ludia. Teoretizuju tu o vesmire, o Smalltalku a OOP v nom, pritom hovno im je to platne, nikto s tym nerobi, pracu s tym zozenies tazko a zit treba z niecoho. Tu davaju ludia rady, ze za par supov nevstanu z postele, pritom sa tvaria, aki su majstri sveta. Na poriadnu diskusiu si najdi ine forum, najlepsie nejake zahranicne, kde vedia diskutovat. A hlavne tu nehladaj rady. Drviva vacsina su tu administratori, ktori o programovani vedia velke prt, cest tym par vynimkam, ale aj tak su tu linuxaci a taki si budu vzdy robit srandu z dovodu ich obmedzenia.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Inkvizitor 18. 08. 2016, 16:54:57
zmija:
ani ich nepocuvaj. tu sa to hemzi linuxakmi. co cakas na linuxovom fore? Ked si pozries, tak vacsina z nich travi cas na roote a to je asi tak vsetko. Tlacia ti kaleraby do hlavy, ake je kde OOP, alebo zas na inom vlakne tlacia ine kaleraby. Root nemozes povazovat za seriozne diskusne forum, pretoze tu nechodia seriozni ludia. Teoretizuju tu o vesmire, o Smalltalku a OOP v nom, pritom hovno im je to platne, nikto s tym nerobi, pracu s tym zozenies tazko a zit treba z niecoho. Tu davaju ludia rady, ze za par supov nevstanu z postele, pritom sa tvaria, aki su majstri sveta. Na poriadnu diskusiu si najdi ine forum, najlepsie nejake zahranicne, kde vedia diskutovat. A hlavne tu nehladaj rady. Drviva vacsina su tu administratori, ktori o programovani vedia velke prt, cest tym par vynimkam, ale aj tak su tu linuxaci a taki si budu vzdy robit srandu z dovodu ich obmedzenia.

Laelovo hloupejsi slovenske dvojce?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: hawran diskuse 18. 08. 2016, 17:31:17
zmija:
ani ich nepocuvaj. tu sa to hemzi linuxakmi. co cakas na linuxovom fore? Ked si pozries, tak vacsina z nich travi cas na roote a to je asi tak vsetko. Tlacia ti kaleraby do hlavy, ake je kde OOP, alebo zas na inom vlakne tlacia ine kaleraby. Root nemozes povazovat za seriozne diskusne forum, pretoze tu nechodia seriozni ludia. Teoretizuju tu o vesmire, o Smalltalku a OOP v nom, pritom hovno im je to platne, nikto s tym nerobi, pracu s tym zozenies tazko a zit treba z niecoho. Tu davaju ludia rady, ze za par supov nevstanu z postele, pritom sa tvaria, aki su majstri sveta. Na poriadnu diskusiu si najdi ine forum, najlepsie nejake zahranicne, kde vedia diskutovat. A hlavne tu nehladaj rady. Drviva vacsina su tu administratori, ktori o programovani vedia velke prt, cest tym par vynimkam, ale aj tak su tu linuxaci a taki si budu vzdy robit srandu z dovodu ich obmedzenia.

Joj!
 ;D  ;D  ;D  ;D
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Aminuxik 18. 08. 2016, 18:16:17
Ivan_bb -  a ty gde ses tu najednou vyskyt? Nejlepší je, gdyž radí něgdo, gdo do teď trtkal medvědy v Tatrách, tahal kozy za cecky a najednou se zjeví tady.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 18. 08. 2016, 18:29:20
C# špatný není, na desktopové aplikace pro Windows asi nejlepší. Dokonce v něm někteří programují i objektově.

V C# jsem dělal 3 roky, je to víceméně to samé jak Java. Rovnou si přihřeju polívku - vedle Smalltalku je to ubožáček - typový systém při složitějších strukturách je na posrání (přetypovávání a překrývání metod pouze z důvodu typu do naprostého vyčerpání), deklarativní třídy způsobující chybějící polymorfismus na třídní straně, podtypový polymorfismus, slabá reflexivita, chybně implementované zapouzdření (instance stejné třídy do sebe vidí!!!), KURRRRREVSKY nabujelá syntaxe, moloch, vynucené volání primitivního konstruktoru, málo pozdní vazba (neumí doesNotUnderstand), ...

K původní otázce: C# pro pochopení(!) OOP ne, jsou lepší.
C# umí doesNotUnderstand
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Honza 18. 08. 2016, 21:20:33
C# umí doesNotUnderstand
to umí ale pouze podtřídy DynamicObject, a to ještě až od verze 4, nelze to použít u libovolného objektu
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: ivan_bb 18. 08. 2016, 21:38:41
Ach presne. Samy mudrlant a pritom skutek utek. Odbornici na vsetko, kazdy tu zaraba 100+kilo. Hovorim, diskusie na roote su na smiech. Clovek sa spyta na nieco a ono sa to zvrtne na debatu o vesmire. Strata casu.

PS: Dufam, ze tie vase prevratne programy napisane na linuxe v smalltalku a inych "tiptop" jazykoch, vyuzivaju minimalne miliony ludi. Skoda, ze to nie je ani pravda  8)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: balki 18. 08. 2016, 21:40:44
zmija:
ani ich nepocuvaj. tu sa to hemzi linuxakmi. co cakas na linuxovom fore? Ked si pozries, tak vacsina z nich travi cas na roote a to je asi tak vsetko. Tlacia ti kaleraby do hlavy, ake je kde OOP, alebo zas na inom vlakne tlacia ine kaleraby. Root nemozes povazovat za seriozne diskusne forum, pretoze tu nechodia seriozni ludia. Teoretizuju tu o vesmire, o Smalltalku a OOP v nom, pritom hovno im je to platne, nikto s tym nerobi, pracu s tym zozenies tazko a zit treba z niecoho. Tu davaju ludia rady, ze za par supov nevstanu z postele, pritom sa tvaria, aki su majstri sveta. Na poriadnu diskusiu si najdi ine forum, najlepsie nejake zahranicne, kde vedia diskutovat. A hlavne tu nehladaj rady. Drviva vacsina su tu administratori, ktori o programovani vedia velke prt, cest tym par vynimkam, ale aj tak su tu linuxaci a taki si budu vzdy robit srandu z dovodu ich obmedzenia.

Laelovo hloupejsi slovenske dvojce?

Ja sicem kodim v jave (java developer som), cielovy os linux/solaris, ale chcel by som zalozit swift uderku. Swift je jazyk zajtrajska.  Od najlepsieho vyrobcu najlepsich pocitacov apple. Dokonca, najvacsieho vyrobcu osobnych pocitacov! Swift bezi len na apploch, a je to dostatocne exoticky, aby som mohol hrat urazeneho trolla na vacsine for. Uz som v tom napisal aj hello world. (Medzi nami, je to okopirovany python)

Inak tento topic bol k veci len prve dve strany. 
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Mirek Prýmek 18. 08. 2016, 21:59:05
AI a big data muzes delat taky na windowsu.
A kdo to dělá? (jen tvrdá data prosím)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gl 18. 08. 2016, 22:13:43
AI a big data muzes delat taky na windowsu.
A kdo to dělá? (jen tvrdá data prosím)

GoodAI
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: neznamej 18. 08. 2016, 22:41:42
AI a big data muzes delat taky na windowsu.
A kdo to dělá? (jen tvrdá data prosím)
treba Hortonworks, iTrend?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: balki 18. 08. 2016, 23:16:36
AI a big data muzes delat taky na windowsu.
A kdo to dělá? (jen tvrdá data prosím)
treba Hortonworks, iTrend?

Co konkrerne? Lebo Hornotworks robia hadoop a ten bezi na jave a zvycajne byva hostovany na linuxe kvoli cene.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: neznamej 19. 08. 2016, 07:16:56
MS ma s nima podpisane partnerstvi, tak ja dal fakty, ktere chtel Mirek.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gamer 19. 08. 2016, 07:31:38
MS nemá nic vlastního, co by mohlo konkurovat Hadoopu, a protože zákazníci Microsoftu zřejmě Hadoop chtějí, najal si Microsoft externí firmu, která Hadoop rozchodí v jejich Azure. Z obchodního hlediska logický krok, z technologického hlediska tak trochu prohra, Microsoft nabízí cizí řešení, protože vlastní konkurenceschopné nemá.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: neznamej 19. 08. 2016, 07:51:01
no vzdyt to je v pohode, ne? kde je napsany, ze MS musi mit vlastni reseni? spolupracuji s externi firmou. a prohra to neni, neda se byt nejlepsi ve vsem a taky to ani nejde. MS je hlavne top firma co se tyce Office produktu, cloudu a desktopu. kazdopadne to potvrzuji i vyrocni spravy.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: balki 19. 08. 2016, 08:44:48
no vzdyt to je v pohode, ne? kde je napsany, ze MS musi mit vlastni reseni? spolupracuji s externi firmou. a prohra to neni, neda se byt nejlepsi ve vsem a taky to ani nejde. MS je hlavne top firma co se tyce Office produktu, cloudu a desktopu. kazdopadne to potvrzuji i vyrocni spravy.
Idem okolo, microsoft uz kupil amazon a apple?
To su mi veci.

Microsoft ma instalacky, hadoopu. Ci to niekto pouziva, je ina vec.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 19. 08. 2016, 08:50:10
C# umí doesNotUnderstand

??? Jak?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Mirek Prýmek 19. 08. 2016, 09:41:23
GoodAI
Ok, takže to bysme měli jeden dva roky starý startup o nějakých 15 lidech :)

Když jsem psal "tvrdá data prosím", tak jsem tím chtěl říct "máme nějaká tvrdá data o tom, kolik procent firem běží Hadoop, Spark, DataFlow, Flink, etc. etc. na Windowsech?" Osobně totiž moc nechápu, proč by to někdo měl dělat. Proč provozovat ten samý soft na platformě, na které není primárně vyvíjen, a ještě platit navíc licenční poplatky? Umím si představit, že v nějaké hodně MS-zadrátované firmě to může za velmi specifických podmínek dávat smysl kvůli integraci, ale pro drtivou většinu případů mi to přijde jako holý nesmysl.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gl 19. 08. 2016, 14:30:33
GoodAI
Ok, takže to bysme měli jeden dva roky starý startup o nějakých 15 lidech :)

Když jsem psal "tvrdá data prosím", tak jsem tím chtěl říct "máme nějaká tvrdá data o tom, kolik procent firem běží Hadoop, Spark, DataFlow, Flink, etc. etc. na Windowsech?" Osobně totiž moc nechápu, proč by to někdo měl dělat. Proč provozovat ten samý soft na platformě, na které není primárně vyvíjen, a ještě platit navíc licenční poplatky? Umím si představit, že v nějaké hodně MS-zadrátované firmě to může za velmi specifických podmínek dávat smysl kvůli integraci, ale pro drtivou většinu případů mi to přijde jako holý nesmysl.

Souhlasím. Oni to používají asi proto, že s tím mají zkušenosti jako vývovojáři her pro windows.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 22. 08. 2016, 02:38:43
C# umí doesNotUnderstand

??? Jak?
Přes dynamic. Funguje to podobně jako v ObjC. Ne že bych to někdy potřeboval, ale od určité verze (tuším 4) co C# umí. Stejně jako Java už dávno, i když ne od první verze.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 22. 08. 2016, 09:22:58
Pošlete mi prosím odkaz na nějaké povídání, odkazů na dynamic je mraky, ale o chytání runtimeové chyby nic nevidím. Děkuji.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 22. 08. 2016, 11:43:17
Pošlete mi prosím odkaz na nějaké povídání, odkazů na dynamic je mraky, ale o chytání runtimeové chyby nic nevidím. Děkuji.
Co má doesNotUnderstand společného s chybami?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Mirek Prýmek 22. 08. 2016, 13:47:26
Co má doesNotUnderstand společného s chybami?
SB si to asi představuje tak, že volání neexistující metody způsobí výjimku, pro kterou existuje nějaký handler...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 22. 08. 2016, 14:46:31
Co má doesNotUnderstand společného s chybami?
SB si to asi představuje tak, že volání neexistující metody způsobí výjimku, pro kterou existuje nějaký handler...
To je dost velká divnost. doesNotUnderstand (a to samé v bledě modrém v Javě nebo C#) je vhodné tak pro nějakou proxy, jinak tu už nějaký ten pátek máme statické typování :) Každopádně dík za upřesnění, evidentně jsem nepochopil jeho myšlenkový pochod...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Mirek Prýmek 22. 08. 2016, 15:26:49
doesNotUnderstand (a to samé v bledě modrém v Javě nebo C#) je vhodné tak pro nějakou proxy
Ještě je k němu komplementární respondsToSelector, se kterým dohromady už se hodí třeba i ke skládání neznámých objektů, což je příjemná věc. Samotný respondsToSelector se pak ještě může hodit k "implementaci rozhraní naruby" - postupně zkouším, jestli neznámý objekt umí třeba renderToPDF, když ne, tak renderToPNG apod.

Nejsou to asi zas tak moc používané metody, ale pokud je nemáš, tak některé věci neuděláš vůbec, nebo jenom hrozně hnusně. Čili jazyk, který si chce říkat OO, je rozhodně mít musí, jinak to žádné OOP není, ať si na školách říká kdo chce co chce ;)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 22. 08. 2016, 15:35:42
doesNotUnderstand (a to samé v bledě modrém v Javě nebo C#) je vhodné tak pro nějakou proxy
Ještě je k němu komplementární respondsToSelector, se kterým dohromady už se hodí třeba i ke skládání neznámých objektů, což je příjemná věc. Samotný respondsToSelector se pak ještě může hodit k "implementaci rozhraní naruby" - postupně zkouším, jestli neznámý objekt umí třeba renderToPDF, když ne, tak renderToPNG apod.

Nejsou to asi zas tak moc používané metody, ale pokud je nemáš, tak některé věci neuděláš vůbec, nebo jenom hrozně hnusně. Čili jazyk, který si chce říkat OO, je rozhodně mít musí, jinak to žádné OOP není, ať si na školách říká kdo chce co chce ;)
Však mi taky v Go a Swiftu chybí (a v C++ taky, ale tam je člověk ani nijak neočekává).
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: noef 22. 08. 2016, 17:04:47
nemas pravdu, co se tyce her. herni studio neni odkazano jenom na linux. pouziva ruzne OS (OSx, Windows, Linux). AI a big data muzes delat taky na windowsu.

Herní studio, pokud chce přežít, tak nesmí vyvíjet primárně pro Windows, tam se prodá minimum her. 90% prodejů dělají konzole, PC je jen 10%. V konzolích momentálně PS4 docela válcuje XBOX One, takže Windows je minoritní platforma. Co se týká mobilních her, má smysl uvažovat jen o Androidu a iPhone, Windows jsou úplně mimo.

Jako nejsu z toho uplne moudrej, ale pokud tech 37% opravdu patri k PC, tak je vysledny pomer 37% vs. 27% ~ PC ma 58% vs konzole s 42%, coz se tomu 90% vs 10% ani neblizi.
(http://i.imgur.com/WOkm6fW.png)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Mirek Prýmek 22. 08. 2016, 17:37:47
Však mi taky v Go a Swiftu chybí (a v C++ taky, ale tam je člověk ani nijak neočekává).
V Go bych ho ani nečekal, vzhledem k tomu, jak je to drahá operace a jak je Go zaměřené na výkon. U Swiftu je to teda docela zklamání, to jsem nevěděl (Swift jsem zkoukl jenom z rychlíku). Aspoň teda co koukám, jde použít, pokud se dědí z NSObject. Tak aspoň něco. Ale je to teda hodně nesystémový, to nemám rád, tyhle výjimky.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 22. 08. 2016, 17:53:50
Však mi taky v Go a Swiftu chybí (a v C++ taky, ale tam je člověk ani nijak neočekává).
V Go bych ho ani nečekal, vzhledem k tomu, jak je to drahá operace a jak je Go zaměřené na výkon. U Swiftu je to teda docela zklamání, to jsem nevěděl (Swift jsem zkoukl jenom z rychlíku). Aspoň teda co koukám, jde použít, pokud se dědí z NSObject. Tak aspoň něco. Ale je to teda hodně nesystémový, to nemám rád, tyhle výjimky.
Typicky se to používá pro implementaci distribuovaných objektů (dynamická proxy), řekl bych, že vzhledem k latenci při komunikaci přes síť ta operace vůbec drahá není. Swift to nemá a dědit z NSObject se dá jen na OS X, na Linuxu ne, takže to je celkem no go (má-li být kód multiplatformní). Celkově bych řekl, že v tomto případě je nejlepší vykašlat se na eleganci a klidně to dělat jako Go - přes textové rozhraní.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 22. 08. 2016, 18:02:39
To je dost velká divnost. doesNotUnderstand (a to samé v bledě modrém v Javě nebo C#) je vhodné tak pro nějakou proxy, jinak tu už nějaký ten pátek máme statické typování :) ...

Co s tím má společné statické typování?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 22. 08. 2016, 18:10:28
Co má doesNotUnderstand společného s chybami?

Asi se mi ztratil příspěvek, takže znovu...

Nedohledání metody v objektu řeší virtuální počítač zavoláním jiné metody (nemusíme tomu říkat běhová chyba, je to šumák).
Neřešte to, prostě mi pošlete odkaz s popisem, jak to v C# funguje. Děkuji.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 22. 08. 2016, 18:10:48
To je dost velká divnost. doesNotUnderstand (a to samé v bledě modrém v Javě nebo C#) je vhodné tak pro nějakou proxy, jinak tu už nějaký ten pátek máme statické typování :) ...

Co s tím má společné statické typování?
Hodně, protože zamezí zbytečným stupidním chybám za běhu.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Mirek Prýmek 22. 08. 2016, 19:36:04
dědit z NSObject se dá jen na OS X, na Linuxu ne,
Aha, já jsem myslel, že pro Swift na Linuxu používají nějaký GNUStep nebo něco takovýho. Tak to je špatný, no.

Neřešte to, prostě mi pošlete odkaz s popisem, jak to v C# funguje. Děkuji.
http://blog.root.cz/babel/nerozumim/
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 22. 08. 2016, 20:30:23
dědit z NSObject se dá jen na OS X, na Linuxu ne,
Aha, já jsem myslel, že pro Swift na Linuxu používají nějaký GNUStep nebo něco takovýho. Tak to je špatný, no.

Na Linuxu je čistý Swift bez ObjC, není tam ani libobjc a Foundation přepsali do Swiftu. Celou tu šaškárnu s ObjC Apple spáchal jen kvůli použití svého veleúžasného nového jazyka na OS X a iOS. Upřímně, nijak mi na Linuxu ObjC nechybí, měl  jsem tam s ním tu čest, žádné zváštní problémy tam nebyly, ale rozchodit ho je dost pracné a ve srovnání se Swiftem nic nového/lepšího nepřináší.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: BoneFlute 24. 08. 2016, 14:01:41
To je dost velká divnost. doesNotUnderstand (a to samé v bledě modrém v Javě nebo C#) je vhodné tak pro nějakou proxy, jinak tu už nějaký ten pátek máme statické typování :) ...

Co s tím má společné statické typování?
Hodně, protože zamezí zbytečným stupidním chybám za běhu.
Navzdory tomu, že jsem zapřisáhlý příznivec statického typování - OOP se statickým typováním nesouvisí. A sice si myslím, že je Python díky absenci typován špatný jazyk, ale je to jen otázka volby. Nelze jen tak prohlásit, že díky tomu, že máme jazyky se statickým typováním, tak že všechno ostatní nemůže chtít nikdo používat.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 24. 08. 2016, 14:11:36
To je dost velká divnost. doesNotUnderstand (a to samé v bledě modrém v Javě nebo C#) je vhodné tak pro nějakou proxy, jinak tu už nějaký ten pátek máme statické typování :) ...

Co s tím má společné statické typování?
Hodně, protože zamezí zbytečným stupidním chybám za běhu.
Navzdory tomu, že jsem zapřisáhlý příznivec statického typování - OOP se statickým typováním nesouvisí. A sice si myslím, že je Python díky absenci typován špatný jazyk, ale je to jen otázka volby. Nelze jen tak prohlásit, že díky tomu, že máme jazyky se statickým typováním, tak že všechno ostatní nemůže chtít nikdo používat.
To je ale hodně mimo téma. Diskuse byla o doesNotUnderstand, které mají i některé statické jazyky (Java) a závěr byl, že statické typování je rozumné používat všude, kde to je možné. V případě nutnosti se pak sáhne k zachycení volání a přesměrování, v C# pomocí dynamic, od čehož se tato diskuse rozvinula.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: BoneFlute 24. 08. 2016, 14:57:36
To je dost velká divnost. doesNotUnderstand (a to samé v bledě modrém v Javě nebo C#) je vhodné tak pro nějakou proxy, jinak tu už nějaký ten pátek máme statické typování :) ...

Co s tím má společné statické typování?
Hodně, protože zamezí zbytečným stupidním chybám za běhu.
Navzdory tomu, že jsem zapřisáhlý příznivec statického typování - OOP se statickým typováním nesouvisí. A sice si myslím, že je Python díky absenci typován špatný jazyk, ale je to jen otázka volby. Nelze jen tak prohlásit, že díky tomu, že máme jazyky se statickým typováním, tak že všechno ostatní nemůže chtít nikdo používat.
To je ale hodně mimo téma. Diskuse byla o doesNotUnderstand, které mají i některé statické jazyky (Java) a závěr byl, že statické typování je rozumné používat všude, kde to je možné. V případě nutnosti se pak sáhne k zachycení volání a přesměrování, v C# pomocí dynamic, od čehož se tato diskuse rozvinula.
Tak si možná jen nerozumíme.

doesNotUnderstand je důležitá až zásadní vlastnost OOP. Statické typování OOP nepotřebuje (i když v praxi je to mnohem důležitější pattern). A vzhledem k subjektu vlákna...

Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 24. 08. 2016, 15:31:47
To je dost velká divnost. doesNotUnderstand (a to samé v bledě modrém v Javě nebo C#) je vhodné tak pro nějakou proxy, jinak tu už nějaký ten pátek máme statické typování :) ...

Co s tím má společné statické typování?
Hodně, protože zamezí zbytečným stupidním chybám za běhu.
Navzdory tomu, že jsem zapřisáhlý příznivec statického typování - OOP se statickým typováním nesouvisí. A sice si myslím, že je Python díky absenci typován špatný jazyk, ale je to jen otázka volby. Nelze jen tak prohlásit, že díky tomu, že máme jazyky se statickým typováním, tak že všechno ostatní nemůže chtít nikdo používat.
To je ale hodně mimo téma. Diskuse byla o doesNotUnderstand, které mají i některé statické jazyky (Java) a závěr byl, že statické typování je rozumné používat všude, kde to je možné. V případě nutnosti se pak sáhne k zachycení volání a přesměrování, v C# pomocí dynamic, od čehož se tato diskuse rozvinula.
Tak si možná jen nerozumíme.

doesNotUnderstand je důležitá až zásadní vlastnost OOP. Statické typování OOP nepotřebuje (i když v praxi je to mnohem důležitější pattern). A vzhledem k subjektu vlákna...
Myslím, že se celkem shodujeme. Mně osobně doesNotUnderstand dost chybí v jazycích, které ho nemají. Na druhou stranu statické typování vidím jako užitečnou pomůcku zamezující chybám už při kompilaci.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: jpu 31. 03. 2017, 14:52:33
Co si myslite o vyrokoch tychto ludi na adresu OOP?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 31. 03. 2017, 15:36:18
Co si myslite o vyrokoch tychto ludi na adresu OOP?

Myslím si, že (na rozdíl od nekrofilů) přemýšlí a diskutují.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 31. 03. 2017, 15:46:05
Co si myslite o vyrokoch tychto ludi na adresu OOP?

Můj názor je:
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: noef 31. 03. 2017, 15:54:08
Pokud jste nevideli ta videa od Kaye (otec "praveho" OOP) postovana v jinem topicu, tak urcite doporucuju.
Treba tohle Is it really "Complex"? Or did we just make it "Complicated"? (https://www.youtube.com/watch?v=ubaX1Smg6pY)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 31. 03. 2017, 16:06:35
Pravého :D Otec bude, ale nikdo to moc nepoužívá a tuším, že bude nějaký důvod...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: phi 31. 03. 2017, 17:03:42
Co si myslite o vyrokoch tychto ludi na adresu OOP?
ja mam tyhle diskuse rad, je tu spousta balastu, pravd, polopravd i nesmyslu, ale vetsinou je to pomerne inspirativni - clovek se tak zamysli co by si mel precist nebo proc je tohle tvrzeni vlastne blbost nebo naopak perla hozena do prasecaku.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 31. 03. 2017, 17:14:07
Pokud jste nevideli ta videa od Kaye (otec "praveho" OOP) postovana v jinem topicu, tak urcite doporucuju.
Treba tohle Is it really "Complex"? Or did we just make it "Complicated"? (https://www.youtube.com/watch?v=ubaX1Smg6pY)

Nic tak nudného a o ničem jsem dlouho neviděl. Se pak nedivím, proč to nikdo nepoužívá :D O co tam teda šlo? Jsem to musel za půlkou vypnout, protože to bylo k ničemu.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: jpu 31. 03. 2017, 17:41:18
Kurna, teraz som si uvedomil, ked to tak citam, ze som zabudol pridat link. Zaujimal ma nazor na vyjadrenia tych ludi ohladom OOP
http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html (http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 31. 03. 2017, 17:46:36
Většinou nesmysly od lidí, kteří asi neumí moc programovat. Nebral bych je vážně. Co tedy považují za tu luxusní alternativu? Nic? Aha...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 31. 03. 2017, 18:22:44
Ale budu rád, pokud někdo k tomu bude něco mít. S OOP problémy nemám a nevím, co by jako ostatní chtěli. Asi fakt jen neumí vyvíjet :D
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: No name 31. 03. 2017, 19:23:39
Pokud jste nevideli ta videa od Kaye (otec "praveho" OOP) postovana v jinem topicu, tak urcite doporucuju.
Treba tohle Is it really "Complex"? Or did we just make it "Complicated"? (https://www.youtube.com/watch?v=ubaX1Smg6pY)

Nic tak nudného a o ničem jsem dlouho neviděl. Se pak nedivím, proč to nikdo nepoužívá :D O co tam teda šlo? Jsem to musel za půlkou vypnout, protože to bylo k ničemu.

Obávám se, že tvé IQ nepostačuje na to, abys to pochopil.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 31. 03. 2017, 19:29:09
Jasně, proto mluví tak pomalu :D OMG, ten chlápek bude pěkně k ničemu a kdo ví, jestli jako mladší byl lepší. Asi těžko.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ondra Satai Nekola 31. 03. 2017, 19:50:10
Jasně, proto mluví tak pomalu :D OMG, ten chlápek bude pěkně k ničemu a kdo ví, jestli jako mladší byl lepší. Asi těžko.

Očividně nebyl anonymní nula, jako ty...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 31. 03. 2017, 19:52:52
Tak prosazovat nesmysly a být s tím slavný asi není úplně můj styl. Jen mě překvapilo, že ho někdo může brát vážně.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Polymath 31. 03. 2017, 20:05:20
Kurna, teraz som si uvedomil, ked to tak citam, ze som zabudol pridat link. Zaujimal ma nazor na vyjadrenia tych ludi ohladom OOP
http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html (http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html)
Chybí tam "OOD is the Roman numerals of computing" (taky Pike). Jinak OOP působí akademičtěji, ale často je samoúčelné. Smysl dává chovat se pragmaticky a používat to nejjednodušší, co stačí na vyřešení problému. Na mnoho věcí je OOP overkill a když si vybavím typický kód pro ASP nebo PHP, tak nevím, kam by se OOP naroubovalo.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: No name 31. 03. 2017, 20:14:31
Tak prosazovat nesmysly a být s tím slavný asi není úplně můj styl. Jen mě překvapilo, že ho někdo může brát vážně.

A čemupak jsi vlastně nerozuměl? Hm?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 31. 03. 2017, 21:19:38
Kurna, teraz som si uvedomil, ked to tak citam, ze som zabudol pridat link. Zaujimal ma nazor na vyjadrenia tych ludi ohladom OOP
http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html (http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html)
Chybí tam "OOD is the Roman numerals of computing" (taky Pike). Jinak OOP působí akademičtěji, ale často je samoúčelné. Smysl dává chovat se pragmaticky a používat to nejjednodušší, co stačí na vyřešení problému. Na mnoho věcí je OOP overkill a když si vybavím typický kód pro ASP nebo PHP, tak nevím, kam by se OOP naroubovalo.

Oni obvykle píšou, že na větší věci se to nehodí, což nechápu. Na menší je to opravdu zbytečné, protože většinu času budu řešit architekturu, která je tam nepodstatná. Tak jak to je?

Tak prosazovat nesmysly a být s tím slavný asi není úplně můj styl. Jen mě překvapilo, že ho někdo může brát vážně.

A čemupak jsi vlastně nerozuměl? Hm?

Pokud po hodině neřekne nic zajímavého, tak má prostě smůlu. Můj čas je drahý a někdo takhle strašně pomalý nemůže nic moc umět.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: jpu 31. 03. 2017, 21:59:34
ty nula, ten clovek je ovela vyznamnejsi a vazeny v IT svete. Teba si nevazi ani nikto, dokonca ani to, co rano vyprodukujes na wc a je to rado, ze ta to opusti.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 31. 03. 2017, 22:13:23
To jen ukazuje, jak je IT svět zdegenerovaný. Se pak nedivim, že lopaty dnes berou 80 tisíc a ještě jsou za to rády. Ony to berou, že je to jako takový lepší dělník.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Polymath 31. 03. 2017, 22:29:01
Pokud jste nevideli ta videa od Kaye (otec "praveho" OOP) postovana v jinem topicu, tak urcite doporucuju.
Treba tohle Is it really "Complex"? Or did we just make it "Complicated"? (https://www.youtube.com/watch?v=ubaX1Smg6pY)
Pravé OOP se definitivně odebralo na krchov IT dějin spolu s ObjC.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 31. 03. 2017, 22:30:38
Přesně tak, nebyl to dobrý koncept. Zkusil to a nevyšlo to.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 31. 03. 2017, 22:43:17
Kurna, teraz som si uvedomil, ked to tak citam, ze som zabudol pridat link. Zaujimal ma nazor na vyjadrenia tych ludi ohladom OOP
http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html (http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html)

V podstatě tam píší, že objektové jazyky bývají systematicky zneužívány ke psaní procedurálního kódu a tedy nesplňují původní očekávání. Dědičnost se potlačuje ve prospěch kompozice, zapouzdření se systematicky porušuje a polymorfismus je pro spoustu programátorů jen cizím slovem. K tomu příšerný přístup k definicím rozhraní a máme tady procedurální kód zabalený do tříd, který se jen tváří, že je objektový.

Ti programátoři si vlastně jen stěžují, že principy OOP zůstaly většinou vývojářů nepochopeny.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Tuxik 01. 04. 2017, 06:15:52
Kurna, teraz som si uvedomil, ked to tak citam, ze som zabudol pridat link. Zaujimal ma nazor na vyjadrenia tych ludi ohladom OOP
http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html (http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html)

V podstatě tam píší, že objektové jazyky bývají systematicky zneužívány ke psaní procedurálního kódu a tedy nesplňují původní očekávání. Dědičnost se potlačuje ve prospěch kompozice, zapouzdření se systematicky porušuje a polymorfismus je pro spoustu programátorů jen cizím slovem. K tomu příšerný přístup k definicím rozhraní a máme tady procedurální kód zabalený do tříd, který se jen tváří, že je objektový.

Ti programátoři si vlastně jen stěžují, že principy OOP zůstaly většinou vývojářů nepochopeny.
A já to říkám pořád... OOP je především dobré pro práci s daty, v některých případech to dává smysl i jinde, ale pokud chce mít někdo jako objekt úplně všechno a tvoří v tom i lineární aplikace, nedává to smysl. Je to neefektivní a kód to zesložiťuje.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: noef 01. 04. 2017, 07:06:57
Chapu, ze ten Kay muze byt pro nekoho pomalejsi, ale veci, o kterych mluvi jsou rozhodne zajimave. Mel i nejakou prednasku pro netrpelive studenty, tak mozna ta se vam bude libit vice - byla o neco kratsi a hral si tam s auticky ;).

Treba toto:
(http://i.imgur.com/XFxrae4.png)

Cervene kolecko je Java, C#, PHP (ok, to je mozna trochu vyse) atd. Znazornuje to, jak "zaostale" se vyviji bezne komercni projekty. Firmy nejsou schopny dat par susnu (pro ne, realne tisice/miliony $) a radeji zustavaji u toho "co je zajete a nejak funguje" nez by se zkusili pousnout vice dal.

Nyni se posouvaji velice pomalu, napr. pronikani FP do mainstream jazyku. On mluvi o trochu agresivnejsim pohybu kupredu, ktery ale korporaty slysici pouze na "penize co nejdriv" maji problem videt (za par let, co tyto projekty casto zaberou, tam ani to vedeni, co by je zadalo, uz ani nebylo, takze proc je zadavat?).

Kdyz se podivam na Akka, prestoze to neni uplne to, co si on predstavuje (je to napul cesty), tak i presto dosahuje skvelych vysledku - kdyz se jednou clovek v tom nauci myslet a vyvijet, tak skalovani a odolnost je "zadarmo", je proste soucasti toho, jak se ma v Akka vyvijet a jak je Akka postavena. Zadne problemy a horory se zamky, vlakny, rucnim resenim toho, co delat kdyz padne par nodu atp.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 01. 04. 2017, 07:28:37
A já to říkám pořád... OOP je především dobré pro práci s daty, v některých případech to dává smysl i jinde, ale pokud chce mít někdo jako objekt úplně všechno a tvoří v tom i lineární aplikace, nedává to smysl. Je to neefektivní a kód to zesložiťuje.

Mám opačnou zkušenost: OOP mi aplikace zkracuje a zefektivňuje. Hlavně mi zlepšuje přehled o tom, kde mám kterou část kódu. Když se mi změní zadání, tak většinou stačí vyměnit nějakou třídu za novou a jede se dál.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 01. 04. 2017, 08:49:03
Cervene kolecko je Java, C#, PHP (ok, to je mozna trochu vyse) atd. Znazornuje to, jak "zaostale" se vyviji bezne komercni projekty. Firmy nejsou schopny dat par susnu (pro ne, realne tisice/miliony $) a radeji zustavaji u toho "co je zajete a nejak funguje" nez by se zkusili pousnout vice dal.

Dík za info.

OK, vyvíjejí zaostale podle něj. A co je řešením? Podle mě Java zaostalá vůbec není a nevím, co jiného bych doporučil. Takže jak se chceš posunout? Co mně a těm firmám uniká a máme začít hned používat?

A já to říkám pořád... OOP je především dobré pro práci s daty, v některých případech to dává smysl i jinde, ale pokud chce mít někdo jako objekt úplně všechno a tvoří v tom i lineární aplikace, nedává to smysl. Je to neefektivní a kód to zesložiťuje.

Mám opačnou zkušenost: OOP mi aplikace zkracuje a zefektivňuje. Hlavně mi zlepšuje přehled o tom, kde mám kterou část kódu. Když se mi změní zadání, tak většinou stačí vyměnit nějakou třídu za novou a jede se dál.

Přesně tak, od toho OOP také je.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: noef 01. 04. 2017, 09:34:56
OK, vyvíjejí zaostale podle něj. A co je řešením? Podle mě Java zaostalá vůbec není a nevím, co jiného bych doporučil. Takže jak se chceš posunout? Co mně a těm firmám uniká a máme začít hned používat?

Jsem to psal v tom prispevku:

... Firmy nejsou schopny dat par susnu (pro ne, realne tisice/miliony $) a radeji zustavaji u toho "co je zajete a nejak funguje" nez by se zkusili pousnout vice dal.

Nyni se posouvaji velice pomalu, napr. pronikani FP do mainstream jazyku. On mluvi o trochu agresivnejsim pohybu kupredu, ktery ale korporaty slysici pouze na "penize co nejdriv" maji problem videt (za par let, co tyto projekty casto zaberou, tam ani to vedeni, co by je zadalo, uz ani nebylo, takze proc je zadavat?).

Zadny vselek, do ktereho korporaty nezainvestuji neni. Zadne instantni reseni pripravene na komercni vyvoj neni (ve Smalltalku se myslim obcas komercne vyviji, ale je to dost okrajove).

Java, prestoze ji take obcas pouzivam a JVM se mi libi, bohuzel zaostala ve srovnani s ostanimi jazyky zcela jiste je. Treba Scala je mnohem dale (ne, ani Java 8 s tezkopadnymi konstrukcemi se Scale neblizi). Podobne Haskell, ve kterem casto postaci par radek na vyjadreni ekvivaletniho algoritmu jako v Jave na desitky ci stovky. Ale ten zase nemuze Jave konkurovat toolingem, knihovnami atd., takze na obecne enterprise veci IMO neni vhodny. Nic z toho neni "prave OOP", jen je blize spodku grafu, tj. vyzaduje mene radek na vyreseni stejnych problemu (pomijim neexistujici/slabe knihovny). Jednoduse to ma lepsi abstrakce, nez treba ta Java, takze vyjadreni reseni je podstatne kratsi. On samozrejmne chce jako ten dalsi krok "prave OOP", ktere spravne pouzite muze podstatne zjednodusit reseni problemu a na extremni paralelismus, ktery je nyni aktualnim smerem v hw, je jako stvorene.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 01. 04. 2017, 14:17:47
Tak existuje něco? Pokud ne, tak nevím, co řešíme. Máš hromadu OSS, takže není třeba investovat. Nebo jak je to myšleno?

Jak je zaostalá? Jak může být Scala mnohem dále a v čem?

Haskell musí být vtip. To je sranda jazyk na hraní, ale Javě se to nemůže rovnat vůbec v ničem. Píšeš, že nástroje nejsou moc dobré. To i neschopný Python má lepší nástroje. Takže z hlediska nástrojů je to jazyk tak na domácí hraní. Z hlediska jazyka není zase dost dobře otestovaný v praxi a může mít hromadu problémů.

Spodek grafu evidentně nikoho nezajímá, protože síla Javy je v tom, že i bez komentářů se skvěle čte. Asi bych nerad měl cool konstrukce na dva řádky, které bych luštil půl hodiny.

Lepší abstrakce je cool na honění trika, ale evidentně to nikdo nechce.

On chce jeho OOP, které nechce nikdo jiný. Takže je otázkou, jestli má smysl řešit jeho názory, které jsou možná mimo a nebo brát reálná fakta.

Extrémní paralelismus možná sedí HW, ale tebe nikdy nezajímá HW, ale požadavky. Takže pokud pro to nemáš využití, stejně máš smůlu.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Polymath 01. 04. 2017, 14:31:15
OK, vyvíjejí zaostale podle něj. A co je řešením? Podle mě Java zaostalá vůbec není a nevím, co jiného bych doporučil. Takže jak se chceš posunout? Co mně a těm firmám uniká a máme začít hned používat?

Jsem to psal v tom prispevku:

... Firmy nejsou schopny dat par susnu (pro ne, realne tisice/miliony $) a radeji zustavaji u toho "co je zajete a nejak funguje" nez by se zkusili pousnout vice dal.

Nyni se posouvaji velice pomalu, napr. pronikani FP do mainstream jazyku. On mluvi o trochu agresivnejsim pohybu kupredu, ktery ale korporaty slysici pouze na "penize co nejdriv" maji problem videt (za par let, co tyto projekty casto zaberou, tam ani to vedeni, co by je zadalo, uz ani nebylo, takze proc je zadavat?).

Zadny vselek, do ktereho korporaty nezainvestuji neni. Zadne instantni reseni pripravene na komercni vyvoj neni (ve Smalltalku se myslim obcas komercne vyviji, ale je to dost okrajove).

Java, prestoze ji take obcas pouzivam a JVM se mi libi, bohuzel zaostala ve srovnani s ostanimi jazyky zcela jiste je. Treba Scala je mnohem dale (ne, ani Java 8 s tezkopadnymi konstrukcemi se Scale neblizi). Podobne Haskell, ve kterem casto postaci par radek na vyjadreni ekvivaletniho algoritmu jako v Jave na desitky ci stovky. Ale ten zase nemuze Jave konkurovat toolingem, knihovnami atd., takze na obecne enterprise veci IMO neni vhodny. Nic z toho neni "prave OOP", jen je blize spodku grafu, tj. vyzaduje mene radek na vyreseni stejnych problemu (pomijim neexistujici/slabe knihovny). Jednoduse to ma lepsi abstrakce, nez treba ta Java, takze vyjadreni reseni je podstatne kratsi. On samozrejmne chce jako ten dalsi krok "prave OOP", ktere spravne pouzite muze podstatne zjednodusit reseni problemu a na extremni paralelismus, ktery je nyni aktualnim smerem v hw, je jako stvorene.
Jenže pravé OOP tu už bylo. Trend je teď osekané OOP ve stylu Go (které je úspěšné ale spíše díky kvalitní implementaci, ne paradigmatu). Javu by zachránilo, kdyby z ní udělali něco jako C++/CLI v pure režimu, jinak zůstane stejně zaostalá jako dnes. Nicméně trend je takový, že na Javu Oracle s**e.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: noef 01. 04. 2017, 14:40:07
Pokud by Java nemela za sebou prachy, tak je taky na urovni toolingu ala Haskell. Java na me pusobi, jak ten jazyk pro lopaty, protoze i triviality se rozepisuji na nekolik radek jako pohadka, spoustu veci musi programator vysvetlovat na nekolikrat. Ani Scala v tomto ohledu neni dokonala, ale je na tom o dost lepe a taky se v ni daji delat a delaji komercni veci. Pokud chcete priklad, kam se ubirat, tak se podivejte na type inferenci v Haskellu, to je trosku jina liga - tam se totiz pisi typy pro programatora, prekladac je nema problem odvodit sam ;D.

Mam pocit, ze v tom videu rikal, co vsechno s trochou penez udelali - treba GUI a OOP. Ale v ramci OSS, kde na tom dela po vecerech par nadsencu nemuzes prijit treba s dobrym IDE pro Haskell na urovni IntelliJ pro Javu. Proste je to ted na mrtvem bode, jak pises sam: neni nic "lepsiho" (= stabilniho s dobrym toolingem, spoustou odladenych knihoven, komunitou atd) -> nebudeme nic lepsiho zkouset udelat (byt by to stalo pro korporaty drobaky) -> nic nedelame, tak nic "lepsiho" nemame.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 01. 04. 2017, 15:29:25
Trend OOP je pořád Java, jen zboj má vlastní svět ;D

Prachy se najdou, pokud je něco dobré. Spíše to otáčíš. Pokud by Haskell nebyla jen hračka, tak už v ní někdo vyvíjí a nástroje podpoří.

Pro lopaty to asi jazyk nebude, když se v tom dělají nejnáročnější věci, které bys neměl šanci s ničím jiným dělat.

Typy jsou vždy hlavně pro programátora a překladač mě nezajímá. Takže žádná výhoda Haskellu.

OSS není o nadšencích. Nebo je třeba Redhat pár nadšenců? Zajímavý, že oni mají docela zajímavé věci. Asi mají po večerech dost času :D

Není co lepšího zkusit, protože je Java králem. Takže co doporučuješ na náročný vývoj?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 01. 04. 2017, 15:41:11
Java na me pusobi, jak ten jazyk pro lopaty, protoze i triviality se rozepisuji na nekolik radek jako pohadka, spoustu veci musi programator vysvetlovat na nekolikrat.

Tak tohle by mě zajímalo:
- Jaké triviality se musí v Javě rozepisovat na několik řádek?
- Které věci musí programátor vysvětlovat Javě několikrát?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ondra Satai Nekola 01. 04. 2017, 15:48:48
Java na me pusobi, jak ten jazyk pro lopaty, protoze i triviality se rozepisuji na nekolik radek jako pohadka, spoustu veci musi programator vysvetlovat na nekolikrat.

Tak tohle by mě zajímalo:
- Jaké triviality se musí v Javě rozepisovat na několik řádek?
- Které věci musí programátor vysvětlovat Javě několikrát?

Trebas typy. I s <> mas porad veci, kde by ti typova inference omezila duplicity.

Na nekolik radek mas trebas klasickou javabeanu. Ve Scale (Haskellu...) mas podobne konstrukce vicemene zadarmo.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: JS 01. 04. 2017, 16:46:28
Na nekolik radek mas trebas klasickou javabeanu. Ve Scale (Haskellu...) mas podobne konstrukce vicemene zadarmo.

A to jsi ani nemusel zminovat deriving..
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ondra Satai Nekola 01. 04. 2017, 16:49:43
Na nekolik radek mas trebas klasickou javabeanu. Ve Scale (Haskellu...) mas podobne konstrukce vicemene zadarmo.

A to jsi ani nemusel zminovat deriving..

Hledal jsem nejake intelektualne minimalni protipriklady ;)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: fedorac 01. 04. 2017, 17:06:25
Blog napsany v r.2001 (pred 16 lety) o vyvoji z r.1995 (pred 22 lety) mnohe napovi.

http://www.paulgraham.com/avg.html (http://www.paulgraham.com/avg.html)

Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 01. 04. 2017, 17:17:40
To platilo možná tenkrát, ale tenkrát byl vývoj dost o ničem. Dnes je vše jinak. Takže z toho všeho plyne, že jen většina lidí neumí vyvíjet a věří něčemu, co neexistuje. Ale určitě je to super, jen se to nikde nepoužívá ;D Vás všechny bych chtěl v týmu...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ondra Satai Nekola 01. 04. 2017, 17:21:21
To platilo možná tenkrát, ale tenkrát byl vývoj dost o ničem. Dnes je vše jinak. Takže z toho všeho plyne, že jen většina lidí neumí vyvíjet a věří něčemu, co neexistuje. Ale určitě je to super, jen se to nikde nepoužívá ;D Vás všechny bych chtěl v týmu...

No my tebe ne...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 01. 04. 2017, 17:31:53
Blog napsany v r.2001 (pred 16 lety) o vyvoji z r.1995 (pred 22 lety) mnohe napovi.

http://www.paulgraham.com/avg.html (http://www.paulgraham.com/avg.html)

V každém případě je dobré se Lisp naučit. Když si představím, že by se Lispem dal nahradit backend, webserver, HTML, CSS, Javascript,...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 01. 04. 2017, 17:37:25
Nástroje má určitě luxusní, když je tak mocný.

Jaké IDE se pro vývoj používá?

Dynamické typování to všechno jen potvrzuje.

Bude to pecka! Jen ti blázni s penězi to nechápou ;D
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 01. 04. 2017, 17:40:54
Je to odborník, to se pozná! ;D
Citace
After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 01. 04. 2017, 18:04:27
Je to odborník, to se pozná! ;D
Citace
After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried.

Kdo se při programování nechce unudit k smrti, ten si vybere firmu preferující Lisp nebo alespoň PHP či Python.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 01. 04. 2017, 18:20:48
Ne každý chce dělat s amatéry, kteří neumí programovat. Někdo chce prostě víc.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 01. 04. 2017, 18:37:38
Ne každý chce dělat s amatéry, kteří neumí programovat. Někdo chce prostě víc.

Takže už je ti určitě jasné, proč nechci dělat s javisty.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 01. 04. 2017, 18:52:02
Jasný, PHP je totiž jeden z nejlepších jazyků všech dob a jen pro ty nejlepší 8)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 01. 04. 2017, 19:09:17
Jasný, PHP je totiž jeden z nejlepších jazyků všech dob a jen pro ty nejlepší 8)

Nejlepším jazykem byl, je a bude Lisp. Ostatní jazyky ho jen více či méně úspěšně napodobují.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 01. 04. 2017, 19:19:51
Jistě, proto je tak populární ;)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: YF 01. 04. 2017, 20:10:37
Jistě, proto je tak populární ;)
koukam chlapce ze sis uzil krasnej jarni den ... a takhle kazdej den celej rok a vic :) 3 veci porad dokola jak kafemlejnek - tomu se chlapce rika sebeublizovani a jak sem rikal - zajdi si k panu doktorovi
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: tru 01. 04. 2017, 20:31:26
A co třeba clojure? Taková moderní implementace lispu... a může sloužit i jako odpověď na otázku, co místo oop...

jinak scala je IMHO příliš expresivní, umí toho příliš moc... nikdy mi nesedla...

Dobře se mi pracuje s Groovy ale vadí mi, že je to dynamický jazyk...

Dále tu máme Kotlin... staticky typový, umí spoustu věcí, co má Scala a Groovy... moc se mi líbí...


bohužel, u mě v práci skousnou leda Groovy, protože některé systémy, se kterými pracujeme, ho používají... jinak Scala, Clojure, Kotlin... jedním slovem NE

btw http://www.itworld.com/article/2693998/big-data/clojure-developers-are-the-happiest-developers.html

a v práci mi na to řekli:
hola hoj,jedním slovem "ne". to raději začnu přidávat lidem do kafe LSD, aby jste se cítili šťastnější.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 01. 04. 2017, 20:35:16
Já ti nevím - z doktorů mám strach ...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Polymath 01. 04. 2017, 20:49:54
A co třeba clojure? Taková moderní implementace lispu... a může sloužit i jako odpověď na otázku, co místo oop...

jinak scala je IMHO příliš expresivní, umí toho příliš moc... nikdy mi nesedla...

Dobře se mi pracuje s Groovy ale vadí mi, že je to dynamický jazyk...

Dále tu máme Kotlin... staticky typový, umí spoustu věcí, co má Scala a Groovy... moc se mi líbí...


bohužel, u mě v práci skousnou leda Groovy, protože některé systémy, se kterými pracujeme, ho používají... jinak Scala, Clojure, Kotlin... jedním slovem NE

btw http://www.itworld.com/article/2693998/big-data/clojure-developers-are-the-happiest-developers.html

a v práci mi na to řekli:
hola hoj,jedním slovem "ne". to raději začnu přidávat lidem do kafe LSD, aby jste se cítili šťastnější.
Příslovečné "vectors headed up" jsou staticky typované jazyky, co se tváří jako dynamické a nechají žít programátora v iluzi OOP, i když ve skutečnosti se nativně kompilují a umožňují FP (lehce, bez vynucování).
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 01. 04. 2017, 20:54:48
Já ti nevím - z doktorů mám strach ...

Tak zkus zmíněné Clojure, JVM tě určitě potěší.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gll 01. 04. 2017, 22:09:27
A co třeba clojure? Taková moderní implementace lispu... a může sloužit i jako odpověď na otázku, co místo oop...

jinak scala je IMHO příliš expresivní, umí toho příliš moc... nikdy mi nesedla...

Dobře se mi pracuje s Groovy ale vadí mi, že je to dynamický jazyk...

Dále tu máme Kotlin... staticky typový, umí spoustu věcí, co má Scala a Groovy... moc se mi líbí...


bohužel, u mě v práci skousnou leda Groovy, protože některé systémy, se kterými pracujeme, ho používají... jinak Scala, Clojure, Kotlin... jedním slovem NE

btw http://www.itworld.com/article/2693998/big-data/clojure-developers-are-the-happiest-developers.html

a v práci mi na to řekli:
hola hoj,jedním slovem "ne". to raději začnu přidávat lidem do kafe LSD, aby jste se cítili šťastnější.
Příslovečné "vectors headed up" jsou staticky typované jazyky, co se tváří jako dynamické a nechají žít programátora v iluzi OOP, i když ve skutečnosti se nativně kompilují a umožňují FP (lehce, bez vynucování).

Předpokládám, že mluvíš o Go. To může být jen přechodná móda. Zatím ten jazyk propagují lidé, kteří předtím ujížděli na jiných hypech.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 01. 04. 2017, 22:23:45
A kteří neumějí vyvíjet.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Polymath 01. 04. 2017, 22:30:18
A co třeba clojure? Taková moderní implementace lispu... a může sloužit i jako odpověď na otázku, co místo oop...

jinak scala je IMHO příliš expresivní, umí toho příliš moc... nikdy mi nesedla...

Dobře se mi pracuje s Groovy ale vadí mi, že je to dynamický jazyk...

Dále tu máme Kotlin... staticky typový, umí spoustu věcí, co má Scala a Groovy... moc se mi líbí...


bohužel, u mě v práci skousnou leda Groovy, protože některé systémy, se kterými pracujeme, ho používají... jinak Scala, Clojure, Kotlin... jedním slovem NE

btw http://www.itworld.com/article/2693998/big-data/clojure-developers-are-the-happiest-developers.html

a v práci mi na to řekli:
hola hoj,jedním slovem "ne". to raději začnu přidávat lidem do kafe LSD, aby jste se cítili šťastnější.
Příslovečné "vectors headed up" jsou staticky typované jazyky, co se tváří jako dynamické a nechají žít programátora v iluzi OOP, i když ve skutečnosti se nativně kompilují a umožňují FP (lehce, bez vynucování).

Předpokládám, že mluvíš o Go. To může být jen přechodná móda. Zatím ten jazyk propagují lidé, kteří předtím ujížděli na jiných hypech.
Nejen. V případě Go na něm "ujíždí" ti, co předním dělali v C(++). Ten jazyk je by design hypeless, v něčem možná až moc - celá jeho filosofie je hezky shrnutá v přednáškách Pika. Já ale myslel trend, kam patří i Rust nebo i Swift, ten je ale zatím ve stavu vysoké entropie.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gll 01. 04. 2017, 22:42:43
Nejen. V případě Go na něm "ujíždí" ti, co předním dělali v C(++). Ten jazyk je by design hypeless, v něčem možná až moc - celá jeho filosofie je hezky shrnutá v přednáškách Pika. Já ale myslel trend, kam patří i Rust nebo i Swift, ten je ale zatím ve stavu vysoké entropie.

Lidé mají tendenci otáčet o 180 stupňů. Nedávno byly v módě jazyky s vysokou mírou abstrakce (například Scala) a Go je protireakce.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Polymath 01. 04. 2017, 22:46:42
Nejen. V případě Go na něm "ujíždí" ti, co předním dělali v C(++). Ten jazyk je by design hypeless, v něčem možná až moc - celá jeho filosofie je hezky shrnutá v přednáškách Pika. Já ale myslel trend, kam patří i Rust nebo i Swift, ten je ale zatím ve stavu vysoké entropie.

Lidé mají tendenci otáčet o 180 stupňů. Nedávno byly v módě jazyky s vysokou mírou abstrakce (například Scala) a Go je protireakce.
Cílová skupina je jiná.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 03. 04. 2017, 09:29:05
Kurna, teraz som si uvedomil, ked to tak citam, ze som zabudol pridat link. Zaujimal ma nazor na vyjadrenia tych ludi ohladom OOP
http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html (http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html)

V podstatě tam píší, že objektové jazyky bývají systematicky zneužívány ke psaní procedurálního kódu a tedy nesplňují původní očekávání. Dědičnost se potlačuje ve prospěch kompozice, zapouzdření se systematicky porušuje a polymorfismus je pro spoustu programátorů jen cizím slovem. K tomu příšerný přístup k definicím rozhraní a máme tady procedurální kód zabalený do tříd, který se jen tváří, že je objektový.

Ti programátoři si vlastně jen stěžují, že principy OOP zůstaly většinou vývojářů nepochopeny.

Myslím si v podstatě to samé - OOP se vlastně nikdy pořádně nepoužívalo, jeho potenciál nebyl nikdy využit. Že něco nechápu, neznamená, že je to na hovno. Další otázkou je, odkud pocházejí zkušenosti oněch komentátorů - jestli z něčeho jako C++ (např. komentář Torvaldse), dávalo by to smysl. A každý by se měl věnovat jen tomu, čemu rozumí.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Tuxik 03. 04. 2017, 09:55:26
A já to říkám pořád... OOP je především dobré pro práci s daty, v některých případech to dává smysl i jinde, ale pokud chce mít někdo jako objekt úplně všechno a tvoří v tom i lineární aplikace, nedává to smysl. Je to neefektivní a kód to zesložiťuje.

Mám opačnou zkušenost: OOP mi aplikace zkracuje a zefektivňuje. Hlavně mi zlepšuje přehled o tom, kde mám kterou část kódu. Když se mi změní zadání, tak většinou stačí vyměnit nějakou třídu za novou a jede se dál.
Všeho s mírou. Jak jsem psal, dává to smysl i v některých jiných případech, ale nic se nemá přehánět. Procedurální "zobjektovaný" 1:1 jen proto, že je to cool, není nic hezkého a bohužel to nejí výjimka.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 03. 04. 2017, 10:58:37
A já to říkám pořád... OOP je především dobré pro práci s daty, v některých případech to dává smysl i jinde, ale pokud chce mít někdo jako objekt úplně všechno a tvoří v tom i lineární aplikace, nedává to smysl. Je to neefektivní a kód to zesložiťuje.

Mám opačnou zkušenost: OOP mi aplikace zkracuje a zefektivňuje. Hlavně mi zlepšuje přehled o tom, kde mám kterou část kódu. Když se mi změní zadání, tak většinou stačí vyměnit nějakou třídu za novou a jede se dál.
Všeho s mírou. Jak jsem psal, dává to smysl i v některých jiných případech, ale nic se nemá přehánět. Procedurální "zobjektovaný" 1:1 jen proto, že je to cool, není nic hezkého a bohužel to nejí výjimka.

Zrovna koukám na aplikaci napsanou v shellu "lineárně". Aby to nebylo v jednom souboru, je tam hromada "source", tedy includů jiných souborů. V objektech to určitě bude vypadat mnohem lépe, ale v podstatě tu aplikaci budu muset navrhnout znovu a pořádně. O nějakém "zobjektování" nemůže být řeč. V případě ponechání shellu by se jednalo spíš o "zfunkcionálnění".
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Tuxik 03. 04. 2017, 11:10:11
Zrovna koukám na aplikaci napsanou v shellu "lineárně". Aby to nebylo v jednom souboru, je tam hromada "source", tedy includů jiných souborů. V objektech to určitě bude vypadat mnohem lépe, ale v podstatě tu aplikaci budu muset navrhnout znovu a pořádně. O nějakém "zobjektování" nemůže být řeč. V případě ponechání shellu by se jednalo spíš o "zfunkcionálnění".
No a jsme u toho. OOP vyžaduje rozumný návrh a pokud se očekává, že aplikace poroste a budou jí přibývat nové funkcionality, musí se na to včas myslet. Tím nechci říct, že u procedurálního programování se špatný návrh ztratí, ale u OOP mně to přijde kritičtější. Ono takový dohledávání dědičností, dědiců, vyděděnců, nevlastních dětí a retardovaných bratranců, to je masakr.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 03. 04. 2017, 11:40:38
- Jaké triviality se musí v Javě rozepisovat na několik řádek?

Pokud jsem si všimnul, tak Collection z iterací umí jen "do" (forEach), nezná select, collect (map), inject (reduce), anySatisfy, allSatisfy, ...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ondra Satai Nekola 03. 04. 2017, 11:59:22
- Jaké triviality se musí v Javě rozepisovat na několik řádek?

Pokud jsem si všimnul, tak Collection z iterací umí jen "do" (forEach), nezná select, collect (map), inject (reduce), anySatisfy, allSatisfy, ...

Nutno podotknout, ze od tehle moznosti jsi vetsinou jenom jedno volani .stream() daleko...

Idealni to neni, ale zrovna tohle neni zas takova tragedie.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: BoneFlute 03. 04. 2017, 12:06:17
Zrovna koukám na aplikaci napsanou v shellu "lineárně". Aby to nebylo v jednom souboru, je tam hromada "source", tedy includů jiných souborů. V objektech to určitě bude vypadat mnohem lépe, ale v podstatě tu aplikaci budu muset navrhnout znovu a pořádně. O nějakém "zobjektování" nemůže být řeč. V případě ponechání shellu by se jednalo spíš o "zfunkcionálnění".
No a jsme u toho. OOP vyžaduje rozumný návrh a pokud se očekává, že aplikace poroste a budou jí přibývat nové funkcionality, musí se na to včas myslet. Tím nechci říct, že u procedurálního programování se špatný návrh ztratí, ale u OOP mně to přijde kritičtější. Ono takový dohledávání dědičností, dědiců, vyděděnců, nevlastních dětí a retardovaných bratranců, to je masakr.

Moje zkušenost je taková, že největší problém OOP je v tom, že ho prakticky nikdo neumí. Takže jako koncept je tímto dost naprd.

Opravovat zobjektizovaný kód je dost na prd.
Opravovat funkcionální kód mi přišlo mnohem snazší. Přijde mi, že v tom nemůžeš udělat takové špagety jako v OOP. Aktivněji ti v tom brání.

Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 03. 04. 2017, 12:10:43

Nutno podotknout, ze od tehle moznosti jsi vetsinou jenom jedno volani .stream() daleko...

Idealni to neni, ale zrovna tohle neni zas takova tragedie.

Určitě to jde vždycky nějak ojebat, ale proč? Upozorňuju, že se bavíme o základní funkcionalitě seznamů, žádné specializované, obskurní, okrajové operace.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Tuxik 03. 04. 2017, 12:20:32
Opravovat zobjektizovaný kód je dost na prd.
Opravovat funkcionální kód mi přišlo mnohem snazší. Přijde mi, že v tom nemůžeš udělat takové špagety jako v OOP. Aktivněji ti v tom brání.
No... ne že by v tom přímo bránil, ale v OOP je víc špagetovacích možností... třeba právě dědičnost. Už jsem viděl objekt, který se jmenoval nějak mainobject, jedinou vlastností bylo nějaký ID a všechny ostatní objekty byly jeho potomkem. V podobném duchu se to neslo dál, takže než se člověk prokousal přes x úrovní, aby zjistil, proč se to se.. kazí, tak měl skoro fousatý děti.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ondra Satai Nekola 03. 04. 2017, 12:32:03

Nutno podotknout, ze od tehle moznosti jsi vetsinou jenom jedno volani .stream() daleko...

Idealni to neni, ale zrovna tohle neni zas takova tragedie.

Určitě to jde vždycky nějak ojebat, ale proč? Upozorňuju, že se bavíme o základní funkcionalitě seznamů, žádné specializované, obskurní, okrajové operace.

To neni zadne ojebat. To je zakladni API.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kamil Podlešák 03. 04. 2017, 12:41:39
Nutno podotknout, ze od tehle moznosti jsi vetsinou jenom jedno volani .stream() daleko...
Idealni to neni, ale zrovna tohle neni zas takova tragedie.
Určitě to jde vždycky nějak ojebat, ale proč? Upozorňuju, že se bavíme o základní funkcionalitě seznamů, žádné specializované, obskurní, okrajové operace.
Protože všechny tyto operace nejsou základní funkcionalitou jen seznamů, a dokonce ani nejsou omezeny na kolekce. Takže jsou součástí samostatného interface Stream, nikoliv Collection (nebo dokonce List).

Jistě, je otázkou proč vlastně Collection neimplementuje Stream (tj. je to "kompozice" místo "dědičnosti"), ale to už je hodně technikálie (a při rozhodování hrála velkou roli nejenom omezení jazyka, ale i zpětná kompatabilita).
Ideální to nikdy nebude, protože Java je prostě low-level jazyk a tohle roubování bude vždy skřípat. Nejlepší je prostě použít jiný jazyk nad JVM, ale do toho se moc lidem nechce...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: SB 03. 04. 2017, 12:49:12
Seznam a proud jsou 2 zcela odlišné abstrakce, to, že zahrnují podobnou funkcionalitu, není důvodem, abych jeden z oněch konceptů řešil tím druhým.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ondra Satai Nekola 03. 04. 2017, 13:03:48
Seznam a proud jsou 2 zcela odlišné abstrakce, to, že zahrnují podobnou funkcionalitu, není důvodem, abych jeden z oněch konceptů řešil tím druhým.

Whatever. V realu tohle vazne je ten posledni problem, co te pri psani v Jave trapi, protoze jedno z druheho umis na jedno code completion...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: BoneFlute 03. 04. 2017, 13:51:30
Opravovat zobjektizovaný kód je dost na prd.
Opravovat funkcionální kód mi přišlo mnohem snazší. Přijde mi, že v tom nemůžeš udělat takové špagety jako v OOP. Aktivněji ti v tom brání.
No... ne že by v tom přímo bránil, ale v OOP je víc špagetovacích možností... třeba právě dědičnost. Už jsem viděl objekt, který se jmenoval nějak mainobject, jedinou vlastností bylo nějaký ID a všechny ostatní objekty byly jeho potomkem. V podobném duchu se to neslo dál, takže než se člověk prokousal přes x úrovní, aby zjistil, proč se to se.. kazí, tak měl skoro fousatý děti.

Ano, to je takříkajíc ze života.

Zatímco zvrtej použití funkce. Teď z fleku mě napadají jen tyto způsoby:
- vracení hodnoty argumentem
- side-efekt
- vracení funkce (ne že by to bylo špatně, ale je to takovej kandidát na znečitelnění)
- ob rekurze (funkce `a` volá `b` a ta volá `a`)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gll 03. 04. 2017, 14:15:12
Ano, to je takříkajíc ze života.

Zatímco zvrtej použití funkce. Teď z fleku mě napadají jen tyto způsoby:
- vracení hodnoty argumentem
- side-efekt
- vracení funkce (ne že by to bylo špatně, ale je to takovej kandidát na znečitelnění)
- ob rekurze (funkce `a` volá `b` a ta volá `a`)

zdokumentované side-efekty mohou vést květší přehlednosti.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ondra Satai Nekola 03. 04. 2017, 14:31:32
Ano, to je takříkajíc ze života.

Zatímco zvrtej použití funkce. Teď z fleku mě napadají jen tyto způsoby:
- vracení hodnoty argumentem
- side-efekt
- vracení funkce (ne že by to bylo špatně, ale je to takovej kandidát na znečitelnění)
- ob rekurze (funkce `a` volá `b` a ta volá `a`)

zdokumentované side-efekty mohou vést květší přehlednosti.

Az do okamziku, kdy se rozjdede dokumentace a kod. Takze zhruba po dobu jednoho tydne realneho vyvoje.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 03. 04. 2017, 14:37:41
Zrovna koukám na aplikaci napsanou v shellu "lineárně". Aby to nebylo v jednom souboru, je tam hromada "source", tedy includů jiných souborů. V objektech to určitě bude vypadat mnohem lépe, ale v podstatě tu aplikaci budu muset navrhnout znovu a pořádně. O nějakém "zobjektování" nemůže být řeč. V případě ponechání shellu by se jednalo spíš o "zfunkcionálnění".
No a jsme u toho. OOP vyžaduje rozumný návrh a pokud se očekává, že aplikace poroste a budou jí přibývat nové funkcionality, musí se na to včas myslet. Tím nechci říct, že u procedurálního programování se špatný návrh ztratí, ale u OOP mně to přijde kritičtější. Ono takový dohledávání dědičností, dědiců, vyděděnců, nevlastních dětí a retardovaných bratranců, to je masakr.

V žádném případně se však nesmí optimalizovat předčasně. Pokud se udělá dědičnost správně, nebývá s tím problém - stačí dodržet LSP. Mnohem větší hrůzu mívám z dlouhatánských tříd s hromadou veřejných metod a protected atributů.

Jakmile má třída > 4 atributy, je okamžitě kandidátem na refaktorování.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: BoneFlute 03. 04. 2017, 15:03:04
zdokumentované side-efekty mohou vést květší přehlednosti.

Nevěřím.
Uznávám, že side-efekty někdy být musí. Ale měli by tě k tomu donutit technické omezení.

Někdy by-design rezignuju u akumulátoru (logger apod.). Hlavně proto, že pracuju s lidma, kteří mají zatím jen imperativní a OOP výchovu a s kódem z takového myšlení vzniknuvším.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gll 03. 04. 2017, 15:20:15
zdokumentované side-efekty mohou vést květší přehlednosti.

Nevěřím.
Uznávám, že side-efekty někdy být musí. Ale měli by tě k tomu donutit technické omezení.

Někdy by-design rezignuju u akumulátoru (logger apod.). Hlavně proto, že pracuju s lidma, kteří mají zatím jen imperativní a OOP výchovu a s kódem z takového myšlení vzniknuvším.

side efekty mohou být alternativou k vnořování funkcí. V perlu mohu napsat:

Kód: [Vybrat]
while(<>) {
    chomp;
    tr/ /_/;
    s/.*\.txt$/$&.old\n/;
    print if $&;
}

takový kód se mnohem snadněji debuguje než několik vnořených funkcí a současně nemusím vymýšlet názvy proměnných pro mezivýsledky. IMHO je to lepší než různá threading makra v lispech.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 03. 04. 2017, 15:58:45
takový kód se mnohem snadněji debuguje než několik vnořených funkcí a současně nemusím vymýšlet názvy proměnných pro mezivýsledky. IMHO je to lepší než různá threading makra v lispech.

Líný vývojář, který není schopen vymyslet název proměnné pro mezivýsledky, je největší pohromou pro ostatní vývojáře v týmu. Významně totiž zvyšuje počet WTF za hodinu.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gll 03. 04. 2017, 16:02:42
Líný vývojář, který není schopen vymyslet název proměnné pro mezivýsledky, je největší pohromou pro ostatní vývojáře v týmu. Významně totiž zvyšuje počet WTF za hodinu.

Jde o eliminaci code noise. Naopak to snižuje počet WTF, protože je vynucováno použítí standartizovaných názvů.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ondra Satai Nekola 03. 04. 2017, 16:11:45
Pokud mne mel ten kus kodu presvedcit o skvelosti sideefektu, tak se mu to nepodarilo...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 03. 04. 2017, 16:18:53
Líný vývojář, který není schopen vymyslet název proměnné pro mezivýsledky, je největší pohromou pro ostatní vývojáře v týmu. Významně totiž zvyšuje počet WTF za hodinu.

Jde o eliminaci code noise. Naopak to snižuje počet WTF, protože je vynucováno použítí standartizovaných názvů.

Za code noise považuji hlavně komentáře, které překladač/interpretr ignoruje. Za nejlepší komentáře považuji správnou volbu názvů. Dodávají kódu sémantiku.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 03. 04. 2017, 17:04:10
getValueButLastCompilerVersionHasBugSoWeNeedAddTwoToResult()
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 03. 04. 2017, 17:26:11
getValueButLastCompilerVersionHasBugSoWeNeedAddTwoToResult()

To má být vtip? Obvykle si vystačím s jedním či maximálně dvěma slovy.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 03. 04. 2017, 17:42:00
A kam dáš dočasné detaily? Přece bys nepoužíval ohavné komentáře, které vše zničí :o
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 03. 04. 2017, 18:41:11
A kam dáš dočasné detaily? Přece bys nepoužíval ohavné komentáře, které vše zničí :o

Do proměnných.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: lispman 03. 04. 2017, 18:53:26
A kam dáš dočasné detaily? Přece bys nepoužíval ohavné komentáře, které vše zničí :o
Do závorek.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ondrej Nemecek 03. 04. 2017, 18:59:54
Podle mě v praxi prostě vázne právě ta formální stránka kódu. Bez ručního přečtení kódu se nemůže člověk spolehnout skoro na nic. Není jasné, zda mají metody vedlejší efekty, není jasná kardinalita vztahů, není jasné, co se kde validuje, není jasné které entity jsou attached vzhledem k databázi, není jasné, kam všude se může dostat null hodnota, není jasné co je bezpečné pro běh ve více vláknech atd. atd. atd.

Samozřejmě různé návrhové vzory, rozhraní, anotace atd. se tohle všechno snaží nějak řešit, ale přijde mi to pořád takové nespolehlivé. Jako ideál bych si představil to, že si pro aplikaci postavím takový typový systém, který si pak už sám ohlídá, že se správné věci dějí na správných místech. Asi jako když si stavím strukturu relační databáze.

Nejspíš se tohle příliš nerozšířilo hlavně kvůli tomu, že to vyžaduje víc matematiky a víc abstrakce, než kolik je mezi programátory běžně k dispozici. Proto to zůstává spíš na akademické půdě a praxi se pořád „tak nějak prasí“.

Ale rád se poučím, pokud se to někde dělá jinak. Docela rád bych i viděl to „pravé OOP“. POřád mi není úplně jasné, co se tím míní a v čem se to liší od současného stavu.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: lispman 03. 04. 2017, 19:04:25
http://lucacardelli.name/TheoryOfObjects.html

Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 03. 04. 2017, 20:18:36
http://lucacardelli.name/TheoryOfObjects.html

Vždyť je tam jen obsah a rejstřík. Navíc je to podle obsahu spíš zaměřeno na C#, který mě vůbec nezajímá. Tady se snažíme dopátrat "toho pravého OOP".
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 03. 04. 2017, 20:37:44
http://lucacardelli.name/TheoryOfObjects.html

Vždyť je tam jen obsah a rejstřík. Navíc je to podle obsahu spíš zaměřeno na C#, který mě vůbec nezajímá. Tady se snažíme dopátrat "toho pravého OOP".

Pravé OOP je dynamický shit, který se nepoužívá, protože je to shit. Používá se luxusní Java OOP, které se hodí na většinu běžných věcí. Nechápu, co za architekturu by člověk musel vymyslet, aby to s Javou nezvládl a hodilo se mu něco jiného.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: lispman 03. 04. 2017, 20:44:22
http://lucacardelli.name/TheoryOfObjects.html

Vždyť je tam jen obsah a rejstřík. Navíc je to podle obsahu spíš zaměřeno na C#, který mě vůbec nezajímá. Tady se snažíme dopátrat "toho pravého OOP".

Pravé OOP je dynamický shit, který se nepoužívá, protože je to shit. Používá se luxusní Java OOP, které se hodí na většinu běžných věcí. Nechápu, co za architekturu by člověk musel vymyslet, aby to s Javou nezvládl a hodilo se mu něco jiného.

Vy dva tu reprezentujete nějaký syndikát idiotů?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 03. 04. 2017, 20:57:27
O tom nic nevím.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: BoneFlute 03. 04. 2017, 21:11:07
zdokumentované side-efekty mohou vést květší přehlednosti.

Nevěřím.
Uznávám, že side-efekty někdy být musí. Ale měli by tě k tomu donutit technické omezení.

Někdy by-design rezignuju u akumulátoru (logger apod.). Hlavně proto, že pracuju s lidma, kteří mají zatím jen imperativní a OOP výchovu a s kódem z takového myšlení vzniknuvším.

side efekty mohou být alternativou k vnořování funkcí. V perlu mohu napsat:

Kód: [Vybrat]
while(<>) {
    chomp;
    tr/ /_/;
    s/.*\.txt$/$&.old\n/;
    print if $&;
}

takový kód se mnohem snadněji debuguje než několik vnořených funkcí a současně nemusím vymýšlet názvy proměnných pro mezivýsledky. IMHO je to lepší než různá threading makra v lispech.

Takovej kód je v pořádku do okamžiku, dokavad je navrchu. Jakmile z něj uděláš funkci jsi v místě kam slunce nesvítí.
Zdůrazním: problém není vnořování funkcí ani vymýšlení názvů. Problém je side-efekt jako takovej. Prostě ten kód ti šáhne na výstup.

Bohužel ostatní nemohu komentovat, Perlem jsem nepolíben.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: jpu 03. 04. 2017, 21:18:16
co je Java OOP? :D.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gll 03. 04. 2017, 21:28:49
zdokumentované side-efekty mohou vést květší přehlednosti.

Nevěřím.
Uznávám, že side-efekty někdy být musí. Ale měli by tě k tomu donutit technické omezení.

Někdy by-design rezignuju u akumulátoru (logger apod.). Hlavně proto, že pracuju s lidma, kteří mají zatím jen imperativní a OOP výchovu a s kódem z takového myšlení vzniknuvším.

side efekty mohou být alternativou k vnořování funkcí. V perlu mohu napsat:

Kód: [Vybrat]
while(<>) {
    chomp;
    tr/ /_/;
    s/.*\.txt$/$&.old\n/;
    print if $&;
}

takový kód se mnohem snadněji debuguje než několik vnořených funkcí a současně nemusím vymýšlet názvy proměnných pro mezivýsledky. IMHO je to lepší než různá threading makra v lispech.

Takovej kód je v pořádku do okamžiku, dokavad je navrchu. Jakmile z něj uděláš funkci jsi v místě kam slunce nesvítí.
Zdůrazním: problém není vnořování funkcí ani vymýšlení názvů. Problém je side-efekt jako takovej. Prostě ten kód ti šáhne na výstup.

Bohužel ostatní nemohu komentovat, Perlem jsem nepolíben.

$_ ve while je lokální, dynamicky scopované. Jinak mohu napsat local $_; na začátku funkce.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: BoneFlute 03. 04. 2017, 21:34:40
zdokumentované side-efekty mohou vést květší přehlednosti.

Nevěřím.
Uznávám, že side-efekty někdy být musí. Ale měli by tě k tomu donutit technické omezení.

Někdy by-design rezignuju u akumulátoru (logger apod.). Hlavně proto, že pracuju s lidma, kteří mají zatím jen imperativní a OOP výchovu a s kódem z takového myšlení vzniknuvším.

side efekty mohou být alternativou k vnořování funkcí. V perlu mohu napsat:

Kód: [Vybrat]
while(<>) {
    chomp;
    tr/ /_/;
    s/.*\.txt$/$&.old\n/;
    print if $&;
}

takový kód se mnohem snadněji debuguje než několik vnořených funkcí a současně nemusím vymýšlet názvy proměnných pro mezivýsledky. IMHO je to lepší než různá threading makra v lispech.

Takovej kód je v pořádku do okamžiku, dokavad je navrchu. Jakmile z něj uděláš funkci jsi v místě kam slunce nesvítí.
Zdůrazním: problém není vnořování funkcí ani vymýšlení názvů. Problém je side-efekt jako takovej. Prostě ten kód ti šáhne na výstup.

Bohužel ostatní nemohu komentovat, Perlem jsem nepolíben.

$_ ve while je lokální, dynamicky scopované. Jinak mohu napsat local $_; na začátku funkce.
No a?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gll 03. 04. 2017, 21:38:47
No a?

tím side-efektem jsi myslel změnu $_, nebo print? Print je tam nepodstatný, šlo ukázku použití $_ k ukládání mezivýsledků.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Polymath 03. 04. 2017, 22:23:06
Podle mě v praxi prostě vázne právě ta formální stránka kódu. Bez ručního přečtení kódu se nemůže člověk spolehnout skoro na nic. Není jasné, zda mají metody vedlejší efekty, není jasná kardinalita vztahů, není jasné, co se kde validuje, není jasné které entity jsou attached vzhledem k databázi, není jasné, kam všude se může dostat null hodnota, není jasné co je bezpečné pro běh ve více vláknech atd. atd. atd.

Samozřejmě různé návrhové vzory, rozhraní, anotace atd. se tohle všechno snaží nějak řešit, ale přijde mi to pořád takové nespolehlivé. Jako ideál bych si představil to, že si pro aplikaci postavím takový typový systém, který si pak už sám ohlídá, že se správné věci dějí na správných místech. Asi jako když si stavím strukturu relační databáze.

Nejspíš se tohle příliš nerozšířilo hlavně kvůli tomu, že to vyžaduje víc matematiky a víc abstrakce, než kolik je mezi programátory běžně k dispozici. Proto to zůstává spíš na akademické půdě a praxi se pořád „tak nějak prasí“.

Ale rád se poučím, pokud se to někde dělá jinak. Docela rád bych i viděl to „pravé OOP“. POřád mi není úplně jasné, co se tím míní a v čem se to liší od současného stavu.
OOP je široký pojem neimplikující dědičnost ani konkrétní způsob typování. Někteří fanatici považují za pravé OOP jen Smalltalk nebo ObjC - prostě jazyk s dynamickým typováním. Nicméně cokoliv s polymorfismem umožňuje mít objekty a virtuální dispatch. Dynamický dispatch je super na určité věci jako distribuované objekty, ale to se už stejně nepoužívá (kdo dnes tvoří COM a NEO?), takže nemá smysl to řešit. Mnohem důležitější je efektivita a výkon, což je k výše uvedenému ortogonální.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 03. 04. 2017, 22:26:26
http://lucacardelli.name/TheoryOfObjects.html

Vždyť je tam jen obsah a rejstřík. Navíc je to podle obsahu spíš zaměřeno na C#, který mě vůbec nezajímá. Tady se snažíme dopátrat "toho pravého OOP".

Pravé OOP je dynamický shit, který se nepoužívá, protože je to shit. Používá se luxusní Java OOP, které se hodí na většinu běžných věcí. Nechápu, co za architekturu by člověk musel vymyslet, aby to s Javou nezvládl a hodilo se mu něco jiného.

Vy dva tu reprezentujete nějaký syndikát idiotů?

Jestli si myslíš, že si po přečtení toho nevalného obsahu půjdu tu mizernou knihu koupit, tak jsi na omylu. To si raději znovu přečtu knihu od Bruce Eckela: Thinking in Java, která je skvělá hlavně díky kvalitnímu OOP.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: BoneFlute 03. 04. 2017, 22:26:48
No a?

tím side-efektem jsi myslel změnu $_, nebo print? Print je tam nepodstatný, šlo ukázku použití $_ k ukládání mezivýsledků.

Tím side-efektem jsem myslel print. Zbytku nerozumím. Ve skutečnosti tam $_ ani nikde nevidím. Ale to je otázky mé neznalosti konkrétního jazyka. Takže asi nějaký lepší příklad.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 03. 04. 2017, 22:30:11
... Mnohem důležitější je efektivita a výkon, což je k výše uvedenému ortogonální.

Tohle je dnes oblíbený FUD. Pravé OOP je efektivní a výkonné, jen si toho někteří vývojáři nestačili všimnout.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Polymath 03. 04. 2017, 22:42:02
... Mnohem důležitější je efektivita a výkon, což je k výše uvedenému ortogonální.

Tohle je dnes oblíbený FUD. Pravé OOP je efektivní a výkonné, jen si toho někteří vývojáři nestačili všimnout.
Pravé OOP používá na dispatch selektory, což extra výkon vylučuje. Stačí se podívat na algoritmy cachování dispatche.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 03. 04. 2017, 22:58:41
... Mnohem důležitější je efektivita a výkon, což je k výše uvedenému ortogonální.

Tohle je dnes oblíbený FUD. Pravé OOP je efektivní a výkonné, jen si toho někteří vývojáři nestačili všimnout.
Pravé OOP používá na dispatch selektory, což extra výkon vylučuje. Stačí se podívat na algoritmy cachování dispatche.

Stačí nepoužívat veřejné *ettery a ztráta výkonu se stane nepodstanou. Také privátní atributy mají menší režii, než protected a public. Lokální proměnné mají nižší režii, než zmíněné privátní atributy. Když se to dá dokupy, vznikne z toho hezký a efektivní kód.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: BoneFlute 03. 04. 2017, 23:02:56
Stačí nepoužívat veřejné *ettery a ztráta výkonu se stane nepodstanou. Také privátní atributy mají menší režii, než protected a public. Lokální proměnné mají nižší režii, než zmíněné privátní atributy. Když se to dá dokupy, vznikne z toho hezký a efektivní kód.
Uff!
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Polymath 03. 04. 2017, 23:06:38
... Mnohem důležitější je efektivita a výkon, což je k výše uvedenému ortogonální.

Tohle je dnes oblíbený FUD. Pravé OOP je efektivní a výkonné, jen si toho někteří vývojáři nestačili všimnout.
Pravé OOP používá na dispatch selektory, což extra výkon vylučuje. Stačí se podívat na algoritmy cachování dispatche.

Stačí nepoužívat veřejné *ettery a ztráta výkonu se stane nepodstanou. Také privátní atributy mají menší režii, než protected a public. Lokální proměnné mají nižší režii, než zmíněné privátní atributy. Když se to dá dokupy, vznikne z toho hezký a efektivní kód.
Když se to dá dohromady, vznikne buď špagetoid nebo FP, což je buď moc špatně nebo moc dobře, ale už to nebude moc OOP. Příkladem budiž ObJC 2.0 nebo JavaScript, kde se dá pomocí bloků buď funkcionálně vylepšit kód, nebo vytvořit pejskokočičí monstrum.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: No name 03. 04. 2017, 23:07:29
http://lucacardelli.name/TheoryOfObjects.html

Vždyť je tam jen obsah a rejstřík. Navíc je to podle obsahu spíš zaměřeno na C#, který mě vůbec nezajímá. Tady se snažíme dopátrat "toho pravého OOP".

Pravé OOP je dynamický shit, který se nepoužívá, protože je to shit. Používá se luxusní Java OOP, které se hodí na většinu běžných věcí. Nechápu, co za architekturu by člověk musel vymyslet, aby to s Javou nezvládl a hodilo se mu něco jiného.

Vy dva tu reprezentujete nějaký syndikát idiotů?

 ;D  ;D ;D
Asi tak...  ;) Přesněji řečeno, u javamana je to nějaká psychická diagnóza, nejspíš kompenzace vlastního komplexu méněcennosti. Je tu celkem známým kašpárkem a nejlepší je mu neodporovat, jak se to doporučuje u všech psychicky labilních jedinců. Prakticky všechno co tu plácá můžeš bez jakýchkoli obav přesměrovat do /dev/null .
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 03. 04. 2017, 23:28:14
Stačí nepoužívat veřejné *ettery a ztráta výkonu se stane nepodstanou. Také privátní atributy mají menší režii, než protected a public. Lokální proměnné mají nižší režii, než zmíněné privátní atributy. Když se to dá dokupy, vznikne z toho hezký a efektivní kód.
Když se to dá dohromady, vznikne buď špagetoid nebo FP, což je buď moc špatně nebo moc dobře, ale už to nebude moc OOP. Příkladem budiž ObJC 2.0 nebo JavaScript, kde se dá pomocí bloků buď funkcionálně vylepšit kód, nebo vytvořit pejskokočičí monstrum.

Zajímavá dedukce. Špagety mám rád jen na talíři a do FP to má daleko. Takže ani jedno, ani druhé, ale OOP.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Polymath 03. 04. 2017, 23:34:10
Stačí nepoužívat veřejné *ettery a ztráta výkonu se stane nepodstanou. Také privátní atributy mají menší režii, než protected a public. Lokální proměnné mají nižší režii, než zmíněné privátní atributy. Když se to dá dokupy, vznikne z toho hezký a efektivní kód.
Když se to dá dohromady, vznikne buď špagetoid nebo FP, což je buď moc špatně nebo moc dobře, ale už to nebude moc OOP. Příkladem budiž ObJC 2.0 nebo JavaScript, kde se dá pomocí bloků buď funkcionálně vylepšit kód, nebo vytvořit pejskokočičí monstrum.

Zajímavá dedukce. Špagety mám rád jen na talíři a do FP to má daleko. Takže ani jedno, ani druhé, ale OOP.
Beru, že máš svou definici OOP. No problem
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: javaman () 03. 04. 2017, 23:41:07
Jestli si myslíš, že si po přečtení toho nevalného obsahu půjdu tu mizernou knihu koupit, tak jsi na omylu. To si raději znovu přečtu knihu od Bruce Eckela: Thinking in Java, která je skvělá hlavně díky kvalitnímu OOP.

Stačí nepoužívat veřejné *ettery a ztráta výkonu se stane nepodstanou. Také privátní atributy mají menší režii, než protected a public. Lokální proměnné mají nižší režii, než zmíněné privátní atributy. Když se to dá dokupy, vznikne z toho hezký a efektivní kód.
Když se to dá dohromady, vznikne buď špagetoid nebo FP, což je buď moc špatně nebo moc dobře, ale už to nebude moc OOP. Příkladem budiž ObJC 2.0 nebo JavaScript, kde se dá pomocí bloků buď funkcionálně vylepšit kód, nebo vytvořit pejskokočičí monstrum.

Zajímavá dedukce. Špagety mám rád jen na talíři a do FP to má daleko. Takže ani jedno, ani druhé, ale OOP.

+1

Zboj zase perlí. Tady má ale volné pole působnosti, protože většina lidí tu neumí vůbec nic. Jeden by dělníky a vývojáře hodil do stejného pytle, další by používal skriptovací jazyk na vše a podobně. Ale zase je to dobré vidět, co dělá konkurence a jestli je třeba se bát.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gll 03. 04. 2017, 23:55:23
No a?

tím side-efektem jsi myslel změnu $_, nebo print? Print je tam nepodstatný, šlo ukázku použití $_ k ukládání mezivýsledků.

Tím side-efektem jsem myslel print. Zbytku nerozumím. Ve skutečnosti tam $_ ani nikde nevidím. Ale to je otázky mé neznalosti konkrétního jazyka. Takže asi nějaký lepší příklad.

některé standartní funkce a operace defaultně mění proměnou $_.

Kód: [Vybrat]
while($_ = <STDIN>) {
    chomp $_;
    $_ =~ tr/ /_/;
    $_ =~ s/.*\.txt$/$&.old\n/;
    print $_;
}

je ekvivalentní tomu původnímu.

Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Polymath 04. 04. 2017, 00:21:21
http://lucacardelli.name/TheoryOfObjects.html

Vždyť je tam jen obsah a rejstřík. Navíc je to podle obsahu spíš zaměřeno na C#, který mě vůbec nezajímá. Tady se snažíme dopátrat "toho pravého OOP".

Pravé OOP je dynamický shit, který se nepoužívá, protože je to shit. Používá se luxusní Java OOP, které se hodí na většinu běžných věcí. Nechápu, co za architekturu by člověk musel vymyslet, aby to s Javou nezvládl a hodilo se mu něco jiného.

Vy dva tu reprezentujete nějaký syndikát idiotů?

 ;D  ;D ;D
Asi tak...  ;) Přesněji řečeno, u javamana je to nějaká psychická diagnóza, nejspíš kompenzace vlastního komplexu méněcennosti. Je tu celkem známým kašpárkem a nejlepší je mu neodporovat, jak se to doporučuje u všech psychicky labilních jedinců. Prakticky všechno co tu plácá můžeš bez jakýchkoli obav přesměrovat do /dev/null .
A Kit je javabumboy bez ega :)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 04. 04. 2017, 09:35:34
A Kit je javabumboy bez ega :)

A Polymath je imperativec a funkcionalista bez argumentů :)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ondra Satai Nekola 04. 04. 2017, 09:45:30
No a?

tím side-efektem jsi myslel změnu $_, nebo print? Print je tam nepodstatný, šlo ukázku použití $_ k ukládání mezivýsledků.

Tím side-efektem jsem myslel print. Zbytku nerozumím. Ve skutečnosti tam $_ ani nikde nevidím. Ale to je otázky mé neznalosti konkrétního jazyka. Takže asi nějaký lepší příklad.

některé standartní funkce a operace defaultně mění proměnou $_.

Kód: [Vybrat]
while($_ = <STDIN>) {
    chomp $_;
    $_ =~ tr/ /_/;
    $_ =~ s/.*\.txt$/$&.old\n/;
    print $_;
}

je ekvivalentní tomu původnímu.

A k cemu ze to potrebujes ty sideefekty? Vzdyt by v principu to same slo bez pomocnych promenych a bez vedlejsich efektu prostym zretezenim volani nebo nejakou variaci na unixovou rouru...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gll 04. 04. 2017, 10:53:22
A k cemu ze to potrebujes ty sideefekty? Vzdyt by v principu to same slo bez pomocnych promenych a bez vedlejsich efektu prostym zretezenim volani nebo nejakou variaci na unixovou rouru...

je to sekvenční kód. Mohu ho krokovat v debuggeru.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Ondra Satai Nekola 04. 04. 2017, 11:04:44
A k cemu ze to potrebujes ty sideefekty? Vzdyt by v principu to same slo bez pomocnych promenych a bez vedlejsich efektu prostym zretezenim volani nebo nejakou variaci na unixovou rouru...

je to sekvenční kód. Mohu ho krokovat v debuggeru.

A to by snad jinak neslo? Slo, kdybys nemel spatny debugger. (Nemluvim ani o tom, ze optimalizace kodu na pouziti v debuggeru neni nejspis to prave bananove.)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 04. 04. 2017, 11:10:02
A k cemu ze to potrebujes ty sideefekty? Vzdyt by v principu to same slo bez pomocnych promenych a bez vedlejsich efektu prostym zretezenim volani nebo nejakou variaci na unixovou rouru...

je to sekvenční kód. Mohu ho krokovat v debuggeru.

Možná se dá krokovat, což nepovažuji za významnou výhodu, ale s testovatelností to bude asi trochu horší.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: jpu 04. 04. 2017, 12:59:11
Mna by skor zaujimala jedna vec, ze ako viete posudit, ci to, co mate naprogramovane, je dobre, splna OOP alebo sa to aspon k OOP priblizuje. Vedel by niekto popr. odporucit nejaku knizku o OOP?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: shogun 04. 04. 2017, 13:33:43
už se to tady ve fóru několikrát řešilo...
čistě objektově:
http://sdmeta.gforge.inria.fr/FreeBooks/
http://files.pharo.org/books/

skripta od Merunky

https://en.wikipedia.org/wiki/Design_Patterns
http://www.dofactory.com/net/design-patterns


Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: shogun 04. 04. 2017, 13:38:39
už se to tady ve fóru několikrát řešilo...
čistě objektově:
http://sdmeta.gforge.inria.fr/FreeBooks/
http://files.pharo.org/books/

skripta od Merunky

https://en.wikipedia.org/wiki/Design_Patterns
http://www.dofactory.com/net/design-patterns

pokud chceš rovnou procvičit + videa + příklady a vysvětlení je pěkný kurz http://files.pharo.org/mooc/
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: BoneFlute 04. 04. 2017, 13:48:27
Mna by skor zaujimala jedna vec, ze ako viete posudit, ci to, co mate naprogramovane, je dobre, splna OOP alebo sa to aspon k OOP priblizuje. Vedel by niekto popr. odporucit nejaku knizku o OOP?
Programátoři obecně neumí OOP. A ti co se prsatí, že ano, těm se vyhejbej.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kiwi 04. 04. 2017, 13:54:13
Mna by skor zaujimala jedna vec, ze ako viete posudit, ci to, co mate naprogramovane, je dobre, splna OOP alebo sa to aspon k OOP priblizuje. Vedel by niekto popr. odporucit nejaku knizku o OOP?

To je těžké. Jeden nějakou doporučí a další ji zkritizují. Mně je třeba blízký ten přístup jaký má Alan Kay, u nás, co by autory literatury, reprezentovaný zejména pány Čadou a Merunkou.

Jestli je to dobře naprogramované, nebo raději bych použil slovo navržené... to se pozná podle toho, jestli při přidávání nebo úpravě nějaké funkcionality uvažuješ o té funkcionalitě, nebo většinu času zabere dumání, jak k sakru tu prkotinu do toho nacpat, aniž by se to celé muselo překopat nebo aniž by to byla nějaká prasárna. S tím druhým jsem se setkal u většiny projektů v C++, C# nebo Javě.
OOP má obvykle jednu nepříjemnou vlastnost, totiž tu, že násobí jakékoli nešikovnosti, vzniklé v době návrhu architektury. A řekl bych, že ten statičtější přístup (C++, Java) je násobí rozhodně větším koeficientem než ten dynamičtější (Objective C, Ruby).

Osobně považuji za dobře navržený objektový systém např. framework Cocoa. Sám jsem s tím dělal jen párkrát, ale dělalo se mi s tím opravdu velmi příjemně. Lidé, co jsem potkal a měli více příležitostí s tím pracovat, si to ale také velice chválili. Nebo třeba Pharo. Takže inspirace, jak se to dá dobře udělat, bych hledal tady. Když to porovnám třeba s Qt nebo .NET, tak mi to připadá mnohem elegantnější.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 04. 04. 2017, 14:13:08
Mna by skor zaujimala jedna vec, ze ako viete posudit, ci to, co mate naprogramovane, je dobre, splna OOP alebo sa to aspon k OOP priblizuje. Vedel by niekto popr. odporucit nejaku knizku o OOP?

To je těžké. Jeden nějakou doporučí a další ji zkritizují. Mně je třeba blízký ten přístup jaký má Alan Kay, u nás, co by autory literatury, reprezentovaný zejména pány Čadou a Merunkou.

Jestli je to dobře naprogramované, nebo raději bych použil slovo navržené... to se pozná podle toho, jestli při přidávání nebo úpravě nějaké funkcionality uvažuješ o té funkcionalitě, nebo většinu času zabere dumání, jak k sakru tu prkotinu do toho nacpat, aniž by se to celé muselo překopat nebo aniž by to byla nějaká prasárna. S tím druhým jsem se setkal u většiny projektů v C++, C# nebo Javě.
OOP má obvykle jednu nepříjemnou vlastnost, totiž tu, že násobí jakékoli nešikovnosti, vzniklé v době návrhu architektury. A řekl bych, že ten statičtější přístup (C++, Java) je násobí rozhodně větším koeficientem než ten dynamičtější (Objective C, Ruby).

Osobně považuji za dobře navržený objektový systém např. framework Cocoa. Sám jsem s tím dělal jen párkrát, ale dělalo se mi s tím opravdu velmi příjemně. Lidé, co jsem potkal a měli více příležitostí s tím pracovat, si to ale také velice chválili. Nebo třeba Pharo. Takže inspirace, jak se to dá dobře udělat, bych hledal tady. Když to porovnám třeba s Qt nebo .NET, tak mi to připadá mnohem elegantnější.
Cocoa je skvělý příklad dobrého návrhu, bohužel se s tím člověk ale setká jen na macOS (gnustep je opruz) a navíc to chce ObjC, protože verze pro Swift (hlavně na Linuxu) je galimatyáš. Qt vskutku moc elegantní není (jako nic v C++). .NET bych neviděl tak černě, to je jen běhové prostředí (a jeho základní knihovna není moc OOP). Pro lidi znalé céčka bych doporučil ještě CoreFoundation, to je objektové a multiplatformní (a ukazuje, jak psát objektově v C).
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: jpu 04. 04. 2017, 15:28:00
uprednostnujete vyuzivanie switch-case, alebo polymorfizmu?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: YF 04. 04. 2017, 15:28:13
Mna by skor zaujimala jedna vec, ze ako viete posudit, ci to, co mate naprogramovane, je dobre, splna OOP alebo sa to aspon k OOP priblizuje. Vedel by niekto popr. odporucit nejaku knizku o OOP?

To je těžké. Jeden nějakou doporučí a další ji zkritizují. Mně je třeba blízký ten přístup jaký má Alan Kay, u nás, co by autory literatury, reprezentovaný zejména pány Čadou a Merunkou.

Jestli je to dobře naprogramované, nebo raději bych použil slovo navržené... to se pozná podle toho, jestli při přidávání nebo úpravě nějaké funkcionality uvažuješ o té funkcionalitě, nebo většinu času zabere dumání, jak k sakru tu prkotinu do toho nacpat, aniž by se to celé muselo překopat nebo aniž by to byla nějaká prasárna. S tím druhým jsem se setkal u většiny projektů v C++, C# nebo Javě.
OOP má obvykle jednu nepříjemnou vlastnost, totiž tu, že násobí jakékoli nešikovnosti, vzniklé v době návrhu architektury. A řekl bych, že ten statičtější přístup (C++, Java) je násobí rozhodně větším koeficientem než ten dynamičtější (Objective C, Ruby).

Osobně považuji za dobře navržený objektový systém např. framework Cocoa. Sám jsem s tím dělal jen párkrát, ale dělalo se mi s tím opravdu velmi příjemně. Lidé, co jsem potkal a měli více příležitostí s tím pracovat, si to ale také velice chválili. Nebo třeba Pharo. Takže inspirace, jak se to dá dobře udělat, bych hledal tady. Když to porovnám třeba s Qt nebo .NET, tak mi to připadá mnohem elegantnější.
Cocoa je skvělý příklad dobrého návrhu, bohužel se s tím člověk ale setká jen na macOS (gnustep je opruz) a navíc to chce ObjC, protože verze pro Swift (hlavně na Linuxu) je galimatyáš. Qt vskutku moc elegantní není (jako nic v C++). .NET bych neviděl tak černě, to je jen běhové prostředí (a jeho základní knihovna není moc OOP). Pro lidi znalé céčka bych doporučil ještě CoreFoundation, to je objektové a multiplatformní (a ukazuje, jak psát objektově v C).

zboj - co z c++ knihoven (navrh / kod / api) stoji z tohodle pohledu za prostudovani? QT se mi docela libi z hlediska API ... je to pragmaticky - ty templaty pod tim - v tom sem se zatim raci nevrtal ... boost uz je horsi a vubec proste .... v c++ snad ani hezkej design delat nejde ne?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 04. 04. 2017, 15:37:32
Mna by skor zaujimala jedna vec, ze ako viete posudit, ci to, co mate naprogramovane, je dobre, splna OOP alebo sa to aspon k OOP priblizuje. Vedel by niekto popr. odporucit nejaku knizku o OOP?

To je těžké. Jeden nějakou doporučí a další ji zkritizují. Mně je třeba blízký ten přístup jaký má Alan Kay, u nás, co by autory literatury, reprezentovaný zejména pány Čadou a Merunkou.

Jestli je to dobře naprogramované, nebo raději bych použil slovo navržené... to se pozná podle toho, jestli při přidávání nebo úpravě nějaké funkcionality uvažuješ o té funkcionalitě, nebo většinu času zabere dumání, jak k sakru tu prkotinu do toho nacpat, aniž by se to celé muselo překopat nebo aniž by to byla nějaká prasárna. S tím druhým jsem se setkal u většiny projektů v C++, C# nebo Javě.
OOP má obvykle jednu nepříjemnou vlastnost, totiž tu, že násobí jakékoli nešikovnosti, vzniklé v době návrhu architektury. A řekl bych, že ten statičtější přístup (C++, Java) je násobí rozhodně větším koeficientem než ten dynamičtější (Objective C, Ruby).

Osobně považuji za dobře navržený objektový systém např. framework Cocoa. Sám jsem s tím dělal jen párkrát, ale dělalo se mi s tím opravdu velmi příjemně. Lidé, co jsem potkal a měli více příležitostí s tím pracovat, si to ale také velice chválili. Nebo třeba Pharo. Takže inspirace, jak se to dá dobře udělat, bych hledal tady. Když to porovnám třeba s Qt nebo .NET, tak mi to připadá mnohem elegantnější.
Cocoa je skvělý příklad dobrého návrhu, bohužel se s tím člověk ale setká jen na macOS (gnustep je opruz) a navíc to chce ObjC, protože verze pro Swift (hlavně na Linuxu) je galimatyáš. Qt vskutku moc elegantní není (jako nic v C++). .NET bych neviděl tak černě, to je jen běhové prostředí (a jeho základní knihovna není moc OOP). Pro lidi znalé céčka bych doporučil ještě CoreFoundation, to je objektové a multiplatformní (a ukazuje, jak psát objektově v C).

zboj - co z c++ knihoven (navrh / kod / api) stoji z tohodle pohledu za prostudovani? QT se mi docela libi z hlediska API ... je to pragmaticky - ty templaty pod tim - v tom sem se zatim raci nevrtal ... boost uz je horsi a vubec proste .... v c++ snad ani hezkej design delat nejde ne?
Jo, to píšu, v C++ to moc elegantně vůbec nejde, ovšem to je trochu subjektivní, "krása" kódu nijak objektivně hodnotit nejde. K hlubšímu zkoumání bych asi doporučil jen STL (a potažmo boost), to je idiomatický kód v C++. A pak možná základní (obecné) třídy clangu, tam je několik velmi hezkých vychytávek ohledně dynamického volání.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: YF 04. 04. 2017, 15:45:16
Mna by skor zaujimala jedna vec, ze ako viete posudit, ci to, co mate naprogramovane, je dobre, splna OOP alebo sa to aspon k OOP priblizuje. Vedel by niekto popr. odporucit nejaku knizku o OOP?

To je těžké. Jeden nějakou doporučí a další ji zkritizují. Mně je třeba blízký ten přístup jaký má Alan Kay, u nás, co by autory literatury, reprezentovaný zejména pány Čadou a Merunkou.

Jestli je to dobře naprogramované, nebo raději bych použil slovo navržené... to se pozná podle toho, jestli při přidávání nebo úpravě nějaké funkcionality uvažuješ o té funkcionalitě, nebo většinu času zabere dumání, jak k sakru tu prkotinu do toho nacpat, aniž by se to celé muselo překopat nebo aniž by to byla nějaká prasárna. S tím druhým jsem se setkal u většiny projektů v C++, C# nebo Javě.
OOP má obvykle jednu nepříjemnou vlastnost, totiž tu, že násobí jakékoli nešikovnosti, vzniklé v době návrhu architektury. A řekl bych, že ten statičtější přístup (C++, Java) je násobí rozhodně větším koeficientem než ten dynamičtější (Objective C, Ruby).

Osobně považuji za dobře navržený objektový systém např. framework Cocoa. Sám jsem s tím dělal jen párkrát, ale dělalo se mi s tím opravdu velmi příjemně. Lidé, co jsem potkal a měli více příležitostí s tím pracovat, si to ale také velice chválili. Nebo třeba Pharo. Takže inspirace, jak se to dá dobře udělat, bych hledal tady. Když to porovnám třeba s Qt nebo .NET, tak mi to připadá mnohem elegantnější.
Cocoa je skvělý příklad dobrého návrhu, bohužel se s tím člověk ale setká jen na macOS (gnustep je opruz) a navíc to chce ObjC, protože verze pro Swift (hlavně na Linuxu) je galimatyáš. Qt vskutku moc elegantní není (jako nic v C++). .NET bych neviděl tak černě, to je jen běhové prostředí (a jeho základní knihovna není moc OOP). Pro lidi znalé céčka bych doporučil ještě CoreFoundation, to je objektové a multiplatformní (a ukazuje, jak psát objektově v C).

zboj - co z c++ knihoven (navrh / kod / api) stoji z tohodle pohledu za prostudovani? QT se mi docela libi z hlediska API ... je to pragmaticky - ty templaty pod tim - v tom sem se zatim raci nevrtal ... boost uz je horsi a vubec proste .... v c++ snad ani hezkej design delat nejde ne?
Jo, to píšu, v C++ to moc elegantně vůbec nejde, ovšem to je trochu subjektivní, "krása" kódu nijak objektivně hodnotit nejde. K hlubšímu zkoumání bych asi doporučil jen STL (a potažmo boost), to je idiomatický kód v C++. A pak možná základní (obecné) třídy clangu, tam je několik velmi hezkých vychytávek ohledně dynamického volání.
kk - mrknu - dik
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 04. 04. 2017, 15:49:53
uprednostnujete vyuzivanie switch-case, alebo polymorfizmu?

Polymorfismus. Je mnohem jednodušší na údržbu.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: zboj 04. 04. 2017, 15:50:12
Mna by skor zaujimala jedna vec, ze ako viete posudit, ci to, co mate naprogramovane, je dobre, splna OOP alebo sa to aspon k OOP priblizuje. Vedel by niekto popr. odporucit nejaku knizku o OOP?

To je těžké. Jeden nějakou doporučí a další ji zkritizují. Mně je třeba blízký ten přístup jaký má Alan Kay, u nás, co by autory literatury, reprezentovaný zejména pány Čadou a Merunkou.

Jestli je to dobře naprogramované, nebo raději bych použil slovo navržené... to se pozná podle toho, jestli při přidávání nebo úpravě nějaké funkcionality uvažuješ o té funkcionalitě, nebo většinu času zabere dumání, jak k sakru tu prkotinu do toho nacpat, aniž by se to celé muselo překopat nebo aniž by to byla nějaká prasárna. S tím druhým jsem se setkal u většiny projektů v C++, C# nebo Javě.
OOP má obvykle jednu nepříjemnou vlastnost, totiž tu, že násobí jakékoli nešikovnosti, vzniklé v době návrhu architektury. A řekl bych, že ten statičtější přístup (C++, Java) je násobí rozhodně větším koeficientem než ten dynamičtější (Objective C, Ruby).

Osobně považuji za dobře navržený objektový systém např. framework Cocoa. Sám jsem s tím dělal jen párkrát, ale dělalo se mi s tím opravdu velmi příjemně. Lidé, co jsem potkal a měli více příležitostí s tím pracovat, si to ale také velice chválili. Nebo třeba Pharo. Takže inspirace, jak se to dá dobře udělat, bych hledal tady. Když to porovnám třeba s Qt nebo .NET, tak mi to připadá mnohem elegantnější.
Cocoa je skvělý příklad dobrého návrhu, bohužel se s tím člověk ale setká jen na macOS (gnustep je opruz) a navíc to chce ObjC, protože verze pro Swift (hlavně na Linuxu) je galimatyáš. Qt vskutku moc elegantní není (jako nic v C++). .NET bych neviděl tak černě, to je jen běhové prostředí (a jeho základní knihovna není moc OOP). Pro lidi znalé céčka bych doporučil ještě CoreFoundation, to je objektové a multiplatformní (a ukazuje, jak psát objektově v C).

zboj - co z c++ knihoven (navrh / kod / api) stoji z tohodle pohledu za prostudovani? QT se mi docela libi z hlediska API ... je to pragmaticky - ty templaty pod tim - v tom sem se zatim raci nevrtal ... boost uz je horsi a vubec proste .... v c++ snad ani hezkej design delat nejde ne?
Jo, to píšu, v C++ to moc elegantně vůbec nejde, ovšem to je trochu subjektivní, "krása" kódu nijak objektivně hodnotit nejde. K hlubšímu zkoumání bych asi doporučil jen STL (a potažmo boost), to je idiomatický kód v C++. A pak možná základní (obecné) třídy clangu, tam je několik velmi hezkých vychytávek ohledně dynamického volání.
kk - mrknu - dik
Není zač. Jinak k tomuto bych doporučil spíše publikace Suttera a Meyerse, já přestal trendy v C++ podrobně sledovat někde u C++11 a teď už skoro máme C++17, takže je možné, že něco opravdu dobrého a doporučeníhodného mi uniklo.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gll 04. 04. 2017, 17:06:02
A k cemu ze to potrebujes ty sideefekty? Vzdyt by v principu to same slo bez pomocnych promenych a bez vedlejsich efektu prostym zretezenim volani nebo nejakou variaci na unixovou rouru...

je to sekvenční kód. Mohu ho krokovat v debuggeru.

Možná se dá krokovat, což nepovažuji za významnou výhodu, ale s testovatelností to bude asi trochu horší.

Testovatelnost je není problém. Side efekty jdou uzavřít dovnitř funkce. Právě díky dynamickému scopování.

Kód: [Vybrat]
use strict;
use Test;


sub modify_line {
    my ($param) = @_;
    local $_ = $_ if defined wantarray;
    $_ = $param if $param;
    chomp;
    tr/ /_/;
    s/.*\.txt$/$&.old\n/;
    $_;
}

BEGIN {plan tests => 5}


$_ = "original value";
ok(modify_line "hello.txt", "hello.txt.old\n");
ok($_, "original value"); # $_ unchanged
$_ = "hello.txt";
ok(modify_line, "hello.txt.old\n");
modify_line;
ok($_ , "hello.txt.old\n");
modify_line "hello.txt";
ok($_, "hello.txt.old\n");

funkce modify line funguje se side efektem, pouze pukud po ní volající nechce žádnou návratovou hodnotu. V tom případě uloží výsledek do proměnné $_.

Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: jpu 05. 04. 2017, 11:07:23
uprednostnujete vyuzivanie switch-case, alebo polymorfizmu?

Polymorfismus. Je mnohem jednodušší na údržbu.
A co vyuzitie Dictionary? To nepouzivas?
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 05. 04. 2017, 11:32:33
uprednostnujete vyuzivanie switch-case, alebo polymorfizmu?

Polymorfismus. Je mnohem jednodušší na údržbu.
A co vyuzitie Dictionary? To nepouzivas?

Slovníky a seznamy používám, ale ty nemají se switchem nic společného. To spíš s tím polymorfismem.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gll 05. 04. 2017, 11:42:00
Slovníky a seznamy používám, ale ty nemají se switchem nic společného. To spíš s tím polymorfismem.

slovník hodnota => akce má se switchem společného hodně.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 05. 04. 2017, 12:27:01
Slovníky a seznamy používám, ale ty nemají se switchem nic společného. To spíš s tím polymorfismem.

slovník hodnota => akce má se switchem společného hodně.

Kde vidíš ten switch? Samozřejmě je uvnitř nějak implementován, ale ztratí se přece v syntaktickém cukru a nepíše se.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: jpu 05. 04. 2017, 12:52:28
da sa to aj pomocou slovnikov implementovat. Key predstavuje napr. hodnotu enumu a Value predstavuje akciu, aka sa ma vykonat.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 05. 04. 2017, 14:49:36
da sa to aj pomocou slovnikov implementovat. Key predstavuje napr. hodnotu enumu a Value predstavuje akciu, aka sa ma vykonat.

Když už se bavíme o OOP, tak ve Value je samozřejmě objekt.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gll 05. 04. 2017, 15:19:36
da sa to aj pomocou slovnikov implementovat. Key predstavuje napr. hodnotu enumu a Value predstavuje akciu, aka sa ma vykonat.

Když už se bavíme o OOP, tak ve Value je samozřejmě objekt.

nebo ten slovník můžeš považovat za objekt, když už potřebuješ mít objekty všude. On totiž objekt není nic jiného než slovník typu nazev_metody => akce.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 05. 04. 2017, 15:47:36
da sa to aj pomocou slovnikov implementovat. Key predstavuje napr. hodnotu enumu a Value predstavuje akciu, aka sa ma vykonat.

Když už se bavíme o OOP, tak ve Value je samozřejmě objekt.

nebo ten slovník můžeš považovat za objekt, když už potřebuješ mít objekty všude. On totiž objekt není nic jiného než slovník typu nazev_metody => akce.

Objekt také obsahuje atributy, které jsou pro jeho smysl zásadní. Objekty bez atributů smysl nemají. Podobně nemají smysl ani objekty bez metod - a to jsem jich už viděl hodně, je to děsný nešvar.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: gll 05. 04. 2017, 16:07:24
Objekt také obsahuje atributy, které jsou pro jeho smysl zásadní. Objekty bez atributů smysl nemají. Podobně nemají smysl ani objekty bez metod - a to jsem jich už viděl hodně, je to děsný nešvar.

Nešvar je psát zbytečný kód navíc jen abych dodržel zásady nějakého paradigmatu.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 05. 04. 2017, 16:18:39
Objekt také obsahuje atributy, které jsou pro jeho smysl zásadní. Objekty bez atributů smysl nemají. Podobně nemají smysl ani objekty bez metod - a to jsem jich už viděl hodně, je to děsný nešvar.

Nešvar je psát zbytečný kód navíc jen abych dodržel zásady nějakého paradigmatu.

No jasně, mezi ně patří ty hromady veřejných *etterů, které ve třídách nemají co pohledávat. Když je odstraníš, často zbude jen hromada privátních (v horším případě protected) atributů a žádná metoda. S takovými objekty se pak nedá ani pracovat, protože nic neumí.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Tuxik 05. 04. 2017, 19:51:13
No jasně, mezi ně patří ty hromady veřejných *etterů, které ve třídách nemají co pohledávat. Když je odstraníš, často zbude jen hromada privátních (v horším případě protected) atributů a žádná metoda. S takovými objekty se pak nedá ani pracovat, protože nic neumí.
To ale ničemu nevadí. Prostě OOP je in, tak ho tam je třeba narvat za každou cenu. Tak je to správné a tak to má být. :D
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Polymath 05. 04. 2017, 20:37:32
No jasně, mezi ně patří ty hromady veřejných *etterů, které ve třídách nemají co pohledávat. Když je odstraníš, často zbude jen hromada privátních (v horším případě protected) atributů a žádná metoda. S takovými objekty se pak nedá ani pracovat, protože nic neumí.
To ale ničemu nevadí. Prostě OOP je in, tak ho tam je třeba narvat za každou cenu. Tak je to správné a tak to má být. :D
OOP je římskými číslicemi dnešní doby...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 05. 04. 2017, 22:47:10
No jasně, mezi ně patří ty hromady veřejných *etterů, které ve třídách nemají co pohledávat. Když je odstraníš, často zbude jen hromada privátních (v horším případě protected) atributů a žádná metoda. S takovými objekty se pak nedá ani pracovat, protože nic neumí.
To ale ničemu nevadí. Prostě OOP je in, tak ho tam je třeba narvat za každou cenu. Tak je to správné a tak to má být. :D
OOP je římskými číslicemi dnešní doby...

Každé paradigma má své výhody i nevýhody a každé z nich má své uplatnění. Teď je sice hype funkcionální programování (podobně jako před 20-30 lety), ale například na deklarativní se docela zapomíná. Zřejmě proto, že nemá chybu :)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Lemming 05. 04. 2017, 23:08:46
No jasně, mezi ně patří ty hromady veřejných *etterů, které ve třídách nemají co pohledávat. Když je odstraníš, často zbude jen hromada privátních (v horším případě protected) atributů a žádná metoda. S takovými objekty se pak nedá ani pracovat, protože nic neumí.

Na podobných diskusích mě hrozně baví situace kdy někdo dělá hroznýho kinga a pak plácne něco z čeho je jasný, že je to jen kecka s minimem reálných zkušeností z oblasti o které tak velkohubě rozkládá. Třeba když debatuje o OOP a netuší, proč se používají "hloupé" třídy, zapouzdřené proměnné a "*ettery".
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 05. 04. 2017, 23:23:19
No jasně, mezi ně patří ty hromady veřejných *etterů, které ve třídách nemají co pohledávat. Když je odstraníš, často zbude jen hromada privátních (v horším případě protected) atributů a žádná metoda. S takovými objekty se pak nedá ani pracovat, protože nic neumí.

Na podobných diskusích mě hrozně baví situace kdy někdo dělá hroznýho kinga a pak plácne něco z čeho je jasný, že je to jen kecka s minimem reálných zkušeností z oblasti o které tak velkohubě rozkládá. Třeba když debatuje o OOP a netuší, proč se používají "hloupé" třídy, zapouzdřené proměnné a "*ettery".

Třeba na to někdy přijdeš, v čem spočívá to zapouzdření. Nech si poradit od Démétér.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Polymath 06. 04. 2017, 01:35:49
No jasně, mezi ně patří ty hromady veřejných *etterů, které ve třídách nemají co pohledávat. Když je odstraníš, často zbude jen hromada privátních (v horším případě protected) atributů a žádná metoda. S takovými objekty se pak nedá ani pracovat, protože nic neumí.
To ale ničemu nevadí. Prostě OOP je in, tak ho tam je třeba narvat za každou cenu. Tak je to správné a tak to má být. :D
OOP je římskými číslicemi dnešní doby...

Každé paradigma má své výhody i nevýhody a každé z nich má své uplatnění. Teď je sice hype funkcionální programování (podobně jako před 20-30 lety), ale například na deklarativní se docela zapomíná. Zřejmě proto, že nemá chybu :)
FP je deklarativní.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 06. 04. 2017, 06:59:06
Každé paradigma má své výhody i nevýhody a každé z nich má své uplatnění. Teď je sice hype funkcionální programování (podobně jako před 20-30 lety), ale například na deklarativní se docela zapomíná. Zřejmě proto, že nemá chybu :)
FP je deklarativní.

Ovšem ne každé deklarativní programování je funkcionální.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: -j- 06. 04. 2017, 07:56:48
Arafat je pro OOP úplnej základ.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 06. 04. 2017, 14:35:58
Arafat je pro OOP úplnej základ.

Byl...
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: jpu 11. 04. 2017, 14:52:46
ako by ste premenili toto do OOP pomocou polymorfizmu:
Kód: [Vybrat]
public string Deregister(ServerReason reason)
        {
            switch (reason)
            {
                case ServerReason.Operator:
                    Navigate(typeof(LoginPage1), true);
                    return string.Format(LocalizationHelper.GetLocalizedString("OP"));
                case ServerReason.DifferentLocation:
                    Navigate(typeof(LoginPage1), true);
                    return LocalizationHelper.GetLocalizedString("AnotherLocation");
                case ServerReason.LimitReached:
                case ServerReason.SupportedFeaturesLimitReached:
                    Navigate(typeof(LoginPage1), true);
                    return LocalizationHelper.GetLocalizedString("MaxUsers");
                case ServerReason.TrialExpired:
                    Navigate(typeof(LoginPage1), true);
                    return LocalizationHelper.GetLocalizedString("UserTrial");
                default:
                    return string.Format(LocalizationHelper.GetLocalizedString("Disconnected"));
            }
        }


Dakujem za napady
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: dustin 11. 04. 2017, 15:11:58
Ty jednotlivé reasons by nebyla pouhá čísla, ale enumy s metodami navigate() a toString()/getDescription(). Očividně je ten reason nejen číslo, ale nese si i nějaké znalosti/dovednosti (konkrétní postupy v navigate(), nějak se v UI jmenuje, atd.). Tipuju si, že při likvidaci takových casů přes reasons rozházených různě po kódu by se nakonec ukázalo, že  reasons toho umí ještě víc -> další metody.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 11. 04. 2017, 15:51:29
ako by ste premenili toto do OOP pomocou polymorfizmu:
Dakujem za napady

Zkus se podívat, jak se v Javě používá enum.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: balki 11. 04. 2017, 21:01:02
ako by ste premenili toto do OOP pomocou polymorfizmu:
Kód: [Vybrat]
public string Deregister(ServerReason reason)
        {
            switch (reason)
            {
                case ServerReason.Operator:
                    Navigate(typeof(LoginPage1), true);
                    return string.Format(LocalizationHelper.GetLocalizedString("OP"));
                case ServerReason.DifferentLocation:
                    Navigate(typeof(LoginPage1), true);
                    return LocalizationHelper.GetLocalizedString("AnotherLocation");
                case ServerReason.LimitReached:
                case ServerReason.SupportedFeaturesLimitReached:
                    Navigate(typeof(LoginPage1), true);
                    return LocalizationHelper.GetLocalizedString("MaxUsers");
                case ServerReason.TrialExpired:
                    Navigate(typeof(LoginPage1), true);
                    return LocalizationHelper.GetLocalizedString("UserTrial");
                default:
                    return string.Format(LocalizationHelper.GetLocalizedString("Disconnected"));
            }
        }


Dakujem za napady

Ak to velmi treba objektovo, tak vzor visitor. Kazdy potomok triedy Serverreason by mal v sebe metodu deregisterVisit (meno som zvolil debilne, ale nazorne) a v nej prislusny kod, co treba vykonat.

V metode deregister, ktoru ste napisali vyssie by sa uz len volala metoda deregisterVisit.

Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: jpu 11. 04. 2017, 21:05:29
aby som este ozrejmil. deregister je event, ktory je vyvolany na zaklade volania metody z kniznice od tretej strany
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: balki 11. 04. 2017, 22:22:10
aby som este ozrejmil. deregister je event, ktory je vyvolany na zaklade volania metody z kniznice od tretej strany

Tak potom, ak aj tak silou-mocou to musi byt objektovo, tak pre kazdy Serverreason si vytvorit objekt s danou logikou a spolocnou metodou "tralala". Ulozit tieto objekty  do hashmapy a indexovat hashmapu pomocou ServerReason.

Pri zavolani vytiahnut objekt z hashmapy a zavolat patricnu metodu "tralala".
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: jpu 11. 04. 2017, 22:36:37
nehovorim, ze to musi byt silou-mocou OOP, len mi prislo na mysel spytat sa, ako by ste to zoptimalizovali do OOP podoby.
dakujem za navrhy :)
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: dustin 11. 04. 2017, 22:46:25
Pokud je to volání jen na jednom místě a ty ServerReasons nemají v tvém kódu jiné využití, pak nějak nechápu, k čemu by bylo předělání do objektů užitečné.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: Kit 11. 04. 2017, 23:22:06
nehovorim, ze to musi byt silou-mocou OOP, len mi prislo na mysel spytat sa, ako by ste to zoptimalizovali do OOP podoby.
dakujem za navrhy :)

Optimalizovat pouze část aplikace do OOP bez objektových vazeb na zbývající komponenty je jen plýtváním časem.

Volání by mělo vypadat asi takto:
Kód: [Vybrat]
reason.deregister();nezávisle na třídě, ze které je vytvořena instance reason. Každá taková třída musí tedy implementovat rozhraní, které obsahuje metodu deregister(). Dle rozpisu to budou třídy Operator, DifferentLocation, LimitReached, SupportedFeaturesLimitReached, TrialExpired apod. Samozřejmě se předpokládá, že tyto třídy budou implementovat i další metody takového rozhraní a z aplikace tak zmizí i další switche s objektem reason. Třídu ServerReason předěláš dle vzoru Factory.
Název: Re:Zdroje k rozvoji OOP myšlení
Přispěvatel: BoneFlute 12. 04. 2017, 16:29:11
nehovorim, ze to musi byt silou-mocou OOP, len mi prislo na mysel spytat sa, ako by ste to zoptimalizovali do OOP podoby.
dakujem za navrhy :)

No, při zvažování jak to zoptimalizovat záleží na dalších aspektech, ne jen zda to jde. Něky převést to do OOP může být neoptimální.

Třeba já bych zvažoval, zda chci, aby objekty: Operator, DifferentLocation, LimitReached,... uměli zpracovat registraci a deregistraci. Dovedu si představit případ, kdy bych to považoval za nežádoucí a nechtěl bych, aby to znali.