Čada: Objektové programování

SB

Re:Čada: Objektové programování
« Odpověď #30 kdy: 17. 06. 2015, 15:16:54 »
Celé nedorozumění spočívá v tom, že tito a podobní autoři dodnes nepochopili, že původní OOP a dnešní OOP v C++ C# Java jsou dvě různé záležitosti a neustále tak matou laickou veřejnost. Je to zasílání asynchronních zpráv procesům proti synchronnímu volání funkcí alias metod v jednom vlákně.

Nevím o tom, že by to nějaký z vámi zmiňovaných hybridů uměl bez „homogenizátorů“ (jak taky).

Nevím o tom, že by někdo tvrdil že to umí :) Naopak všichni ví že to neumí, že se tam proto pořádný moloch CORBA musí dopsat ručně a to proto že v jazyku není podpora na zasílání zpráv objektům.

1. Nikdo se tu nehádá, že původní OOP mělo být asynchronní a všechny implementace jsou synchronní, a taky to neznamená, že nemůžou objekty komunikovat asynchronně. Svár spočívá v skutečnosti, jak snadno či těžko se v kterých jazycích vytváří objektový model a že někteří autoři nepochopili, které vlastnosti implementace OOP modelování pomáhají a které škodí.
2. CORBu jsem uvedl jako příklad, a je úplně šumák, jak je realizovaná či funkční, jako ukázka nutnosti přemostění nehomogenního prostředí stačí. Objektové jazyky samozřejmě zasílání zpráv objektům mají, ale v homogenním prostředí. Ale to už jsem říkal!


l

Re:Čada: Objektové programování
« Odpověď #31 kdy: 17. 06. 2015, 15:48:41 »
Svár spočívá v skutečnosti, jak snadno či těžko se v kterých jazycích vytváří objektový model a že někteří autoři nepochopili, které vlastnosti implementace OOP modelování pomáhají a které škodí.

Mě se zdá že podstata sváru je vágnost definice "objektový model" :) Dokud byl objekt synonymum pro strukturu s přibastlenými metodami, vtable, konstruktorem, destruktorem, bylo jasno a sváry nebyly :)

Jann

Re:Čada: Objektové programování
« Odpověď #32 kdy: 17. 06. 2015, 16:07:00 »
Svár spočívá v skutečnosti, jak snadno či těžko se v kterých jazycích vytváří objektový model a že někteří autoři nepochopili, které vlastnosti implementace OOP modelování pomáhají a které škodí.

Mě se zdá že podstata sváru je vágnost definice "objektový model" :) Dokud byl objekt synonymum pro strukturu s přibastlenými metodami, vtable, konstruktorem, destruktorem, bylo jasno a sváry nebyly :)

To nebylo jasno nikdy, resp. mohlo se to zdát být jasné těm, kteří si pod OOP dokázali představit jen to, co píšeš, protože o OOP očividně mnoho nevěděli. Rozšířil se totiž blud, že "OOP = zapouzdření + dědičnost". Jenže realita je taková, že "OOP = polymorfismus + pozdní vazba" a otázkou zůstává, jak ten polymorfismus a pozdní vazbu implementovat. Některé jazyky na to šly přes dědění, zapouzdření, přetěžování a VFT, jiné se vydaly cestou zasílání zpráv (způsob jejichž zpracování je vnitřní záležitostí objektu, včetně typu vrácené hodnoty), jiné cestou generických funkcí, ležících zcela mimo hierarchii tříd. První přístup se rozšířil nejvíce, jenže má také nejvíce slabých míst a přísně vzato ani není schopen splnit "definiční požadavky" OOP (polymorfismus + (extrémně) pozdní vazbu).

SB

Re:Čada: Objektové programování
« Odpověď #33 kdy: 17. 06. 2015, 16:48:59 »
...že "OOP = zapouzdření + dědičnost". Jenže realita je taková, že "OOP = polymorfismus + pozdní vazba" ...

