Co si myslíte o OOP?

[oss]

Boze, toto tu je ciste trolenie bez argumentov.
fakt zboznujem ludi co sa vyjadruju o OOP a pri tom v nom nevedia kodit (vid priklad hore, to je antoipatern OOP).
Ale dnes je modrene nadavat na vsteko co ako tak funguje a dava zmysel.

[Reklama]

[Kiwi]

Ne. Každý si pod tím představuje trochu něco jiného. Pro mě to je to, co tím mysleli otcové-zakladatelé, tj. Alan Kay a spol.

Tomu se dneska (bohužel) říká spíš "agentní systém" nebo "actor model".

Proto tvrdě prosazuji návrat k tomu původnímu smyslu. Pro to byl ten název vymyšlen. Že tím dnes většina lidí myslí C++ nebo Javu je jen důkazem, že to celé vůbec nepochopili (včetně tvůrců těch jazyků). Současné mainstreamové pojetí je cargo kult jak vyšitý.

[JSH]

Ne. Každý si pod tím představuje trochu něco jiného. Pro mě to je to, co tím mysleli otcové-zakladatelé, tj. Alan Kay a spol.

Tomu se dneska (bohužel) říká spíš "agentní systém" nebo "actor model".

Proto tvrdě prosazuji návrat k tomu původnímu smyslu. Pro to byl ten název vymyšlen. Že tím dnes většina lidí myslí C++ nebo Javu je jen důkazem, že to celé vůbec nepochopili (včetně tvůrců těch jazyků). Současné mainstreamové pojetí je cargo kult jak vyšitý.

Ono to taky vychází z toho, že si vybrali fakt blbý název. Všude kromě OOP se "objekt" říká něčemu, co rozumí akorát tak zprávě "zůstaň". Jestli by nebylo lepší se vrátit k původní myšlence s nějakým lepším jménem.

[Kadet]

Dokazal byste nekdo nadefinovat oop? Lidi se tu ztraci v semantice.

Ne. Každý si pod tím představuje trochu něco jiného. Pro mě to je to, co tím mysleli otcové-zakladatelé, tj. Alan Kay a spol.

Alan Kay ma svoji definici kterou neustale omila a nikdo ji nechape. Precet jsem o tom neapocer jeho komentaru i posledni clanky na quore a HN kam prispiva. Rad bych, aby tu jeho definici nekdo tady vysvetlil, nez se budem bavit dal.

[Kit]

Ja pracujem na projekte kde oop je dost zastupene a tolko abstrakcie som este nikde nevidel a mam pocit, ze je to niekedy az prekomplikovane a uplne zbytocne.

Také jsem dělal na projektu, ve kterém byla použita čtyřúrovňová dědičnost, ve které prarodičem byla třída Config. No prostě hnus. A když jsem se ozval, že je to kravina, tak se to vedení nelíbilo.

[Reklama]

[Mirek Prýmek]

Jestli by nebylo lepší se vrátit k původní myšlence s nějakým lepším jménem.

No to je právě ten "agent" nebo "actor" Lepší je imho "actor". Sice to zní trochu exoticky, ale "agent" na sebe nabaluje speciální význam, který mu byl dán v podoboru "multiagentní systémy" (takže různé ty komunikační jazyky KQML, ACL, sémantiky/ontologie atd.)

Když místo "programuju objektově" řekneš "programuju pomocí actorů", bude jasný, že nemyslíš to zparchantělý rádobyOOP

[Kiwi]

Dokazal byste nekdo nadefinovat oop? Lidi se tu ztraci v semantice.

Ne. Každý si pod tím představuje trochu něco jiného. Pro mě to je to, co tím mysleli otcové-zakladatelé, tj. Alan Kay a spol.

Alan Kay ma svoji definici kterou neustale omila a nikdo ji nechape. Precet jsem o tom neapocer jeho komentaru i posledni clanky na quore a HN kam prispiva. Rad bych, aby tu jeho definici nekdo tady vysvetlil, nez se budem bavit dal.

Se mi líbí, jak když někdo něco nepochopí, tak tvrdí, že to "nikdo" nechápe. Čemu přesně nerozumíš?

[Kadet]

To je dobre ze tomu nekdo jako ty rozumi.
Vysvetli mi tedy

