Jste zastánci OOP programování?

[ondra.novacisko.cz]

Vy sa tu hádate čo je lepšie a ja furt neviem o čom... Každý o tom hovorí, už mi ľudia posielali siahodlhé články, ale nikde v tých tonách slov som nevidel príklad a uvedené rozdiely (ne)OOP programovania.
Mohol by mi to prosím niekto vysvetliť (najlepšie na nejakom príklade v PHP, ale v podstate je to jedno)? Ďakujem.

Tak třeba porovnejte API GTK a QT.
Nebo Windows GUI a Javovské GUI.
Třeba najednou přijdete na to, proč Windows mají pro každou blbost okno. No jasně, oni totiž mají pouze jeden "objekt", který funguje jako holka na všechno. Zatímco v Javovském GUI máme listenery a interface a takovy věci.

Pak člověk řeší třeba takové věci, proč zpráva z menu se handluje přes okno (který nemusí s menu mít nic společného) ve windows, zatímco v Javě přes listener spojený přímo s tím menu.

Ono je to právě všechno v tom navrhu a jít na to neobjektově, pak člověk hledá způsoby jak si ušetřit práci znásilňováním věci, které původně byly určeny pro něco jiného, ale protože mají určitou specifickou vlastnost, tak se to znásilní. Okna ve Windows mají schopnost přijímat zprávy, protože potřebují vědět, kdy se mají nakreslit, nebo kdy se do nich kliklo. Proto když chce člověk přijmout například zprávu o tom, že na soket došla data, co použije... no jasně, znásilní si okno  , namísto toho, aby k soketu zaregistroval rozhraní, na němž se vyvolá patřičná funkce, která vykoná obsluhu dané akce.

[Reklama]

[D.A. Tiger]

To není vlastnost "čistě objektových" jazyků, to je vlastnost jazyků používajících duck typing. V duck-typingu a ve strukturálních typových systémech můžou být typy kompatibilní i bez toho, aby tak byly explicitně deklarovány. V typovém systému, který má C++, na to explicitně deklarovány být musí - je to tzv. nominální typový systém.

S tím, jestli je jazyk čistě objektový (jako např. Ruby - to neobsahuje žádné jiné datové typy než třídy), to nemá nic společného. Mimochodem, Python čistě objektový není.

Ok, i když si myslím, že podobného efektu by šlo dosáhnout už jen s pomocí pozdní vazby.

Nic to však nemění na tom, že se mi nelíbí možnost, pouze díky shodě rozhraní či podobnosti hodnoty, zaměnit dva naprosto odlišné objekty  (což v C++ už tak jednoduché není. Tedy pokud nejsou potomky jedné třídy, ale pak je už nepovažuji za naprosto odlišné.... ). Tedy chci, aby se potopil potápěč a ... pošlu ke dnu celou letadlovou loď... 

[koroptev]

me v posledni dobe zaujal rozhovor s Alanem Kayem, mimo jine tam vysvetluje motivace zavedeni pojmu OOP, zminuje jednak nejaky vektorovy kreslici program, druhak priklad s nejakymi vojenskymi depesemi + problemy s jejich zpracovanim (+ protipriklad weboveho prohlizece a html); ten druhy zejmena mi prijde jako jadro te puvodni myslenky - dorucit data spolecne s kodem, ktery s nimi bude umet pracovat, protoze neni dobre spolehat na to, ze druha strana umi s onemi daty vubec spolupracovat, druha strana proste jen pouzije ten kod, co to umi
tohle je na hony vzdalene tomu, co se tim mysli dnes, dle me je uzitecne rozdelit OOP z pohledu - 1.) modelovani reality pri reseni problemu, protoze je to prirozene (a velmi casto "prirozene") 2.) metodika vytvareni programu, ktera s tim Kayovym pohledem nema jiz mnoho spolecneho (on mimo jine dodava "extreme late binding on everything")
takovou funkce sin(x) zjevne z toho 1. pohledu nema VUBEC ZADNY smysl umistovat do jakekoli tridy, ze, ale dela se to kvuli tomu 2. pohledu, protoze trida vetsinou implikuje namespace napr. a nejaky pocit, ze "je to pohromade" (treba s cosinem)..
ad metodika - resp. ze funkce (potazmo strukturovane programovani) metodika nejsou; samozrejme jsou, popreni je jako rici, ze pred C++ nebo Javou se nic velkeho nedelalo (delalo, nedelaly to hordy nahraditelnych "lidskych zdroju")
ad potapec/ponorka - a proc bych pro situaci, kdy chci mit naprostou jistotu, volil neco, co mi ji neda? kdyz mi ji to neda? stejne jako proc bych tam nenapsal ten runtime test rucne (v jazycich s duck typingem), kdyz bych ji opravdu chtel mit? na co presne to ma ukazovat? ze dynamicka typova kontrola je horsi? je jina a ma jine vyhody; megaobev, gratuluju
vzhledem k tomu, jak moc se Java uchytila v korporatnu, pocitam, ze to je z duvodu preneseni jadra vykonu povolani z porozumeni/premysleni na schopnost vyhledavani v dokumentaci/neskodneho (to je asi opravdu plus Javy) dobastlovani (tozn. vymeni se clovek a muze, protoze browsit tridy a jejich dokumentaci ve standardnim formatu je zvykly, pokracovat v tom, co nekdo zkusenejsi navrhl), coz je neco, co se univerzalnim hnedym manazerum, kteri chteji "zastupitelnost", "jistotu" a ordnung nejspis libi..