Pozor, mezi ZÁKLADNÍ vlastnosti určitě patří i to zapouzdření, je to nutným požadavkem pro zajištění konzistence stavů a zabránění objektovým orgiím.
Na druhou stranu dědičnost tam určitě nepatří - prototypované jazyky ji nemají a je možno ji nahradit delegací.

...jak ten polymorfismus a pozdní vazbu implementovat. Některé jazyky na to šly přes dědění, zapouzdření, přetěžování a VFT, jiné se vydaly cestou zasílání zpráv (způsob jejichž zpracování je vnitřní záležitostí objektu, včetně typu vrácené hodnoty), jiné cestou generických funkcí, ležících zcela mimo hierarchii tříd. První přístup se rozšířil nejvíce, jenže má také nejvíce slabých míst a přísně vzato ani není schopen splnit "definiční požadavky" OOP (polymorfismus + (extrémně) pozdní vazbu).

Asi těžko půjde implementovat odpovědnost za zpracování zprávy voláním místo zasílání, když o zpracování rozhoduje objekt. Takže zrovna volání x zasílání je dost důležitý implementační detail.

JSH

Re:Čada: Objektové programování
« Odpověď #34 kdy: 17. 06. 2015, 17:16:35 »
Asi těžko půjde implementovat odpovědnost za zpracování zprávy voláním místo zasílání, když o zpracování rozhoduje objekt. Takže zrovna volání x zasílání je dost důležitý implementační detail.
Tady se úplně nechytám. Nevidím tam až tak zásadní rozdíl. Při posílání zprávy se podle typu objektu vybere funkce k zavolání (koukneme do hashmapy). Při volání metody se podle typu objektu vybere funkce k zavolání (koukneme do vtable). Jediný rozdíl vidím v tom, že při posílání zpráv může objekt všechny neznámé zprávy někam přeposlat. U mainstream oop to neprojde překladem. Jo, principielně v jednom případě rozhoduje volající a v druhém volaný, ale výsledek je prakticky na jedno kopyto.
V čem se pletu?


l

Re:Čada: Objektové programování
« Odpověď #35 kdy: 17. 06. 2015, 17:30:17 »
"definiční požadavky" OOP (polymorfismus + (extrémně) pozdní vazbu)

Jasná otázka "polymorfismus + (extrémně) pozdní vazba", má jasnou odpověď: Dávno to máte před sebou, třeba C# s MethodBase.Invoke.
Bohužel extrémně pozdní vazba je v praxi kontraproduktivní, doufám že mě nebudete přesvědčovat že je v pořádku kontrolovat překlepy v názvech metod až za běhu. Jsou výjimky a jednou z výjimek je inter-process komunikace. Je to náhoda nebo logický důsledek, že všechno co se točí kolem "správného OOP" vždy skončí u inter-process komunikace ? :)

rootacek

  • *
  • 47
  • Linux je dobrá volba, Windows je cesta do pekla!
    • Zobrazit profil
    • E-mail
Re:Čada: Objektové programování
« Odpověď #36 kdy: 18. 06. 2015, 00:54:55 »
Protože to "praktické OOP" není žádné OOP, ale hromada sr...k, slepá cesta vývoje programování, jeden obrovský omyl, něco, co by se mělo aktivně potírat, jako se kdysi potíral příkaz GOTO. Je to programovací styl lidí, kteří v IT nemají co dělat a mnohem lépe by udělali jak pro sebe, tak pro IT, kdyby raději prodávali brambory na tržišti nebo je okopávali na poli nebo tak něco adekvátního. Ono "praktické OOP" selhává v podstatě ve všem, co si OOP původně bralo za cíl řešit: halda zcela zbytečného syntaktického balastu, z níž vzniká ještě větší halda nepřehledného balastního kódu, který v praxi vůbec není znovupoužitelný, je spjatý s hromadou zbytečných mechanismů, s nimiž musejí překladače počítat a výsledkem jejich práce je pak mimořádně nenažraný, pomalý kód..

