Jste zastánci OOP programování?

[JS]

Ale to já netvrdím. Já jsem taky zastánce OOP. Akorát tvrdím, že OOP řeší jiné problémy než procedurální programování. Prostě jsou OOP procedurální jazyky (např. C# nebo Java) a OOP deklarativní jazyky (CLOS nebo ten paper co jsem postoval) takže říkat, že OOP je lepší horší než procedurální programování je prostě blbina, stejně jako nejde říct, jestli je lepší mlýnek na maso nebo pánev.

Presne tak. Podle me hadat se, zda je lepsi OOP nebo proceduralni programovani je jako hadat se, zda jsou v jazyce dulezitejsi slovesa nebo podstatna jmena. Viz tez http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html.

[Reklama]

[martin]

OOP nepotrebuje, aby som ho zastaval.
Naopak, ja potrebujem OOP:

• aby som mohol pouzivat tisicky metod, ktore napisali ini ludia.
  
• aby som vedel zorganizovat vlastny kod.
  

Nehovorim, ze OOP je vseliek. OOP nezabranuje problemom. OOP je pristup, ktory nieco umoznuje. Pre mna je OOP dar z nebies.

[Logik]

JS: To jsem neznal. A je to fakt dobrý :-)

[dekel]

Ak niekto nazve Smalltalk alebo Ruby objektovými jazykmi tak nepochopil o čom OOP vlastne je. Smlltalk a Ruby sú jazyky, ktoré porušujú základné princípy OOP.

[JS]

Ak niekto nazve Smalltalk alebo Ruby objektovými jazykmi tak nepochopil o čom OOP vlastne je. Smlltalk a Ruby sú jazyky, ktoré porušujú základné princípy OOP.

To jsou ponekud silna slova, uvazime-li, ze to byl autor Smalltalku, kdo termin OOP vymyslel. Viz tez http://www.paulgraham.com/reesoo.html. Ktere z tech bodu tam zminenych jsou podle vas to prave OOP?

[Reklama]

[Bobrnautus]

Já jsem zastáncem prasoprogramování. Nedodržuji základní programátorské konvence a skoro pořád používám příkaz goto. :-D

[Logik]

Bobr: To já programuju zásadně objektově:
program.goto(radka)
:-D

Dekel: Jazyk porušuje principy OOP? Já měl za to, že jedinej , kdo je může porušit je programátor. Jazyk k tomu akorát může či nemusí dávat vhodné vyjadřovací prostředky.
Jinak také se obávám, že OOP tady nepochopil nikdo jiný - a ve slušné diskusi je zvykem
svá tvrzení podkládat argumenty a ne vytvářet flametvorné výkřiky do tmy :-)

[Paja]

Nikde jsem v diskuzi nenašel hlavní důvod pro použití OOP jak to vidím já.
Je to rozhraní. A stím související kontejnery objektů.

Příklady :
a/ evidence něčeho na webu
definuju rozhraní které umí objekt načíst, uložit, zobrazit jeho formulář, zvalidovat jeho formulář, vypsat seznam položek a popř. vyhledat. Jeden objekt může implementovat třeba uživatele, jiný třeba auta ve firmě, atd ... K tomu pak stačí zobrazovací nadstavba která pracuje s objekty implementujícími toto rozhraní. A je jí jedno čeho se ta evidence týká. A když chci přidat objekt, stačí napsat jen tento objekt.
b/ lineage server napsaný v javě
například rozhraní pro zbraně. Když chci vytvořit novou zbraň se speciálními vlastnostmi, definuju tento objekt s rozhraním jaké má mít zbraň. A hra už ho umí použít sama. Tady se navíc použije i dědičnost - použiju nějakou jinou zbraň a přidám speciální vlastnosti (např. na dinosaury je 2x účinnější než na draky)

[Logik]

Ne že bych byl proti OOP, ale právě to co jsi teď postnul ukazuje limity OOP v Javě/C# a nadužívání dědičnosti.

Chci zbraň co dává 2x drakům. Podědím ze zbraně. Chci zbraň, co dává 2xskřetům. Ok, také podědím ze zbraně. No a teď chci zbraň, co dává jak 2xdrakům, tak 2xskřetům. A z čeho ji mám podědit?
Např. podědím-li jí opět ze zbraně, dosti špatně pak budu implementovat nestvůru, která je zranitelná právě jen zbraněmi, které dávají minimálně 2x skřetům, protože mám dvě nesouvisející třídy, které obě popisují zbraň s danou vlastností.

Jojo, OOP rulez, ale ani OOP nezaručí jednoduchou a na první pohled jasnou architekturu programu...

[Paja]

No to byly takove triviální příklady pro ty co o rozhraní neslyšeli - znají jen dědičnost.

Do L2j serveru přispívá několik desítek (možná stovek) lidí. A díky rozhraní nemusí znát vše, stačí nastudovat jen to co chtějí přidat/měnit/opravit. S tím příkladem co píšeš by je komunita hnala ... I když občas tam taky člověk najde zvěrstva.

S OOP i bez OOP se dají napsat špatné a dobré programy.

[Logik]

Tak jak bys to teda vyřešil pomocí rozhraní? :-)

(IMHO rozhraní Ti tady právě zas až tak nepomůže... ale třeba se pletu....)

[Paja]