[Inkvizitor]

Byl by jsi schopen vysvětlit, co to monáda je?

Monáda je (zjednodušeně řečeno) krabice na nějaký typ, která má dvě základní operace, return pro vytvoření monády a bind, která umožňuje transformaci obsahu a vytvoření jiné monády. Používá se v Haskellu mimo jiné pro práci s I/O a definici sekvence akcí (čistý Haskell je v podstatě jedna velká transformace vstupních dat na výstupní a explicitní sekvence akcí nedefinuje).

Nicméně jsem se nad tím zamýšlel a monáda bez modulu zapouzdření moc neřeší, takže se omlouvám za zbrklý výrok.

[koroptev]

jeste k ponorce/potapecovi - co presne to melo dokazovat?
1.) ze ve staticky typovanem jazyku mi instance.potop nikdy nepotopi ponorku? japato, co kdyz jsem se upsal a potapim prave instanci ponorky? typechecker to prohlasi za ok, chyba je v semantice, stejne jako kdyz se upisu v dynamicky typovanem
2.) ze ve staticky typovanem jazyce rychle najdu (= zjistim potencialni chybu) mista, kde potapim ponorku diky typovym deklaracim (i v hlavickach funkci/metod)? no japabyne, kdyz ty typy vsude pisu resp. znovu a znovu opisuju, bez toho ten typechecker nepremava!

[Reklama]

[Petr Mejzlík]

Nic to však nemění na tom, že se mi nelíbí možnost, pouze díky shodě rozhraní či podobnosti hodnoty, zaměnit dva naprosto odlišné objekty  (což v C++ už tak jednoduché není. Tedy pokud nejsou potomky jedné třídy, ale pak je už nepovažuji za naprosto odlišné.... ). Tedy chci, aby se potopil potápěč a ... pošlu ke dnu celou letadlovou loď... 

To se mi taky nelíbí. Na druhou stranu je to jednodušší, pružnější.

1.) ze ve staticky typovanem jazyku mi instance.potop nikdy nepotopi ponorku? japato, co kdyz jsem se upsal a potapim prave instanci ponorky? typechecker to prohlasi za ok, chyba je v semantice, stejne jako kdyz se upisu v dynamicky typovanem

Japato: protože je tam explicitně napsaný typ. Mám třeba nějakou funkci, která má na starosti ponor potápěče na určitém místě a té dám jako parametr potápěče:

Kód: [Vybrat]

void ponor(Potapec& p, double zem_sirka, double zem_delka) {
  //...
  p.ponor();
  // ...
}Taková funkce nemůže potopit ponorku, protože p nemůže být ponorka, může to být jenom potápěč. Nejde jí předat místo potápěče něco jiného, překladač by zahlásil chybu a program by nepřeložil. Pokud se program přeloží, je zaručeno, že funkce ponor() pracuje vždycky jen s potápěčem a nikdy s ničím jiným.

[Bone Flute X]

Pánové, prosím vás, k tomu Duck typingu - veškerý fór je v tom, že zatímco duck typing prohlašuje, že "chodí to jako kachna, plave to jako kachna, kváká to jako kachna - je to kachna", od toho to má i to jméno, tak klasicky, bez duck typingu se pracuje tak, že "Je to kachna? Sice to kváká, plave, chodí jako kachna, ale má to na sobě cedulku, že je to veterán z vojny, takže to kachna není."

Takže k tomu potápěči to dokazuje jen to, že nemůže dojít k omylu na základě shody metod. Nic víc, nic méně.

[blizz]

duck typing prohlašuje, že "chodí to jako kachna, plave to jako kachna, kváká to jako kachna - je to kachna", od toho to má i to jméno, tak klasicky, bez duck typingu se pracuje tak, že "Je to kachna? Sice to kváká, plave, chodí jako kachna, ale má to na sobě cedulku, že je to veterán z vojny, takže to kachna není."

