Jste zastánci OOP programování?

[Logik]

Většina VM kritiky IMHO spíše souvisí s tím, že dost lidí chápe OOP jinak, než co to IMHO ve skutečnosti je.
1) Jak to souvisí s OOP? Kdyby teď letělo procedurální programování, tak budou lidi houfně generovat procedury na přístup k datům....
2) Pokud to někdo takhle dělá, tak to není OOP - copak je položka formuláře samostatná entita?
3) Fór je v tom, že málokdy člověk předem ví, co bude. Navíc to, co popisuješ je v přímém rozporu s myšlenkou OOP, protože se nemá přistupovat k hromadě vlastností objektu, ale zavolat jeho jedna metoda, která provede co je třeba.
4) Když je program navrženej blbě, tak je to proto, že ho navrhoval blb :-) Není to teda vina použité metody, ale toho, kdo ji používá. Naopak dobrý OOP návrh je imho nejčitelnější, protože každá entita v programu má definovanou svoji zodpovědnost a úlohu, takže nikde nedochází k sideefektům, k dělání pěti věcí najednou a podobným zhůvěřilostem, které čitelnost snižují nejvíce.

[Reklama]

[ondra.novacisko.cz]

Neduh číslo 1: automatické generování tříd z datového modelu s předgenerovanými metodami.
Vznikne džungle tříd, které nedělají vůbec nic, stovky zdrojových souborů, které by při trošce inteligence šly nahradit jedním univerzálním rozhraním pro přístup k datům (kdo tvrdí že to nejde kvůli typové kontrole, tak nejspíše nikdy neslyšel o validačních funkcích).

Většinou je v pozadí ještě něco jiného a to znovupoužitelnost. Některé třídy vznikají jen proto, že jedna velká třída by implementovala zbytečně moc operací, pak se problém rozdělí do mnoha malých tříd, které mohou fungovat samostatně.  Dám příklad. Lze udělat správce přístupu tak, že budu mít skupiny uživatelů a ke každé skupině přístupová práva. Mohu na to napsat jednu třídu. Ale taky to mohu napsat jako třídu přístupových práv, třídu skupiny uživatelů a třídu, která to spojuje dohromady. A stejně tak třídu přístupových práv lze dále dekomponovat na kolekci instancí třídy definující prostředek a jednotlivá práva. Těch tříd je tam pravda hodně, a některé budou hodně krátké, některé díky STL budou omezeny jen na nějaký typedef. Ale už budou hotové, připravené a jak platí jedno programátorské pravidlo, každá věc má být napsána v programu jen jednou.

Rozdělení na třídy neurčuje to, jak veliká ta třída má být, ale její logické začlenění do celého objektového návrhu. Řešit výkon v tomto případě nemá smysl, protože třeba překladače C++ (myslím teď třeba MS Visual C++) umí celkem dost obstojně optimalizovat, takže ve výsledném kódu třeba vůbec nějaké objekty nejsou vůbec patrné.

Hlavním smyslem OOP jazyka je čitelný zápis často abstraktních myšlenek, ne honba za výkonem. To má co nejvíc pořešit překladač (ano, uznávám, výjimečně se musí algoritmy přizpůsobovat specifikám dané platformy).

Neduh číslo 2: nadužívání objektů a tříd
.... Například pro formulář o 100 položkách nemá smysl vytvářet 100 různých objektů, které nedělají nic jiného než že zapouzdřují základní typy, komplikují a zpomalují manipulaci s nimi, a žerou paměť.

Pokud ovládací prvky nemají nějaké speciality, pak je to nesmysl. Třída vzniká tam, kde existuje odlišnost od existujících tříd. A to ještě s možností podědit existující třídu a dopsat jen tu odlišnost

Neduh číslo 3: gettery a settery na úplně všechno