Jsem rád, že tady jsou lidi s tímto názorem.Nejlepší je, že spoléhajíci na OOP, ale bez procedurálu či paradigmat by to neexistovalo...
Ja bych řekl, že oop, je líné programování.A o dost jednodušší a v podstatě z programátora se stává ovce, která vlastně programovat neumí umí jen
Kód: [Vybrat]
$this->result(); např možná :) .


SB

Re:Čada: Objektové programování
« Odpověď #37 kdy: 18. 06. 2015, 08:13:12 »
Asi těžko půjde implementovat odpovědnost za zpracování zprávy voláním místo zasílání, když o zpracování rozhoduje objekt. Takže zrovna volání x zasílání je dost důležitý implementační detail.
Tady se úplně nechytám. Nevidím tam až tak zásadní rozdíl. Při posílání zprávy se podle typu objektu vybere funkce k zavolání (koukneme do hashmapy). Při volání metody se podle typu objektu vybere funkce k zavolání (koukneme do vtable). Jediný rozdíl vidím v tom, že při posílání zpráv může objekt všechny neznámé zprávy někam přeposlat. U mainstream oop to neprojde překladem. Jo, principielně v jednom případě rozhoduje volající a v druhém volaný, ale výsledek je prakticky na jedno kopyto.
V čem se pletu?

Jde o ty neznámé zprávy. Ale to by asi šlo ojebat posíláním metodě doesNotUnderstand, když existuje, nebo vybořit. Takže asi implementovat daný koncept by nějak šlo. Každopádně je to dost důležité.

SB

Re:Čada: Objektové programování
« Odpověď #38 kdy: 18. 06. 2015, 08:45:04 »
Jasná otázka "polymorfismus + (extrémně) pozdní vazba", má jasnou odpověď: Dávno to máte před sebou, třeba C# s MethodBase.Invoke...

Jo, a takhle je to v hybridních jazycích s deklarativními třídami se vším, reflexe se patlá jakousi zalomenou knihovnou a imperativně. Ve Smalltalku stačí jednoduché
<objekt> perform: <zpráva> with: <případný parametr>.

...Bohužel extrémně pozdní vazba je v praxi kontraproduktivní, doufám že mě nebudete přesvědčovat že je v pořádku kontrolovat překlepy v názvech metod až za běhu. Jsou výjimky a jednou z výjimek je inter-process komunikace. Je to náhoda nebo logický důsledek, že všechno co se točí kolem "správného OOP" vždy skončí u inter-process komunikace ? :)

Je asi tak kontraproduktivní, že dokáže v případech, kdy je to třeba, značně zjednodušit návrh. Na druhou stranu nadužívání není vyžadováno.
S meziprocesovou komunikací nemám zkušenost, tam nemůžu posuzovat. Můžete klidně přiblížit problém.

SB

Re:Čada: Objektové programování
« Odpověď #39 kdy: 18. 06. 2015, 09:02:56 »
Jsem rád, že tady jsou lidi s tímto názorem.Nejlepší je, že spoléhajíci na OOP, ale bez procedurálu či paradigmat by to neexistovalo...
Ja bych řekl, že oop, je líné programování.A o dost jednodušší a v podstatě z programátora se stává ovce, která vlastně programovat neumí umí jen
Kód: [Vybrat]
$this->result(); např možná :) .

Přibližte mi, co je na Smalltalku procedurálního, to mě hodně zajímá...
Jaká paradigmata máte na mysli?
OOP je v první řadě systém organizace modelu a jeho výpočtu, který má zjednodušit vedení velkých projektů. To samo o sobě neznamená, že by vývojář nemusel přemýšlet. Důkazem je mi právě ona praxe, kdy drtivá většina vývojářů není schopna vytvořit objektový model dané domény. Takže ono to pro úplné blbce asi nebude, spíš se potkávám s těmi nasranými, že jim to nejde.