Bez urážky ale z toho čo som prečítal tak na tomto fóre je naozaj minimum ludí, ktorí vedia programovať a rozumejú OOP a preto tu splietate takéto nezmysli o kachnách. Sú to naozaj drísty. Na roote by sa mala zaviesť sekcia vtipy a všetky príspevky z tohoto threadu do nej presunúť.

[Petr Mejzlík]

Bez urážky ale z toho čo som prečítal tak na tomto fóre je naozaj minimum ludí, ktorí vedia programovať a rozumejú OOP a preto tu splietate takéto nezmysli o kachnách. Sú to naozaj drísty. Na roote by sa mala zaviesť sekcia vtipy a všetky príspevky z tohoto threadu do nej presunúť.

Duck typing se podle toho fakt jmenuje, uvádí se to typicky jako přirovnání, nevymyslel to nikdo tady.

[Bone Flute X]

Bez urážky ...

Pokračuj v cestě...

[Radovan]

... na tomto fóre je naozaj minimum ludí, ktorí vedia programovať a rozumejú OOP ...

Já se programováním neživím, je to jen můj koníček, OOP nesnáším a nepoužívám, ale co je Duck typing vím velmi dobře a ctím moudrost člověka, který tohle přirovnání vymyslel. Řekl bych tedy, že tvůj výrok pasuje především na tebe ;-)
Mimochodem, když jsem stejný "kachní" citát použil na Laela, tak také nepochopil, ale to je starší člověk který dnešní technologie už moc nestíhá...

[ondra.novacisko.cz]

... na tomto fóre je naozaj minimum ludí, ktorí vedia programovať a rozumejú OOP ...

Já se programováním neživím, je to jen můj koníček, OOP nesnáším a nepoužívám, ale co je Duck typing vím velmi dobře a ctím moudrost člověka, který tohle přirovnání vymyslel. Řekl bych tedy, že tvůj výrok pasuje především na tebe ;-)
Mimochodem, když jsem stejný "kachní" citát použil na Laela, tak také nepochopil, ale to je starší člověk který dnešní technologie už moc nestíhá...

Rozdíl mezi klasickým duck typingem a  OOP je v tom, že zatímco u duck typingu vám stačí najít společné znaky, které jsou pro daný typ objektu typické, tak u OOP je musíte takto označit.  Abych argumentoval v podobném duchu jako klasický duck test:

If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

Slovíčko probably je tady hodně důležité. Mě třeba dost vadí.

[Inkvizitor]

If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

Slovíčko probably je tady hodně důležité. Mě třeba dost vadí.

Myslím, že není problém si pohlídat, aby v metodě šly zpracovávat opravdu jenom objekty typu "kachna". V Pythonu apod. ale až v době běhu programu; což je podle mě větší problém, než samotný duck typing. Ten je IMO neškodný, ale pokud program (třeba v Pythonu) až při běhu zjistí, že ten objekt nemá metodu swim, je to průšvih. Ale to je problém dynamických jazyků obecně. V praxi to obvykle tak často nevadí.

Nedávno jsme narazili v jednom projektu na podobný problém - kolega použil omylem v jednom volání numerickou konstantu podobne vyhlížející, ale patřící do jiné kategorie. To by se mu stalo i v C++ a problematiku OOP to přesahuje. Primárně jde o rozumně definované typy. Pokud se nepletu, enum by v C++ nepomohl a dělat si na každou kategorii konstant speciální třídu je strašlivý opruz.

[Petr Mejzlík]

Rozdíl mezi klasickým duck typingem a  OOP je v tom, že zatímco u duck typingu vám stačí najít společné znaky, které jsou pro daný typ objektu typické, tak u OOP je musíte takto označit.

To je blábol, OOP vůbec není v rozporu duck typingem. OOP není typový systém, je blbost porovnávat OOP a nějaký typový systém. Různé OOP jazyky mají různé typové systémy.

[ondra.novacisko.cz]

Rozdíl mezi klasickým duck typingem a  OOP je v tom, že zatímco u duck typingu vám stačí najít společné znaky, které jsou pro daný typ objektu typické, tak u OOP je musíte takto označit.

To je blábol, OOP vůbec není v rozporu duck typingem. OOP není typový systém, je blbost porovnávat OOP a nějaký typový systém. Různé OOP jazyky mají různé typové systémy.

Omlouvám se za zkratku. Myslel jsem tím OOP se statickým typováním. To do OOP patří.

Přiřazování do tříd je velmi oblíbenou technikou v OOP, akorát je třeba umět přiřadit objekt do vícero tříd, což je třeba problém Javy a jiných jazyků, jdoucí třetí cestou.

Příklad kachny jako objektu, který patří do třídy plavající, kvákající a vypadající jako kachna.