Gettery a settery se tu řešili. Mnohem radši používám konfigurační třídy (struktury), které gettery a settery nemají. Konfigurační objekt pak nastavuje parametry nového objektu přes konstruktor a tím jsou vlastnosti zadané. Nadužívání getterů a setterů se mi samozřejmě taky nelíbí, ale jejich nepoužívání je také špatně. Je prostě se potřeba nad tím zamyslet, jaký vlastně ty gettery a settery mají mít smysl. Příliš velké množství getterů a setterů zpravidla ukazují na nešťastný návrh

Neduh číslo 4: špagetový kód
Nadměrné používání objektů a metod způsobuje, že většina metod jen předává své parametry jiným metodám a nedělá vůbec nic. Pro nalezení výkonné části musíte projít třeba deset úrovní. V takovém kódu se nedá vyznat a špatně se ladí.

Otázka je, chcete vůbec vidět výkonné části? OOP je práce s černými krabičkami. Pokud černé krabičce nevěříte, chápu, že se chcete dovnitř podívat... abyste zjistil, že je v ní další černá krabička (nebo krabičky). Bavme se ale o situaci, kdy máme černé krabičky, kterým věříme, pak bych tuto námitku považoval za irelevantní. Při práci v týmu, kdy každý programátor má na starost nějakou černou krabičku je výhodou i zodpovědnostní model, každá práce je oddělená a programátoři si nelezou do zelí. A pokud lezou... opět to je ukazatel nešťastného návrhu.

U OOP neřešte výkon. U některých jazyků to ani nechceme (Python, smalltalk), u některých to řeší dobrý překladač (C++, Java JITC)

[D.A. Tiger]

Neduh číslo 4: špagetový kód
Nadměrné používání objektů a metod způsobuje, že většina metod jen předává své parametry jiným metodám a nedělá vůbec nic. Pro nalezení výkonné části musíte projít třeba deset úrovní. V takovém kódu se nedá vyznat a špatně se ladí.

Nelze než nevzpomenout na tu tolik milovanou Javu....

[X]

Neduh číslo 4: špagetový kód
Nadměrné používání objektů a metod způsobuje, že většina metod jen předává své parametry jiným metodám a nedělá vůbec nic. Pro nalezení výkonné části musíte projít třeba deset úrovní. V takovém kódu se nedá vyznat a špatně se ladí.

Nelze než nevzpomenout na tu tolik milovanou Javu....

Ano, to skutečně nelze nevzpomenout. Java sice za tento problém OOP návrhu nemůže, ale naopak ho ve svých IDE pomáhá řešit - např. http://blogs.jetbrains.com/idea/2009/08/analyzing-dataflow-with-intellij-idea/

[Ivan]

Nejvíc mě ovšem dojímá kritika C++, že není objektový jazyk a jako příklad se uvádí Java, která je koncipována naprosto shodně jako C++. Smaltalkisté se vůbec rádi pouští do C++ a ty ostatní jazyky jako by přehlíželi. co si o tom myslíte? (ať flame začne v samostatném vlákně)

Je nutne si uvedomit na jakou platformu je dotaz smerovan. Jestli se bavis o programovani 16 bitovych mikroprocesoru, tak tam kvuli nedostatku pameti samozrejme jedine proceduralni jazyk C. Ale to asi neresis.

Bavis-li se o PC, tak tam uz aspon 15 let proceduralni jazyk nepatri (vyjma SQL). Duvod je jediny: Proceduralnim jazykem proste NELZE!!! programovat nektere situace a zaroven s nim NELZE programovat efektivne. Proceduralnim jazykem taky NELZE rozlisit data od logiky, coz je zakladem pro vicevrstve aplikace. Branit se OOP je jako chtit v roce 2010 jezdit z Bratislavy do Prahy na kravskem povoze. Dovede vas to tam, ale unavite se, bude vas bolet zadek, zmoknete u toho a hlavne vam to bude trvat milionkrat dele nez autem.

Ad C++ vs. Java)
C++ je opravdu desnej jazyk! Clovek v nem vice hleda zpusob jak problem vyresit, nez aby programoval funkcnost samotnou. Taky neni pravda, ze Java koncepcne vychazi z C++! Tobychom mohli prohlasit o SQL, ze vychazi z assembleru, protoze v nem lze zapsat pismenka a zavorky.

