Jste zastánci OOP programování?

[ondra.novacisko.cz]

Fakt, že C++ je na ústupu, je prostě fakt, i kdyby se vám to tisíckrát zdálo jako spiknutí lidí kráčejících s dobou.

Jsou v těch grafek započítány i nárusty počtu programátorů, které mají díky jednodušším jazykům typu C# blíže k programování, než třeba u C++? Aby se neukázalo, že těch C++ programátorů je plusmínus pořád stejně a jen do oboru přichází noví lidé

[Reklama]

[Mirek Prýmek]

The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. The popular search engines Google, MSN, Yahoo!, Wikipedia and YouTube are used to calculate the ratings. Observe that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Osobně bych nepodceňoval růst Objective C, který nepochybně souvisí se zvyšující se popularitou produktů Applu, což je trend, který bude IMHO pokračovat.

[vvv]

Z toho grafu je ale jen videt, ktery jazyk roste/klesa vzhledem k ostatnim.

Relativni rust nebo pokles uplatneni vzhledem k jazyku samotnemu by byl v tomhle pripade zajimavejsi ne?

[x]

"Pokud není člověk prase a ke každé datové položce hned nepíše getter a setter"

A ja myslel ze principem OOP je pouzivat prave vzdycky gettery a settery, prave proto, ze muze prijit situace kdy se neco vlozi do setteru a tim se obejde prepisovani kodu na mnoha mistech treba. ALe ja sam moc get a set taky nepouzivam protoze jsem proste linej

[Petr Mejzlík]

Taky jsem myslel, že v Javě je naopak člověk prase, když gettery a settery nepíše - že to sice je práce navíc, ale je to tak správné. Kdo je teda vlastně prase? Getter a setter může být:

• i tam, kde je jeho přidaná hodnota nulová (pro důslednost - aby nebylo něco s getterem/setterem a něco jiného zase používané přímo), a v kódu bude spousta "zbytečných" getterů a setterů
• jenom tam, kde se to hodí, ale pak to zase bude "každý pes jiná ves"

[Reklama]

[ondra.novacisko.cz]

Taky jsem myslel, že v Javě je naopak člověk prase, když gettery a settery nepíše - že to sice je práce navíc, ale je to tak správné. Kdo je teda vlastně prase? Getter a setter může být:

Naštěstí gettry a settry lze generovat a to jak v Eclipse (Java). tak v inteligentních nástrojích pro vývoj v C++ (Visual Assist X, Eclipse CDT)

[Inkvizitor]

K těm getterům a setterům - problém je v tom, že ostatním objektům (obecně) není NIC do toho, co má jiný objekt uvnitř, natož aby mohly libovolně data jiného objektu modifikovat. Protože jakmile se zpřístupní všechna data všech objektů všem, nastane několik problémů:

1. Dochází k redundanci rozhraní. Každý programátor se rozhodne s daným objektem pracovat jinak. V kódu bude chaos, někdo bude používat "nízkoúrovňové" gettery a settery (není žádný měkkýš), druhý bude používat vysokoúrovňové rozhraní, tj. požádá objekt, aby provedl celou operaci (je to systematické a méně pracné), třetí bude obě techniky střídat podle toho, jak se zrovna vyspí a čtvrtý podle toho, jestli je lichý nebo sudý týden.

2. Roste složitost kódu v objektu, pokud chceme docílit konzistentního chování. Například pokud ten kód reprezentuje geometrický útvar a chceme omezit jeho velikost, musí se to ohlídat nejenom tam, kde provádíme komplexní operaci (resize(), scale() nebo něco podobného), ale i ve všech setterech, které ten objekt mohou zvětšit.

3. Pokud chceme z nějakého důvodu změnit vnitřní implementaci (efektivita, apod.), musíme buďto změnit kód na všech místech, kde se settery a gettery používají, případně ty gettery a settery (vygenerované původně jednoduše pomocí dekorátoru nebo třeba prostřednictvím IDE) změnit tak, aby chování objektu po zavolání příslušné metody (dříve getteru nebo setteru) zůstalo stejné, resp. aby se navrátila data ve stejné podobě jako dřív.

Ano, v případě getterů a setterů mi jako menší zlo přijde je dělat jenom v případě, kdy jsou skutečně nezbytné.

[ondra.novacisko.cz]

Ano, v případě getterů a setterů mi jako menší zlo přijde je dělat jenom v případě, kdy jsou skutečně nezbytné.

To asi jo, takže nakonec jich tolik nebude. Můj styl je dokonce takový, že konfigurace objektu jde vždycky přes konstruktor. Settry už jen slouží, ke změně vnitřního stavu. Gettry mají občas výhodu v tom, že redukují duplicitní informace, pokud objekt například poskytuje informace o dalších objektech, se kterými komunikuje.

Pokud je objekt bezestavový, settry vůbec nepotřebuje. Takový objekt má výhodu, že při přístupu nepotřebuje zamykat (v MT prostředí)

[Inkvizitor]

Miroslav Prýmek: Ke getterům a setterům jsem se už vyjádřil. Co se týče UML, nic srovnatelného (podle daných kritérií) osobně neznám.

V Prologu jsem dělal jenom jednu školní úlohu, s Haskellem jsem si hrál víc, ale nikdy jsem v něm nedělal nic většího a ani nechci. Většinu toho, co nabízí Haskell, umožňuje více či méně elegantně třeba Scala, přičemž ale méně programátora omezuje (když chci vypsat něco na obrazovku, nemusím si s sebou tahat explicitně celý monitor) a souhlasím s tím, že "čistě funkcionální přístup" je dosud jenom spíš akademický koncept. Haskell má koneckonců už několikátou implementaci IO přístupu (před monádami byly tuším další dva pokusy, moc si nepamatuju, o co přesně šlo). Ten čistě funkcionální přístup ale LZE používat v co největší míře, nicméně se to ale zase podle mě tluče s některými zásadami OOP a rozhodně s běžnou praxí. FP se ale do mainstreamu tlačí i tak a objektoví fundamentalisté se s tím asi budou muset nějak srovnat. 