perceptron

Re:Čada: Objektové programování
« Odpověď #40 kdy: 18. 06. 2015, 10:04:32 »
Citace
Je to programovací styl lidí, kteří v IT nemají co dělat a mnohem lépe by udělali jak pro sebe, tak pro IT, kdyby raději prodávali brambory na tržišti nebo je okopávali na poli nebo tak něco adekvátního.
rofl to je nazor jak z pivnice.

vyhodime tu kopu kodu zrusime oop jazyky a pojdeme rubat c, abap, perl a erlang.



resp pojdeme rubat aktor model ako je napr v akke lebo ten obviouzly splna tie poziadavky

l

Re:Čada: Objektové programování
« Odpověď #41 kdy: 18. 06. 2015, 11:17:07 »
Jo, a takhle je to v hybridních jazycích s deklarativními třídami se vším, reflexe se patlá jakousi zalomenou knihovnou a imperativně.

Luxus to není, dostačuje na zamýšlený účel.

Je asi tak kontraproduktivní, že dokáže v případech, kdy je to třeba, značně zjednodušit návrh. Na druhou stranu nadužívání není vyžadováno.

Jsem ochoten připustit, že sem tam existuje případ kdy se to může hodit a těchto pár případů se vyřeší alternativně třeba přes reflexi. Trvám na tom že výchozí chování OOP (uvnitř jednoho procesu) nemůže být extrémně pozdní vazba.

OOP je v první řadě systém organizace modelu a jeho výpočtu, který má zjednodušit vedení velkých projektů.

A jsme opět u toho, že podstata sváru je vágnost definice "objektový model" :) Zjevně co člověk to názor :)

SB

Re:Čada: Objektové programování
« Odpověď #42 kdy: 18. 06. 2015, 12:22:31 »
Jo, a takhle je to v hybridních jazycích s deklarativními třídami se vším, reflexe se patlá jakousi zalomenou knihovnou a imperativně.

Luxus to není, dostačuje na zamýšlený účel.

Je asi tak kontraproduktivní, že dokáže v případech, kdy je to třeba, značně zjednodušit návrh. Na druhou stranu nadužívání není vyžadováno.

Jsem ochoten připustit, že sem tam existuje případ kdy se to může hodit a těchto pár případů se vyřeší alternativně třeba přes reflexi. Trvám na tom že výchozí chování OOP (uvnitř jednoho procesu) nemůže být extrémně pozdní vazba.

OOP je v první řadě systém organizace modelu a jeho výpočtu, který má zjednodušit vedení velkých projektů.

A jsme opět u toho, že podstata sváru je vágnost definice "objektový model" :) Zjevně co člověk to názor :)

Na zamýšlený účel dostačuje i procedurální členění, ale spravovatelnější to nebude.

Pozdní vazba je univerzální, jde s ní udělat víc než s časnou, proto její volba v jazyku při zachování jeho jednoduchosti.

Tak ono už jenom zapouzdření znamená mimořádný nárůst izolace částí modelu. Dá se využít někde mimo objektový model?

l

Re:Čada: Objektové programování
« Odpověď #43 kdy: 18. 06. 2015, 14:03:26 »
Pozdní vazba je univerzální, jde s ní udělat víc než s časnou

Jestli chcete donekonečna obhajovat hledání metod podle názvu za běhu, tak s Váma končím, tato myšlenka je zcela pomýlená. Na odůvodněné případy stačí reflexe.

JSH

Re:Čada: Objektové programování
« Odpověď #44 kdy: 18. 06. 2015, 14:21:39 »
Tak ono už jenom zapouzdření znamená mimořádný nárůst izolace částí modelu. Dá se využít někde mimo objektový model?
:o Třeba tak nějak úplně všude? Nesetkal jsem se s jazykem, ve kterém by se nedaly detaily schovat za nějaké rozhraní.