- svoji definici oop
- priklad systemu co hodne lidi zna co je oop
- na ktery pripady bys pouzil oop jestli vubec
- kterej programovaci jazyk je skutecne oop. Nebo kterej byl jestli vubec kdy byl

[Kiwi]

To je dobre ze tomu nekdo jako ty rozumi.
Vysvetli mi tedy

- svoji definici oop
- priklad systemu co hodne lidi zna co je oop
- na ktery pripady bys pouzil oop jestli vubec
- kterej programovaci jazyk je skutecne oop. Nebo kterej byl jestli vubec kdy byl

- objekt jako černá krabička, která může mít stav, přijímá a vysílá zprávy, pomocí nichž interaguje s okolím; množina zpráv na něž reaguje a způsob jak tak činí je čistě v gesci objektu (může se to v čase i měnit)
- použil bych ho u problémů, které se přirozeně rozpadají na autonomní podproblémy a je účelné je na tyto autonomní jednotky separovat z důvodů přehlednosti, substituovatelnosti, znovupoužitelnosti a testování
- Smalltalk

[JSH]

- použil bych ho u problémů, které se přirozeně rozpadají na autonomní podproblémy a je účelné je na tyto autonomní jednotky separovat z důvodů přehlednosti, substituovatelnosti, znovupoužitelnosti a testování

Popravdě, tohle toho moc neříká. Dělit problémy na menší a jednodušší kusy se snaží úplně všechna paradigmata. Je to akorát rozkecané "použil bych ho tam, kde se hodí". Někdo, komu OOP několikrát nebouchlo do obličeje, ví kulové, kdy je to účelné a kdy není.

[rigormortiz]

Prijde mi, ze do jiste miry je spise problem business logic nez OOP jako takove. Ono to totiz svadi prevadet "firemni procesy" do "trid" a reflektovat/popisovat realitu v programovacim jazyku.

Bez ohledu na to jaky mate oblibeny programovaci jazyk doporucuju bez predsudku precist a nechat se treba i inspirovat:

https://rubyonrails.org/doctrine/
http://trailblazer.to/ potazmo http://trailblazer.to/gems/cells/

Filozofie neni vylozene zavisla na jazyku, tak snad aspon nekomu to rozsiri obzory. Kdyz se spravne nacrtne business logika a rozume se to prevede do OOP tak polymorfizmus je rozhodne dobry pristup, jenom se to nesmi prehanet, protoze pak opravdu muze dojit ke snizeni citelnosti nebo testovatelnosti kodu. Proste vseho s mirou a "overthinking" je fakt problem hodne lidi.

Ja doufam, ze vetsina je aspon trochu rozumna a chape, ze krasnej a citelnej kod nemusi bejt zrovna ten nejefektivnejsi. Dalsi oblibena vec je "code reusability" coz neni uplne sranda udelat, aby se vam to po pridani par novejch ficurek nezacalo rozpadat nebo molochovatet. Dalsi kamen urazu, ze kteryho obvinuju vetsinou "byznysaky", ze PoC neni produkt. Sice zbastlite za par hodin neco co by chteli, ale muze trvat dny i tydny to naimplementovat spravne, jenze vime jak to je s "pridelovanim prostredku". Treba VW a jejich pr**er s "klicema" .... Aneb z PoC jsme udelali produkt. Gratuluju.

Jinak vidime to napr. i v Linuxu, prechod od init scriptu k systemd nebo treba v gnome, kdy gconf je do jiste miry lehka forma registru podobne jak ve windowsech. Proste kdyz vam aplikace roste tak v urcite fazi nechcete mit vsechno v tisici konfigurakach kde ma kazdej dva az tri radky, jelikoz mate vysoce modularni pristup. Nakonec to soupnete nekam do "databaze", aby se vam s tim lip pracovalo. Cili ten pristup je definovanej velikosti aplikace a jejim designem (monolith vs atomic) atd. ....

[Kiwi]

- použil bych ho u problémů, které se přirozeně rozpadají na autonomní podproblémy a je účelné je na tyto autonomní jednotky separovat z důvodů přehlednosti, substituovatelnosti, znovupoužitelnosti a testování