[anonym]

"Pokud není člověk prase a ke každé datové položce hned nepíše getter a setter"

A ja myslel ze principem OOP je pouzivat prave vzdycky gettery a settery, prave proto, ze muze prijit situace kdy se neco vlozi do setteru a tim se obejde prepisovani kodu na mnoha mistech treba. ALe ja sam moc get a set taky nepouzivam protoze jsem proste linej

skus si pozriet ine programovacie jazyky ktore pouzivaju "threads", a potom pochopis preco instancne premenne su private.

[ondra.novacisko.cz]

gettry a settry v zásade nepoužívám u objektů nesoucí konfiguraci. Prostě něco jako struktura. Ty objekty zpravidla nemají jedinou metodu, nebo mají metody, které zjednodušují nastavování některých atributů. Tam bych opravdu gettry a settry viděl zbytečné.

Právě tyto objekty pak jsou parametry konstruktorů a jiný význam, než příprava konfigurace, nemají. Ani by se neměli sdílet mezi thready

[Logik]

IMHO u setterů a getterů je třeba rozlišovat k čemu.
- jsou interní proměnné objektu, které nesou jeho vnitřní stav. Ty by neměli mít s/g, ty by neměli být vidět vůbec.
- pak jsou externě viditelné nezávislé vlastnosti objektů (např. jméno člověka). Tam by měl naopak být getter vždy a setter velmi často (např. na barvu rámečku okna)
- pak jsou externě viditeln vlastnosti, které vypovídají o vnitřním stavu objektu. Tam mívá smysl setter, ale málokdy getter (např. indikátor, zdali je stream otevřený apod.)

Mastit s/g ke každý vlastnosti a pracovat s objektem jako se strukturou není OOP, ale paskvil.

Co se týče konfiguračních objektů, u těch je otázka, jestli ve skutečnosti nejde o strukturu (teda není to objekt - samostatná entita, čistě strukturovaný vlastnost nějakého objektu). Nicméně vzhledem k tomu, že třeba časem to chce umět konfiguraci uložit (perzistence), nějak upravovat, přenášet mezi objekty atd., tak se na to často hodí nahlížet jako na objekt.
V tomdle případě jsem na vážkách, kterej přístup je správnej, asi jak kdy (podle velikosti programu, účelu struktury a také jednoduchosti s/g či properties v danym jazyku).

[Hynek Vychodil]

Jsem skalní zastánce OOP a proto je mým nejoblíbenějším jazykem Erlang, protože tam jsou objekty skutečně zapouzdřené, aliasing a problémy s dědičností jsou prakticky eliminovány. Teda pokud člověku nevadí, ze objektům se říká process a metodám message. Kam se hrabe takový SmallTalk.

[D.A. Tiger]

Pokud mám mluvit za sebe, řekl bych, že nejsem skalním zastáncem žádného programovacího stylu nebo techniky. Podle mě  IMHO mnohem více záleží na typ úlohy/problému,  který jsem se rozhodl řešit pomocí vlastního programu a na tom co umím, nebo znám. Tahle univerzálnost je jeden z důvodů proč je pro mě C++ no. 1 - mohu v něm v základu volit mezi strukturálním a určitým typem objektového programovaní. A pokud chci tak mi nabízí možnosti jak implementovat / simulovat vlastnosti jiných jazyků (programovacích technik a stylů). Je to sice už mnohdy vyšší dívčí - přiznávám, že bych si na ledacos asi netroufl , ale vím, že to v C++ jde...  V mnohých jiných "čistých" jazycích by to znamenalo mnohem větší problém. 

Když se na různé svaté války (flamewary) za ten jediný správný jazyk, styl, techniku, ... (doplnte si, prosím, patřičný pojem) dívám z tohoto pohledu, neubráním se pobavenému úsměvu a myšlence na to, že "každá liška chválí svůj ocas..."     

[VM]

OOP používám jen tam kde musím a kde to přináší efekt, například když potřebuju interface s dědičností. Proč? Myslím že nevhodné použití OOP přináší celou řadu problémů:

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).
No a do takto vygenerovaného bludiště programátoři ukryjí vlastní kód. Ten se mezi tisíci vygenerovaných metod hledá obtížně, a při přegenerování kvůli změně schématu se většinou ztratí nebo aspoň rozbije.

Neduh číslo 2: nadužívání objektů a tříd
Třídy jsou vhodné tam, kde je potřeba objekty dynamicky nahrazovat za jiné se stejným rozhraním. U interních datových struktur, kde to nedává smysl, bych to nepoužil. 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ěť.

Neduh číslo 3: gettery a settery na úplně všechno
Myslím že gettery a settery mají místo v rozhraní modulu, který komunikuje s vnějším světem, a i tam jen v případě, že reálně očekáváme, že položka v budoucnu např. změní typ, nebo že bude potřeba nějaká reakce. Spousta programátorů je ale cpe úplně všude. V kombinaci s předchozím to znamená, že veškerý přístup k datovým strukturám se dělá pomocí řetízku volání getterů a setterů, což je nepřehledné na zápis, zpomaluje běh, a nemá žádný dobrý důvod. Pokud navíc předpokládáme, že některé položky struktury nejsou vyplněné, musíme každý jednotlivý řádek uzavřít do vlastního try .. catch bloku, nebo k němu napsat velmi dlouhý if().

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í.

Ale pokud se objekty používají s mírou a rozumem, mohou být užitečné.