Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: 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
-
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.
-
...
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)
-
Na rozvoj OOP se hodí Robert C. Martin a jeho kniha Clean Code.
-
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.
-
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.
-
"Refactoring: Improving the Design of Existing Code od M.fowlera" je podla mna tiez sucast povinnej jazdy, co sa tyka oop.
-
mrkni na "Head first design patterns", dá se stáhnout PDF
-
http://www.martinfowler.com/books/
-
...
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.
-
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í?
-
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.
-
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í?
-
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.
-
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ů.
-
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ší.
-
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.
-
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.
-
"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á.
-
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.
-
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í, ...
-
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í.
-
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.
-
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.
-
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ě.
-
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?
-
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:
class MyVector : public std::vector
Pokud se OOP učím, nechci takové věci řešit.
-
ono nic neni dokonale a taky na 100%.
-
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...
-
co tedy radis?
-
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...
-
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++. :)
-
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.
-
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é?
-
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:
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++.
-
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.
-
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á.
-
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?
-
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.
-
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.
-
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".
-
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.
-
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.
-
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...
-
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...
-
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++.
-
no pockat. srovnavat C++ a PHP to je teda katastrofa. Ne ne. To nedelejte.
-
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...
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"...
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... :)
-
no pockat. srovnavat C++ a PHP to je teda katastrofa. Ne ne. To nedelejte.
Srovnávám OOP v C++ vs. OOP v PHP.
-
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.
-
Tak na chvíli odlož C++, nainstaluj si Smalltalk a zkoušej si příklady.
Asi to bude nejlepší možnost.
-
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.
-
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.
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í.
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.
-
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.
-
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 .
-
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ů.
-
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í.
-
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).
-
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ý.
-
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.
-
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í
-
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 ;)
-
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.
-
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.
-
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.
-
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.
-
+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!
-
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.
-
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ý.
-
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á.
-
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?
-
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
-
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..
-
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.
-
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#
-
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?
-
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...
-
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ě.
-
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.
-
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.
-
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.
-
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?
-
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.
-
Uživatelé Windows by byly šťastnější, kdyby .NET neexistoval.
Chtěl jsi říct "uživatelky", ne? :)
-
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.
-
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.
-
Ja poufivam jedine swift. Uf pol roka :) Niefom zmija fom ftefan :) Fwift bude vfade.
-
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ší.
-
Ja poufivam jedine swift. Uf pol roka :) Niefom zmija fom ftefan :) Fwift bude vfade.
Co hulíš?
-
Ja poufivam jedine swift. Uf pol roka :) Niefom zmija fom ftefan :) Fwift bude vfade.
Co hulíš?
Ano :)
-
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š!
-
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.
-
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.
Řekl bych že Foundation byl větší kalibr, a nechytlo se to. Takže nás nevystrašíš.
.NET pojede jeste dal ;)
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?
-
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áš.
-
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
-
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 :).
-
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ší.
-
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.
-
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.
-
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ě.
-
Ano, webovky - intranet, informační systémy, evidence
Mohl byste mi prosím napsat na bordel007(na)centrum(v)cz? Děkuji.
-
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# š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!
-
radsi delat v necem poradnem, nez v neporadnem jako Qt ;) vim, zazil jsem. ne dekuji, neprosim.
-
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.
-
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?
-
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
-
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.
-
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
-
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
-
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)
-
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.
-
AI a big data muzes delat taky na windowsu.
A kdo to dělá? (jen tvrdá data prosím)
-
AI a big data muzes delat taky na windowsu.
A kdo to dělá? (jen tvrdá data prosím)
GoodAI
-
AI a big data muzes delat taky na windowsu.
A kdo to dělá? (jen tvrdá data prosím)
treba Hortonworks, iTrend?
-
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.
-
MS ma s nima podpisane partnerstvi, tak ja dal fakty, ktere chtel Mirek.
-
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á.
-
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.
-
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.
-
C# umí doesNotUnderstand
??? Jak?
-
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.
-
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.
-
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.
-
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.
-
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?
-
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...
-
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...
-
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 ;)
-
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á).
-
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)
-
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.
-
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í.
-
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í?
-
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.
-
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.
-
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/
-
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áší.
-
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 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.
-
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...
-
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.
-
Co si myslite o vyrokoch tychto ludi na adresu OOP?
-
Co si myslite o vyrokoch tychto ludi na adresu OOP?
Myslím si, že (na rozdíl od nekrofilů) přemýšlí a diskutují.
-
Co si myslite o vyrokoch tychto ludi na adresu OOP?
Můj názor je:
-
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ého :D Otec bude, ale nikdo to moc nepoužívá a tuším, že bude nějaký důvod...
-
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.
-
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.
-
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ě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...
-
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
-
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.
-
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.
-
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...
-
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ě.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
Přesně tak, nebyl to dobrý koncept. Zkusil to a nevyšlo to.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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?
-
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.
-
Na nekolik radek mas trebas klasickou javabeanu. Ve Scale (Haskellu...) mas podobne konstrukce vicemene zadarmo.
A to jsi ani nemusel zminovat deriving..
-
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 ;)
-
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)
-
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...
-
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...
-
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á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
-
Je to odborník, to se pozná! ;D
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.
-
Je to odborník, to se pozná! ;D
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.
-
Ne každý chce dělat s amatéry, kteří neumí programovat. Někdo chce prostě víc.
-
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.
-
Jasný, PHP je totiž jeden z nejlepších jazyků všech dob a jen pro ty nejlepší 8)
-
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í.
-
Jistě, proto je tak populární ;)
-
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
-
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ší.
-
Já ti nevím - z doktorů mám strach ...
-
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í).
-
Já ti nevím - z doktorů mám strach ...
Tak zkus zmíněné Clojure, JVM tě určitě potěší.
-
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.
-
A kteří neumějí vyvíjet.
-
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.
-
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.
-
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á.
-
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í.
-
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.
-
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í".
-
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.
-
- 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, ...
-
- 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.
-
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í.
-
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.
-
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.
-
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.
-
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...
-
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.
-
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...
-
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`)
-
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.
-
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.
-
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í.
-
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.
-
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:
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.
-
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.
-
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ů.
-
Pokud mne mel ten kus kodu presvedcit o skvelosti sideefektu, tak se mu to nepodarilo...
-
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.
-
getValueButLastCompilerVersionHasBugSoWeNeedAddTwoToResult()
-
getValueButLastCompilerVersionHasBugSoWeNeedAddTwoToResult()
To má být vtip? Obvykle si vystačím s jedním či maximálně dvěma slovy.
-
A kam dáš dočasné detaily? Přece bys nepoužíval ohavné komentáře, které vše zničí :o
-
A kam dáš dočasné detaily? Přece bys nepoužíval ohavné komentáře, které vše zničí :o
Do proměnných.
-
A kam dáš dočasné detaily? Přece bys nepoužíval ohavné komentáře, které vše zničí :o
Do závorek.
-
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.
-
http://lucacardelli.name/TheoryOfObjects.html
-
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".
-
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.
-
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ů?
-
O tom nic nevím.
-
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:
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.
-
co je Java OOP? :D.
-
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:
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.
-
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:
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?
-
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ů.
-
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í.
-
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.
-
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.
-
... 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.
-
... 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.
-
... 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.
-
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!
-
... 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.
-
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 .
-
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.
-
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
-
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.
-
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 $_.
while($_ = <STDIN>) {
chomp $_;
$_ =~ tr/ /_/;
$_ =~ s/.*\.txt$/$&.old\n/;
print $_;
}
je ekvivalentní tomu původnímu.
-
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 :)
-
A Kit je javabumboy bez ega :)
A Polymath je imperativec a funkcionalista bez argumentů :)
-
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 $_.
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...
-
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 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.)
-
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ší.
-
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?
-
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
-
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/
-
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.
-
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ší.
-
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).
-
uprednostnujete vyuzivanie switch-case, alebo polymorfizmu?
-
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?
-
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í.
-
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
-
uprednostnujete vyuzivanie switch-case, alebo polymorfizmu?
Polymorfismus. Je mnohem jednodušší na údržbu.
-
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.
-
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í.
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é $_.
-
uprednostnujete vyuzivanie switch-case, alebo polymorfizmu?
Polymorfismus. Je mnohem jednodušší na údržbu.
A co vyuzitie Dictionary? To nepouzivas?
-
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.
-
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ě.
-
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.
-
da sa to aj pomocou slovnikov implementovat. Key predstavuje napr. hodnotu enumu a Value predstavuje akciu, aka sa ma vykonat.
-
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.
-
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.
-
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.
-
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.
-
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í.
-
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
-
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...
-
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 :)
-
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".
-
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.
-
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í.
-
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í.
-
Arafat je pro OOP úplnej základ.
-
Arafat je pro OOP úplnej základ.
Byl...
-
ako by ste premenili toto do OOP pomocou polymorfizmu:
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
-
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.
-
ako by ste premenili toto do OOP pomocou polymorfizmu:
Dakujem za napady
Zkus se podívat, jak se v Javě používá enum.
-
ako by ste premenili toto do OOP pomocou polymorfizmu:
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.
-
aby som este ozrejmil. deregister je event, ktory je vyvolany na zaklade volania metody z kniznice od tretej strany
-
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".
-
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 :)
-
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é.
-
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:
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.
-
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.