C# je momentalne nejmodernejsi a nejefektivnjsi jazyk na programovani. Jeho jedinou slabinou je multiplatformnost. Coz muze byt zasadni slabina.

V multiplatformnosti vede Java. Java ma jeste tu vyhodu, ze Javiste patri mezi nejlepe placene programatory. Duvod je ten, ze jde o rozsireny jazyk ale technicky zastaraly, takze kdyz chce nekdo vice zabavy, jde do C#, kdyz chce nekdo vice penez a nevadi mu reseni naprosto zbytecnych problemu v/s naprosto hnusnym grafickym prostredim, spatnym memory managementem, nevzhlednym zapisem kodu, s problemy Javovske prostredi rozchodit, tak jde do Javy. Nejvice pracovnich nabidek je na Javu a trva to jiz 10 let.

Mnohem efektivnejsi jazyk nez C/C++ a Java byl Delphi (potomek Pascalu), jenomze ten se bohuzel tolik nerozsiril, protoze programatori jsou divni lide, kteri si mysli, ze kdyz budou psat write-only kod (cti "zmateny, prekomplikovany, tj. necitelny") tak si o nich lide budou rikat, ze jsou vice coool. A tak kdo chtel byt cool, trapil se s C++. Delphi uz je dnes ale minulost a vetsina Delphistu presla na C#. C# vychazi z Delphi a z Javy. Vzdyt hlavni architekti C# jsou prave od Javy a od Borlandu (Delphi). Z obou svetu vzali to nejlepsi a spojili to do bezkonkurencne nejefektivnejsiho jazyka vsech dob (zatim) - C#.

Povsimnete si jednu vec! Cim vic modernejsi jazyk, tim objektovejsi. Proc asi?! Protoze objekty jsou efektivita!!! Efektivita ekonomicka, casova, efektivita pri ladeni, pri cteni a zapisu kodu. Efektivita a elegance pri reseni problemu. Efektivita pri kresleni UML diagramu. Zkuste si proceduralni apliakci zapsat do UML. Delphi byl objektovy jak by smet a aplikace se v nem psali nejrychleji, ale s prichodem C# je OOP proti Delphi jeste o nekolik levlu vykonnejsi.

Takze dnes lze uvazovat pouze o dvou jazycich - Java a C#. Jak uz jsem zminil, penize = Java, zabava = C#.

Pak jsou ruzne jine jazyky jako Python, J#, .... ale to jsou minoritni jazyky a hledat s v tom praci je problem. Sktipty taky resit nechci, to je prokleti IT. Bohuzel skripty jako HTML 5, JavaScript, PHP zas*raji tuhle IT planetu jejich neefektivitou, nachylnosti na chybovost a neladitelnosti. Skripty resit nebudem.

Pak jsou jazyky na specialni ukoly pro matematiky, fyziky, ... to je okrajova zalezitost.

No a pak jsou zastarale jazyky, jako Pascal, Foxpro, ABAP a pod. V tom se uz opravdu pouze udrzuji archaicke vykopavky, ale kdo ma to stesti, ze musi udrzovat takove aplikace, vydela si slusny balik. Ale je to opravdu o stesti.

GN!

[Reklama]

[D.A. Tiger]

[Ivan]