Myslím že si nerozumíme. Objekt zbraně kterou držím v ruce implementuje rozhraní zbraně.
Rozhraní zbraně má řekněme k dispozici výchozí definici která načítá hodnoty z databáze. Můžu a nemusím ho použít. Lépe je použít ho - jednodušeji budu modifikovat třeba její hmotnost a rychlost - jen nastavením v databázi.

Teď záleží, co vlasně chci. Pokud je to speciální vlasnost zbraně, přidám modifikaci metody útočná sila podle třeba počasí, nepřítele, ... Pokud chci zavést nový typ všeobecněji - bude třeba změnit rozhraní a udělat refaktorizaci. Včetně databáze. To mi naopak umožní zavést tyto vlastnosti jednoduše do zbraní co dědí úvodní implementaci. U ostatních, co si někdo splácal na koleně to vyhodí chybu implementace rozhraní - nebudou mít metody které jsem přidal. Takže pokud chci aby měly všechny zbraně vlastnost na draky, na skřety udělám to takto.

Můžu ale udělat i tu nestvůru. Změním její metodu příjmu zranění. Bude reagovat na konkrétní objekt který na ní útočí. A pokud byla zbraň A na skřety, B je potomkem A který má navíc i draky tak budu reagovat na instanci B.

Rozhraní je o tom - že někdo kliknul na útok. A algoritmus který počítá útok neobsahuje žádné konkrétní hodnoty - vše mu řekne zbraň kterou útočím. Nikdy nebudu muset měnit algoritmus který řeší útok kvůli přidání zbraně. A dokonce pokud udělám bug - projeví se jen při použití zbraně. Odladěný algoritmus útoku se ani nehne.

Kdyby to nebylo přes OOP, musím při každé změně šahat do algoritmu co řeší útok. Dodělávat do něj podmínky, zanášet konkrétní hodnoty. Časem by z něj byl velký kus kódu. Blbě laditelný a nepřehledný.

[Logik]

Takže pokud budu dělat zbraň na skřety, tak tam musím znovu zopakovat celou metodu jak se útočí a někam dovnitř tam vepsat modifikátor x2? Nebo jak.

A když takových zbraní vyrobím třicet, tak tam budu mít třicet skoroduplicitních kódů? A když pak budu chtít změnit algoritmus útoků všech zbraní.... No fuj.... To už snad radši ten neOOP přístup. :-)

Anebo z jiné strany - mám zbraň na skřety. Mám zbraň na draky. Jak z toho jednoduše vyrobím zbraň, která kombinuje vlastnosti obou?

Ono samozřejmě že OOP přístup je lepší (spíš bych řekl že je nejbližší realitě a proto přináší nejméně problémů), ale zrovna přístup chci modifikaci objektu, tak ho podědím je imho
velmi špatný.
Copak zbraň více zraňující skřety je něco "speciálnějšího" než zbraň? Copak ona umí něco více, poskytuje něco co běžná zbraň ne? Tak proč dědičnost? Zraňovat více skřety je vlastnost zbraně a jako taková by měla být implementována: tedy nikoli dědičností, ale agregací dané vlastnosti.

B je potomkem A který má navíc i draky tak budu reagovat na instanci B.

Fuj. To je právě to. A proč je zbraň která je na skřety i draky potomkem zbraně, která je jen na skřety a ne potomkem zbraně, která je jen na draky? Nebo potomkem obou? (což jaksi v javě/C# nejde a v C++ je zdrojem velkých problémů...

Můžu ale udělat i tu nestvůru. Změním její metodu příjmu zranění.

To můžu, ale dostanu se do stejnejch problémů u nestvůry, která bude skřet i drak (skřetodrak, no fuj :-) ).

Pokud chci zavést nový typ všeobecněji - bude třeba změnit rozhraní a udělat refaktorizaci. Včetně databáze. ..... U ostatních, co si někdo splácal na koleně to vyhodí chybu implementace rozhraní - nebudou mít metody které jsem přidal.

Bavíme se o OOP? Já měl za to, že v OOP implementace potomka NESMÍ zasahovat do implementace předka. Pokud pro novej typ musím modifikovat předka, něco jsem udělal špatně...
Právě proto, aby fungovali i objekty, co napíše někdo jiný...

[Paja]

To mi přijde jako o voze a koze.

Nepsal jsem nic o modifikaci předka. Psal jsem o refaktorizaci a změně rozhraní. Je jasné, že pokud musím udělat 30 téměř stejných objektů, měl bych přehodnotit zda není třeba refaktorizace. To je stejné pro OOP jako bez objektů.

Vrátil bych se k tomu co považuji za výhodu OOP - to jsou kontejnery objektů implementujících rozhraní. To je v neOOP o dost méně přehlednější. A náročnější na chyby a odladění.

[Logik]

Změna rozhraní je totéž jako změna předka - prostě v okamžiku, kdy todle člověk musí udělat, tak byla provedena špatně analýza.

Nevím, o jaké koze se bavíš ty :-), ale já celou dobu upozorňuju, že to, co jsi napsal jako ukázkový příklad OOP: "potřebuji modifikaci vlastnosti objektu, tak z něj udělám potomka", nemá s OOP moc společného, protože to porušuje hned několik zásad OOP
- používá to dědičnost tam, kde nepatří
- nevede to k znovupoužitelnosti kódu
- nutí to modifikovat předka/rozhraní při implementaci potomka