Vlákno názorů k článku
Kritika objektového programování: je to katastrofa? od Ondřej Novák - Problém OOP vidím spíš v tom, že ho...

Problém OOP vidím spíš v tom, že ho nikdo pořádně neumí. A i když už ví vo co go, tak ho neumí správně a efektivně použít. Tím neříkám, že třeba já jsem výjimka.

OOP neberu jako dogma, jen jako forma pohledu. Objektově jsem programovál v době, kdy jsem OOP neznal. Jen jsem si to neuvědomoval. Tíhnul jsem k vytváření instancí, černých soběstačných krabiček, které lze snadno instanciovat. Samostatně fungujících jednotek, které standardním způsobem komunikují s okolím a imitují vztahy mezi lidma.

Příchodem lambda funkcí zejména v javascriptu ale i v C++ je to opět posunuto trochu jinam... jenže... ona taková funkce může být chápána jako objekt. Nezřdka kdy přepisuju funkce na rozhraní, protože prostě jedna funkce je málo na nějaký obecnější vyjádření. Jindy zase přizpůsobuju objekty, aby dobře pracovaly jak s objektem, tak s funkcí. V javascriptu může mít funkce vnitřní stav.

function create_counter(start) {
   var cnt = start;
   return function() {return cnt++;}
}

var counter = create_counter(10);
console.log(counter());
console.log(counter());
console.log(counter());

Je to funkce nebo objekt?

Pokud tento objekt voláním přijme message, aby vrátil jako výsledek jinou message, je to objekt. Je to jen úhel pohledu.

Totálne si to nepochopil. Nekritizuje to bunka A posle data bunke B ale kritizuje cely ten nezmysel čo je v Jave. Tvoj priklad je navyše nezmyselný, lebo ani nevieš čo je a čo neni OOP, porovnavaš OOP s OOP a na jedno OOP nadavas zatial co druhe vyzdvihujes, ale pri tom je to ten isty OOP. Až bys vyskúšal Golang, Ruby, ERLang a pod. a psal bys neOOP, pochopil by si jak moc je OOP v podobe javy nezmyselné, už to kolik design patternov potřebuješ vedieť abys to OOP samotne docielil svedčí o tom že celú prácu to komplikuje.

> kolik design patternov potřebuješ vedieť abys to OOP samotne docielil
Ani jeden, programovat objektovo mozete aj bez patternov. Asi ste to cele naozaj nepochopil.

Tys to nepochopil. Ne bez patternov to nejde, pokiaľ sa jedná čo i len o trocha komplexnejší projekt. Když sa pokúšaš o to to psať bez patternov, pak to vyzerá tak že všade sa len kód "hackuje" a "ohýba" a když máš projekt s 20 tisíc riadkami kódu s 80 triedami, s 500 metodami, tak jedna metóda ovplivní funkčnosť polovice tried, metód a kódu. Chceš osoliť hranolky a odpáliš nukleárnu bombu. Kdyby to šlo bez design patternov, proč by boli vôbec vymyslené?

23. 7. 2019, 13:17 editováno autorem komentáře

Dobry kod sa da napisat aj bez patternov. Ak si dobry programator ten pattern sa ti tam objavi sam. Ak nie, tak si mozes pomoct patternom a nemusis vymyslat vymyslene.

Java jako jazyk není ten problém. Tam se dá pracovat i bez nesmyslných getterů a setterů. Jen ten EE ekosystém je kolem toho celý postavený :/

To je kombinace důvodů číslo tři a čtyři, na mém osobním seznamu důvodů, proč neprogramuju weby.

Jakože, je hezké, že se takhle dá programovat, ale do produkce to nepatří. Pokud to někdo používá, tak chudáci kolegové a chudák jeho budoucí já.

myslíte counter? No to byl příklad. Ale já takle mám dělané streamy.

function parse(stream) {... whatever....}

function create_string_stream(string) {
    var s = string;
    var l = string.length;
    var i = 0;
    return function() {
          if (i >= l) return null; else return s.charAt(i++);
   }
}

$ var s = create_string_stream("hello world")
undefined
$ s()
"h"
$ s()
"e"
$ s()
"l"
$ s()
"l"
$ s()
"o"
$ s()
" "
$ s()
"w"
$ s()
"o"
$ s()
"r"
$ s()
"l"
$ s()
"d"
$ s()
null
$ s()
null

Zkuste si v prohlížeči. Parser samozřejmě očekává funkci co vrací další znak dokud není konec streamu. Mam plnou svobodu mu jako zdroj znaků poskytnout cokoliv.

Jinak používám javascript k vyjádření algoritmu. Všechny tyhle postupy používám v C++. Ale to si asi těžko vyzkoušíte

To ti gratuluju. Místo abys použil class, tak jsi ušetřil pár znaků za cenu přehlednosti.

24. 7. 2019, 14:42 editováno autorem komentáře

U class bych musel vymýšlet rozhraní. musel bych pak dědit ten class - moc komplikovaný