No, jste ukázkový příklad toho co jsem už tu jednou psal - totiž používání děla na komára. Nechápu kde jste přišel na to, že na moderních platformách nemá procedurální programování co dělat. Přijde mi to stejně geniální prohlášení asi jako tvrzení, že dneska jsou klasické vývojové diagramy o ničem, a mají se používat jen strukturogrami. tak jako některé principy a myšlenky mnohem lépe, přehledněji a jednodušeji vyjadřuje vývojový diagram, stejně tak nechápu proč nepoužívat procedurální programování, když to mnohem zjednodušší a zpřehlední konkrétní úlohu.  Přikladem budiž aplikace typu filtr, na něž stačí několik dobře napsaných funkcí. Navíc stejně se procedůrám nevyhnete, protože ve všech třech jayzcích, které jste zmínil (C++, Java, C#) je rozhraní objektů implementováno z velké části procedurálně.

Hlavní ( a z mého pohledu jedinou) výhodu kterou Java oproti C++ má, je její přenositelnost, což by mělo teoreticky znamenat, že jednou aplikaci napíšu a zkompiluji a potom ta stejná aplikace by měla běžet na všech podporovaných platformách. Jejími zásadními problémy je pomalost (virtual machine + gb) a onen "špagety kód", ke kterému tak rádi programátoři v Javě inkliminují (což je dalším argumentem proti kecům typu: "Vytvořily jsme super jazyk xxx, který budete používat, protože jsme v něm odstranily nebo schovaly všechny špatnosti jazyka yyy ". Pravda, s novím jazykem však přišli nové, nebo staronové nešvary). To je takz důvod proč se snažím Javovským aplikacím na desktopu vyhýbat (ono to bohužel v mém případě stoprocentně nejde, ale snad česem lidé trochu zmoudří...)

Kdysi jsem podobnému blábolu propadl taky - někdo někde plácl, že klasická makra nemají v C++ co dělat. Všichni jsme to jak idioti bez přemýšlení papouškovaly po něm. Dneska jsem o něco moudřejší....

[Ivan]

Nechápu kde jste přišel na to, že na moderních platformách nemá procedurální programování co dělat. ... nechápu proč nepoužívat procedurální programování, když to mnohem zjednodušší a zpřehlední konkrétní úlohu.  Přikladem budiž aplikace typu filtr, na něž stačí několik dobře napsaných funkcí.

Tak predpokladam, ze vyznam puvodniho dotazu je dotaz na zpusob programovani ucelenych aplikaci a ne jen jedne konkretni minimalisticke ulohy, ktera sama o sobe nema vubec zadny smysl. Filtr sam o sobe nema smysl bez vyuziti v aplikaci. A psat dnes aplikaci, ktera ma aspon jeden formular a jedno tlacitko proceduralne je nesmysl, nebot musite reagovat minimalne na nekolik zakladnich udalosti a to snad nikdo uz nechce psat proceduralni metodou. Nikdo se nehada, ze v OOP programu, ktery je tvoren z trid neni misto pro procedury. Procedury jsou zakladem objektu, takze za "proceduralni" se chape stavba progrmu jako celku a ne jedne metody.

Hlavní ( a z mého pohledu jedinou) výhodu kterou Java oproti C++ má, je její přenositelnost, což by mělo teoreticky znamenat, že jednou aplikaci napíšu a zkompiluji a potom ta stejná aplikace by měla běžet na všech podporovaných platformách.

Tech vyhod meci C++ na jedne strane a Javou a C# na strane druhe je mnohem mnohem vic, ale je to imho OFF TOPIC. Nejzasadnejsi vyhoda je ovsem produktivita. Clovek v C# napise proste aplikaci rychlejsi, znacne rychleji, nez v C++. Navic nemusi resit spoustu problemu s vynimkami, s pameti, ...., kterym se v C++ nevyhne.

Jejími zásadními problémy je pomalost (virtual machine + gb) a onen "špagety kód", ke kterému tak rádi programátoři v Javě inkliminují (což je dalším argumentem proti kecům typu: "Vytvořily jsme super jazyk xxx, který budete používat, protože jsme v něm odstranily nebo schovaly všechny špatnosti jazyka yyy ". Pravda, s novím jazykem však přišli nové, nebo staronové nešvary). To je takz důvod proč se snažím Javovským aplikacím na desktopu vyhýbat (ono to bohužel v mém případě stoprocentně nejde, ale snad česem lidé trochu zmoudří...)

Javovskym aplikacim na desktopu se taky snazim vyhybat a duvod je zastaralost toho prostredi, nestabilita, problem s kompatibilitou atd... Ale resime tu spise jazyk jako takovy.
Spagetovy kod rozhodne neni takovy problem jaky s nej delate a rozhodne neni jen vysadou OOP, ale neodmyslitelne patri i k C++. Problem muzete resit 30 metodami nebo 2 metodami jak v OOP tak v proceduralnim prostredi!

Pomalost aplikaci jiz dnes nikdo neresi. Kdyby nekdo resil pomalost aplikaci, tak by nikdy nevznikaly webove aplikace, ale zustali bychom u desktopovych. Jenomze stejne tak, jak je vetsina programatoru spatnych, tak je i vetsina administratoru spatnych. Jedinym argumentem pro webove aplikace kdysi davno bylo, ze je neni potreba instalovat a tato jedina vyhoda prevalcovala vsechny ostatni vyhody desktopovych aplikaci. A kdyz lidi muzou cekat na nacitani stranky a pak ovladat UI pomoci mysi, tak nikdo z nich neresi vykon. A tech nekolik malo z nas, kteri preferuji efektivitu si vzdy nejak poradi.

Navic nikde neni receno, ze C#/Java je pomalejsi nez C++. U nekterych veci je pomalejsi, u nekterych vtykonnejsi. Celkove je ale vykonnejsi! A i kdyby nebyl, tak vykon HW roste, proto to neni potreba resit. Tim zase nechci rict, ze je spravne udelat neefektivni palikaci! To vubec ne! Jen rikam, ze neni potreba resit kraviny jakymi je porovnavani vykonu C++ a C# pri stejnem algoritmu! 99% vykonu aplikaci je o efektivite algoritmu a ne o vykonu jazyka. (Neresim skripty, to je ine kafe)

Kdysi jsem podobnému blábolu propadl taky - někdo někde plácl, že klasická makra nemají v C++ co dělat. Všichni jsme to jak idioti bez přemýšlení papouškovaly po něm. Dneska jsem o něco moudřejší....

Blabol to pro Vas bude pouze do te doby, nez nenajdete odvahu zkusit na dva tydny neco jineho. Muzu Vam garantovat, ze kdyz zacnete psat nejakou aplikaci v C# a stravite u toho dva tydny, jiz nikdy se nebudete chtit vracet k C++. Bude to pusobit na Vas stejne, jako kdyby Vam nekdo daroval zdarma mercedes i kdyz doma mate trabanta, vozil byste se na mercedesu a po dvou tydnech byste si mel vybrat, zda se vratite do trabose a mercedes nechate ve sve garazi hnit.

[Logik]

Ivan: Kvalitu tvoje příspěvku imho charakterizuje už to, že pokládáš SQL za procedurální jazyk...

Řešit problémy s výjimkami musíš v C++ úplně stejně jako v javě (jen java to o něco víc hlídá), s dobrou knihovnou nemusíš řešit správu paměti ani v C++ a naopak implementace správy jiných zdrojů (soubory, databáze etc.) se zas lépe řeší v C++ (viz problém chybějících destruktorů).

Osobně má z Tebe dojem, že umíš C# a neumíš C++ a proto je pro Tebe C# lepší. Jsou lidi, co uměj C++ daleko lépe a vsadím se, že některý úlohy by měli v C++ třikrát rychlejc, než ty v C#. Totéž platí pro Javu.

Jinak používanej jazyk rozhodně nemá majoritní vliv na produktivitu. To, co má největší vliv jsou knihovny. Viz příklad Delphi - ta dojela hlavně na svoje knihovny, které byly sice na první pohled jednoduché, ale chybové a velmi špatně rozšiřitelné - co jsem se s nina natrápil :-). Takže psát složitější projekt v Delphi bylo za trest a proto taky delphi skončilo tak, jak skončilo.