Popravdě, tohle toho moc neříká. Dělit problémy na menší a jednodušší kusy se snaží úplně všechna paradigmata. Je to akorát rozkecané "použil bych ho tam, kde se hodí". Někdo, komu OOP několikrát nebouchlo do obličeje, ví kulové, kdy je to účelné a kdy není.

To ano, ale tady jsem měl na mysli právě tu autonomii. Že sám o sobě je ten objekt "životaschopný". Pokud použiju klasickou strukturovanou dekompozici, tak toto nezbytně neplatí (dokonce to bude platit málokdy).

[Kadet]

To je dobre ze tomu nekdo jako ty rozumi.
Vysvetli mi tedy

- svoji definici oop
- priklad systemu co hodne lidi zna co je oop
- na ktery pripady bys pouzil oop jestli vubec
- kterej programovaci jazyk je skutecne oop. Nebo kterej byl jestli vubec kdy byl

- objekt jako černá krabička, která může mít stav, přijímá a vysílá zprávy, pomocí nichž interaguje s okolím; množina zpráv na něž reaguje a způsob jak tak činí je čistě v gesci objektu (může se to v čase i měnit)
- použil bych ho u problémů, které se přirozeně rozpadají na autonomní podproblémy a je účelné je na tyto autonomní jednotky separovat z důvodů přehlednosti, substituovatelnosti, znovupoužitelnosti a testování
- Smalltalk

Diky, od toho se da odpichnout.

Objekt jako cerna krabicka prijimajici a vysilajici zpravy.

Zastavi se zbytek sveta v case zatimco jeden objekt zpracovava zpravu?

Pokud jo, pak je to oop ve smyslu synchronni simulace. Smalltalk to splnuje. Java a CPP, pokud si odmyslim tu michaninu objektu a modulu, tak taky.

Pokud kazdej objekt funguje nezavisle, tj. ve vlastnim vlakne, s tim ze jeden objekt neblokuje ostatni, tak se tomu rika mimo jine asynchronni simulace, actor model, reaktivni programovani?, gen_server, erlang nebo mikrojadro operacniho systemu.

Alan Kay nekde zminil explicitni cas, proto rikam, ze to co tim svym oop myslel, nikdo nechape. Proto druha otazka. Jak je definovan cas v tomhle oop?

Nejaky systemovy hodiny? Pak je to obycejna real time simulace. Taky se tomu rika operacni system.

Nebo explicitne definovanej cas? Pak se daji vsechny zpravy ktery objekty prijimaji a odesilaji reprezentovat jako data s explicitnim timestampem. Jediny co ukladas jsou tyhle zpravy. To co pak provedou s vnitrnim stavem objektu muzes vzdycky prehrat od zacatku pokud si uchovas log tech zprav. Rika se tomu event sourcing, v databazich write ahead logging, journaling.

A ted moje definice oop. Oop jak ho lidi chapou je management stavu systemu v case. Stav je explicitne ulozen v pameti/disku/databazi a prichozi a odchozi zpravy jsou prchave, tj. fire and forget. Jinak receno staticky pohled na system a da se modelovat pomoci treba UML.

Dualem tohoto pohledu je explicitni uchovavani zprav/eventu v pameti/disku/databazi a stav objektu je prchavy, protoze muze byt vzdy prehran od zacatku historie diky tomu, ze je ulozen log vsech modifikaci jeho stavu. Jinak receno data flow pohled na system.

[Bacsa]

- kterej programovaci jazyk je skutecne oop. Nebo kterej byl jestli vubec kdy byl

Objective-C

[Kiwi]

IMHO to není třeba stavět takto kategoricky. To zase zavání nějakým dogmatismem. Nikde není řečeno, že musí jít o synchronní nebo o asynchronní model. Nejspíš ve většině případů půjde o synchronní přístup, v případech, kdy je to účelné/nezbytné, si konkrétní objekty budou žít ve vlastním čase. Nevidím moc smysl dělat z toho zbytečnou vědu.

Rozdíl oproti C++like jazykům vidím hlavně v eleganci, s jakou je to řešené. Předně dynamické typování vnímám jako nezbytnost pro objektový přístup. Bez toho podle mě není možné efektivně dosáhnout těch správných efektů, resp. statickým typováním se to všechno šíleně zamotá a znepřehlední. Tím se nabourává ta absolutní autonomie objektů.