takhle mohu napsat

parse(function() {
 //...
return ...
})

a vyšvihnout tam inline generátor. Jde o to, že rozhraní je jasně daný. Je to funkce, volá se bez parametrů a vrací další znak. string_stream je jen jedna možná implementace. Čtení ze souboru bude vypadat jinak ale bude mít stejně jednoduché rozhraní.

Zápis do streamu je zase funkce, která přijímá znak. Případně null (zapíše EOF)

k tomu v JS i jiných jazycích slouží generátory.

Jenže v C++ standardně ještě nejsou (až C++20). Jinak generátory jsem měl ve svých knihovnách už někdy v roce 2008 pomocí windows fiberů a v linuxu make_context a set_context. Ale nikdy jsem je nepotřeboval, vždycky se to dalo napsat jinak.

Funkce nemůže mít „vnitřní stav“, funkce může mít jen kontext, to je tento případ.

V případě, že bychom připustili, že counter je objekt s jedinou metodou, jejíž desktiptor se tudíž při posílání zprávy neuvádí, tak by to OOP sice připomínalo, ale OOP to vlastně není, protože klíčovou vlastností je, že objekt může přijmout JAKOUKOLIV zprávu a zpracovat ji. To zde neplatí.
Kdyby return vracel dictionary funkcí, pak by bylo možno uvedením názvu jednotlivé spouštět, ale opět by to nebylo OOP, protože situaci, kdy se odkážeme na neexistující položku dictionary, nevede na zachycení neznámého deskriptoru metody a vyřešení situace „objektem“.

Závěr: Tohle OOP není.

Asi jsem totálně mimo. Funkce že nemůže mít vnitřní stav? A co tedy vidíte?

Ale jo, rozumím tomu, že "správně zadefinovaná" funkce nesmí mít vnitřní stav. Ale běžně píšu funkce a potažno lambda funkce, který běžný vnitřní stav mají. Je to OOP programování nebo funkcionální programování?

vemte si objekt. Objekt příjme zprávu, a zpracuje ji, eventuálně generuje další zprávy na jíne objekty.

function vytvor_objekt(params) {
    var vnitrni_stav = params;
   return function(zprava) {
       switch (zprava.nazev) {
           case "get" : return vnitrni_stav;
           case "set" : vnitrni_stav = zprava.hodnota;return;
           default: return "neumim";
       }
  }
}

$ var obj = vytvor_objekt(10)
undefined
$ obj({nazev:"get"})
10
$ obj({nazev:"set", hodnota:20})
undefined
$ obj({nazev:"get"})
20
$obj({nazev:"aaa"})
"neumim"

Je to funkce nebo objekt? Přijímá to zprávy, zapouzdřuje to vnitřní stav, dědičnost by se dala udělat dekompozicí (prostě by potomek do vnitřního stavu zahrnul předka a neznámé zprávy by forwardoval předkovi) a to by řešilo i polymorfismus.

Pořád ne? Musíte mít na to úředně razítko, nebo umíte změnit úhel pohledu? O tom to totiž je

Je to uzávěr, ne funkce s vnitřním stavem (interně nějaká struktura s funkcí a ukazatelem na její okolí, což mimochodem komplikuje vůbec základní způsob práce s těmito strukturami).

Jinak to myslíš a píšeš dobře, jen nepoužíváš správnou terminologii a lidi se na to chytají (a mají taky pravdu).

Nechme ale mluvit klasika nejklasičtějšího:

The venerable master Qc Na was walking with his student, Anton. Hoping to
prompt the master into a discussion, Anton said "Master, I have heard that
objects are a very good thing - is this true?" Qc Na looked pityingly at
his student and replied, "Foolish pupil - objects are merely a poor man's
closures."

Chastised, Anton took his leave from his master and returned to his cell,
intent on studying closures. He carefully read the entire "Lambda: The
Ultimate..." series of papers and its cousins, and implemented a small
Scheme interpreter with a closure-based object system. He learned much, and
looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by
saying "Master, I have diligently studied the matter, and now understand
that objects are truly a poor man's closures." Qc Na responded by hitting
Anton with his stick, saying "When will you learn? Closures are a poor man's
object." At that moment, Anton became enlightened.

No jo, uzávěry a λ-funkce si plete kdekdo. To podobenství je výstižné, hlavně v C++ s jeho “funktory.”

Hm, asi mi něco chybí, abych mohl být enlightened. Takže bych prosil vysvětlení.

Jo, tohle už je (na rozdíl od předchozího příkladu!) objekt, ani do toho nemusíte míchat dědičnost.

Je to uzávěr :-)

λ-funkce není objekt, ale tvoří ve spojení s kontextem uzávěr (closure), který už regulérním objektem je.

Super. Jak taková uzávěra přijímá zprávy, a to libovolné? Nebo se bavíte o implementaci uzávěry pomocí objektu? To je ale něco jiného.