Člověk, co umí programovat, tak programuje čistě, čitelně a rychle nezávisle na jazyku.  Jen si v některém musí dopsat knihovny, což ho zdržuje. Např. pro C++ už ale většinou všechny potřebné knihovny jsou, jen holt nejsou standard (což může bejt i výhoda, protože je můžeš upravit, když potřebuješ).

Jinak, co se týče objektovýho a procedurálního programování, tak tvrdit, že to či ono je lepší než to druhý je imho BLBINA, protože každý koncept řeší úplně něco jiného. Větší celek nenapíšeš rozumně a čitelně bez rozčlenění na objekty, ale samotné objekty nenapíšeš rozumně bez procedurálního programování.

[blizz]

Nikto tu ako argument nezmienil hlavnú výhodu oo návrhu a to je udržovateľnosť kódu. Pri procedurálnom návrhu sa buduje architektúra systému na báze funkcií. Objektovo orientovaný návrh používa za základ modularizácie dáta (abstraktné dátové typy). Hlavným problém funkcionálnej dekompozície je zanedbanie kritéria modulárnej spojitosti. Prax ukazuje že funkcie sú menej stabilnou časťou systému a preto by nemali tvoriť základ architektúry.

[Justas]

Vrátím se zpátky k původní otázce a začnu trochu zdálky.
Když jsem se v roce 1986 začal učite ve škole Basic, nadával mi kantor, co to dělám za prasárny, proč mám v každém programu tolik podprogramů, a co to má znamenat.
Pak jsem se začal učit soukromě Pascal, a pochopil jsem, že jsem si vlastně sám vytvořil základy procedurálního programování. Prostě to odpovídalo mému vnímání světa.
Výhody OOP jsem dodnes pořádně nepochopil, patrně proto, že by mě tento přístup nutil změnit pohled na svět. Vím, jsem v tom rarita.
Jenže pak jsem začal přemýšlet o tom, co opravdu OOP dává a co je jen markteingový kec. A došel jsem k tomu, že nevidím rozdíl mezi tím, jestli si napíšu třídu nebo knihovnu. Zapouzdření je dobrá věc, ale dá se k němu dospět programátorskou kázní (prostě do těch vnitřních dat nepolezu). Dědičnost se řeší hůř (ono takové foo.str1.str2.str3.bar pro trojnásobnou dědičnost dat vypadá hůř než foo.bar), ale s odřenýma ušima to jde taky. A polymorfismus? Tak tady přiznávám, že ten se mi rozumně nahradit nepodařilo, a tak se bez něj obcházím.
Možná se připravuju o hodně, ale vzhledem k tomu, co v současné době dělám (programuju si už jen pro zábavu, a to většinou stránky v PHP), mi to vlastně ani moc nevadí...

Omlouvám se, že k otázce nepřistupuju technicky jako vy ostatní, ale spíš filosoficky -- snad mi to odpustíte...

[jk]

@justas
Filozoficky pohled je ten jediny spravny. Citim to podobne ale protoze jsem zazil jiz povícero podobnych 'zmen paradigma', tak jsem si jisty, ze OOP neprineslo nic. Pamatuji si totiz presne jeste tu dobu, kdy se tvrdilo, ze ted se bude programovat pomoci OOP a uz nebudou chyby v programech a vyvoj bude levnejsi ... bla bla. Nic takoveho se nestalo.

@blizzboz
OOP navrh jak pisete ma jeden problem. Je to jen jedna velka lez, ze objektovy pohled na svet je neco , co je cloveku prirozene. Opak je pravdou, cela existence lidi je zalozena na opakovani zazitych procedur.

[iwtu]

@Logik pekny prispevok :-)

[ext3fs]

@blizzboz
OOP navrh jak pisete ma jeden problem. Je to jen jedna velka lez, ze objektovy pohled na svet je neco , co je cloveku prirozene. Opak je pravdou, cela existence lidi je zalozena na opakovani zazitych procedur.

Tak tohle bych podtrhnul a podepsal. Muj osobni nazor je naprosto stejny.

[D.A. Tiger]

[Ivan]

Váš předpoklad při vší úctě nestačí, je lepší to napsat - protože z vašeho příspěvku vyplývá, že procedurální programování je pasé úplně. Jinak asi jste špatně informován, na filtrech je založena velká část unixových a like-unixových systémů. Asi jste nepsal nikdy třeba v GTK, Win32API, nebo SDL, kde se právě docela často mnohem složitější aplikace, s mnohem více ovladacích a aktivních prvků (než formulář s jedním tlačítkem) tvořilo (a dodnes i často tvoří) procedurálně v C.

Ano porovnávat C++ s Javou (a C#) je OFF TOPIC, ale když si přečtete Váš příspěvek, tak je takových OFF TOPIC srovnání PLNÝ.

Java je ve srovnání C/C++ pomalá. IMHO protože automatizovaná správa zdrojů něco stojí (a má další své mouchy - nedá se optimalizovat a občas bývá i nespolehlivá, už se to tu několikrát řešilo), navíc kód který musí být při spuštění dodatečně zpracováván, je IMHO vždycky pomalejší než strojový kód, no a nakonec jsou tu už samotné javovské aplikace, které jsou oproti jiným aplikacím stejného typu a zaměření opravdu pomalejší a navíc jejich odezva na nějakou událost bývá také často viditelně malátnější.

Imho způsob uvolnění z paměti si musíte občas implementovat i v Javě, gc pouze hlídá referece na daný objekt a jakmile žádné nejsou, pak objekt uvolní (jinými slovy, nemusíte např. volat operátor delete - jako v C++). Jednak já osobně to za žádnou výhodu (tak abych to musel používat vždy a v každé aplikaci) nepovažuji a jednak pokud bych o to stál, mám k dispozici v C++ např. inteligentní ukazatele, továrny a pod. No probléma.

Chcete mi tvrdit, že v Javě nemusíte ošetřovat vyjímky? No toto.... Nikde jsem netvrdil, že špagetový kód je přímou vinou Javy. ne jen k tomu spůsob programování v Javě dost svádí - o moc víc než v C/C++, avšak ano je to hlavně chyba programátorů. Jenže, tím se právě spousta zastánců Javy a C# ohání -> prý jedním z cílů jejich existence je psát efektivní kód bez nešvarů jejich předchůdců. A se špagetovým kódem se zápasilo (v trochu jiné formě) už na BASICU ;-) Navíc tento problém javě na výkonosti asi moc nepřidá.

Nakonec, je rozdíl, když kód pracuje na silném stroji jako modul serveru a je rozdíl když pracuje na obyčejném PC jako samostatná aplikace s plným GUI.

Já jsem zkusil jazyků myslím, že docela dost. Některé více a některé méně do hloubky, a nakonec jsem zůstal  u C++. Asi jednak proto, že pro většinu problému, které řeším, mi poskytuje dostatčné nástroje a možnosti ( a pokud mi něco chybí, tak už to někdo implementoval, nebo mi to implementovat umožní - s mnohem menším úsilím, než v jazycích vyšší úrovně), nic za mě nedělá a nic přede mnou neschovává,  a nakonec mi umožnuje samostatně rozhodovat co, kdy a jak se bude dělat. Mohu použít téměř jakýkoliv styl programování. (Je libo typy/objekty, funkce, metaobjekty, nebo něco speciálnějšího... např lispovské seznamy typů?) Je tedy velice flexibilní a výkonný. Ano, má to i své mouchy - a co nemá? Mě však předešlé vlastnosti C++ za to stojí. Toliko k mercedesu v garáži.
   

[iwtu]

@blizzboz
OOP navrh jak pisete ma jeden problem. Je to jen jedna velka lez, ze objektovy pohled na svet je neco , co je cloveku prirozene. Opak je pravdou, cela existence lidi je zalozena na opakovani zazitych procedur.

Tak tohle bych podtrhnul a podepsal. Muj osobni nazor je naprosto stejny.

dnes sa uz psychiatrii zhodoju, ze clovek nema prirodzenost :-) Vidno to na uplne rozdielnych etnickych zvyklostiach atd.... OOP moze prist prirodzeny managerovi alebo cloveku na nom zvyknuty. I ked stale si myslim, ze to zalezi od problemu k problemu. Niekomu sa vidi prirodzeny iba Assembler alebo Haskell. Na co sa clovek nastavi, to mu pride prirodzene... Moj skromny nazor :-)