Výběr vhodného OOP jazyka

Onestone

Re:Výběr vhodného OOP jazyka
« Odpověď #135 kdy: 07. 06. 2018, 10:39:02 »
Zapouzdření hlavně vůbec nesouvisí s OOP.
Souvisí. Hlavně je však potřebné vědět, co je to zapouzdření.
To je dost logické. Pak právě člověk ví, že nesouvisí ;)

OOP bez zapouzdreni asi neni uplne koser, ale spousta lidi netusi, ze treba ve funkcionalnim Haskellu je mozne pomoci modulu dosahnout prakticky tehoz - s danym typem muze pracovat jenom dotycny modul, kdyz se z modulu nevyexportuje informace o vnitrku toho typu, proste se dovnitr funkce z jineho modulu vubec nepodiva.

Tudiz bych trval na tom, ze zapouzdreni neni to, co dela OOP. Natoz aby bylo jeho vysadou.
Ano, tak nějak. Zapouzdření a OOP jsou dva ortogonální koncepty. Pojem OOP jako takový jen zastřešuje vlastnosti jako polymorfismus a sloučení dat s relevantními funkcemi. Javistům to ale vysvětlit nejde, protože Dunning-Kruger. O PHPčkářích už vůbec nemluvě...


Kit

Re:Výběr vhodného OOP jazyka
« Odpověď #136 kdy: 07. 06. 2018, 10:49:29 »
Pojem OOP jako takový jen zastřešuje vlastnosti jako polymorfismus a sloučení dat s relevantními funkcemi. Javistům to ale vysvětlit nejde, protože Dunning-Kruger. O PHPčkářích už vůbec nemluvě...

Sloučení dat s relevantními funkcemi je právě to zapouzdření.

Onestone

Re:Výběr vhodného OOP jazyka
« Odpověď #137 kdy: 07. 06. 2018, 11:06:31 »
Pojem OOP jako takový jen zastřešuje vlastnosti jako polymorfismus a sloučení dat s relevantními funkcemi. Javistům to ale vysvětlit nejde, protože Dunning-Kruger. O PHPčkářích už vůbec nemluvě...

Sloučení dat s relevantními funkcemi je právě to zapouzdření.
Ne, to není.

Re:Výběr vhodného OOP jazyka
« Odpověď #138 kdy: 07. 06. 2018, 12:18:53 »
Ano, tak nějak. Zapouzdření a OOP jsou dva ortogonální koncepty. Pojem OOP jako takový jen zastřešuje vlastnosti jako polymorfismus a sloučení dat s relevantními funkcemi. Javistům to ale vysvětlit nejde, protože Dunning-Kruger. O PHPčkářích už vůbec nemluvě...

Tak sem si cetl o te studii a pokusu co Dunning a Kruger udelali. Jestli jsem to pochopil spravne tak prave potom co ty nekompetentni byli pouceni tak se jejich sebehodnoceni i uroven kompetence zlepsily.
Takze jestli radis javisty do skupiny nekompetentnich tak podle Dunning-Kruger by prave vysvetleni melo pomoci.
Pokud radis javisty do skupiny kompetentnich tak to asi vysvetlovat nebudou potrebovat.

ava

Re:Výběr vhodného OOP jazyka
« Odpověď #139 kdy: 07. 06. 2018, 13:49:29 »
Pojem OOP jako takový jen zastřešuje vlastnosti jako polymorfismus a sloučení dat s relevantními funkcemi. Javistům to ale vysvětlit nejde, protože Dunning-Kruger. O PHPčkářích už vůbec nemluvě...

Sloučení dat s relevantními funkcemi je právě to zapouzdření.
Ne, to není.

Mohl by ses teda konečně vymáčknout, co podle tebe zapouzdření je, místo toho aby jsi jen říkal "tohle ne, tohle taky ne"?

Wikipedia říká: In object oriented programming languages, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination[1][2] thereof:

     - A language mechanism for restricting direct access to some of the object's components.[3][4]
     - A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.[5][6]

to druhé to podle tebe není, takže ty za zapouzdření považuješ tu první odrážku? Nebo máš nějakou vlastní definici?


SB

Re:Výběr vhodného OOP jazyka
« Odpověď #140 kdy: 08. 06. 2018, 09:01:38 »
Z návrhových vzorů řešících nedostatky v implementaci OOP si z hlavy vybavuju pouze dekorátor, což je ovšem typický příklad řešící chybějící pozdní vazbu v jazycích s podtypovým kvazipolymorfismem.
A taky všechny možné factory, proxy, mediátory, state, template method... To jsou všechno obraty v dynamicky typovaných jazycích jednoduché jak facka, takže nikoho nenapadlo je nějak pojmenovávat, ale teprve u těch statických se muselo přijít na idiomy, jakými se to chování známé z těch dynamických nasimuluje.

Pořád jsou to popisy typizovaných, i když často triviálních řešení, takže v pořádku. Akorát využitelnost oněch vzorů záleží na jazyku, takže nejsou obecné.

SB

Re:Výběr vhodného OOP jazyka
« Odpověď #141 kdy: 08. 06. 2018, 09:08:38 »
Tudiz bych trval na tom, ze zapouzdreni neni to, co dela OOP.

Už jsem to psal - bez zapouzdření padá izolace problému v rámci objektu, takže už se nejedná o objekt.

Natoz aby bylo jeho vysadou.

To tu nikdo nikdy netvrdil.

SB

Re:Výběr vhodného OOP jazyka
« Odpověď #142 kdy: 08. 06. 2018, 09:12:07 »
Sloučení dat s relevantními funkcemi je právě to zapouzdření.

To je druhým významem termínu vedle izolace.

Kiwi

Re:Výběr vhodného OOP jazyka
« Odpověď #143 kdy: 08. 06. 2018, 13:24:28 »
Tudiz bych trval na tom, ze zapouzdreni neni to, co dela OOP.

Už jsem to psal - bez zapouzdření padá izolace problému v rámci objektu, takže už se nejedná o objekt.
Objekt je abstraktní pojem. Už jsem to tu psal - můžu mít fungující objektový systém, kde v objektech vůbec žádné funkce nejsou. Důležitý je mechanismus, který vybere správnou metodu pro konkrétně předhozený objekt. A je fuk, jestli mám přímo v objektu nějaké metody, které přímo korespondují s názvy zpráv, nebo ty metody vybírá nějaký dispečer na základě zpráv, nebo ty metody stojí úplně mimo objekty a jsou s nimi (nebo klidně s více objekty) svázány jen pomocí nějaké opět mimo stojící funkce, např. print, kdy print(obj) koukne, co to je za typ objektu, a když zjistí, že string, tak zavolá string_print(obj), když double, tak zavolá double_print(obj), když float, tak taky zavolá double_print(obj), protože ten doublí print umí vypisovat i float atp. "Zapouzdření" konkrétních metod s konkrétními daty se tu děje jen na abstraktní úrovni, žádná fyzická izolace se tu nekoná, přesto se dá v takovém prostředí pohodlně objektově programovat.

Na druhou stranu můžu mít jazyk, který perfektně izoluje data od okolí a pevně spojuje metody s těmi daty, ale když bych náhodou zavolal špatnou metodu, tak neexistuje síla, jak takovou špatnou zprávu zachytit za běhu a vyrovnat se s ní nějak kreativně, než že mi už při kompilaci vyskočí error, konstruktor bude volán až po fyzickém vyrobení objektu a nebude moci vrátit jinou instanci nebo třeba úplně jiný objekt, atd. Takový jazyk by byl jen zkripleně objektový, třebaže dokonale zapouzdřuje.

Inkvizitor

Re:Výběr vhodného OOP jazyka
« Odpověď #144 kdy: 08. 06. 2018, 13:50:41 »
ou stranu můžu mít jazyk, který perfektně izoluje data od okolí a pevně spojuje metody s těmi daty, ale když bych náhodou zavolal špatnou metodu, tak neexistuje síla, jak takovou špatnou zprávu zachytit za běhu a vyrovnat se s ní nějak kreativně, než že mi už při kompilaci vyskočí error, konstruktor bude volán až po fyzickém vyrobení objektu a nebude moci vrátit jinou instanci nebo třeba úplně jiný objekt, atd. Takový jazyk by byl jen zkripleně objektový, třebaže dokonale zapouzdřuje.

Proč bych, do pytle, ale měl chtít, aby si objekt něco kreativně domýšlel? Jakože třeba (zjednodušeně) namísto operátoru + zmáčknu jedničku, objektu dojde, že je to na klávesnici někde poblíž a tudíž jsem chtěl asi říct objektu, že se má sečíst s nějakým objektem, který jsem mu poslal coby parametr zprávy? Tohle mi celé přijde na hlavu, pan Alan Kay navrhnul Smalltalk podle mě z nouze tak, jak je, protože tenkrát neviděl možnost, jak udělat jazyk s typovým systémem, který by mu přišel OK. A další a další apologeti "čistých objektů" se rozplývají nad tím, jak je super, když si objekt může nějak poradit se zprávou, kterou nemá explicitně definovanou.

Sorry, nic osobního, ale fakt Ti tohle nepřijde uhozené?

Kit

Re:Výběr vhodného OOP jazyka
« Odpověď #145 kdy: 08. 06. 2018, 14:06:41 »
Na druhou stranu můžu mít jazyk, který perfektně izoluje data od okolí a pevně spojuje metody s těmi daty, ale když bych náhodou zavolal špatnou metodu, tak neexistuje síla, jak takovou špatnou zprávu zachytit za běhu a vyrovnat se s ní nějak kreativně, než že mi už při kompilaci vyskočí error, konstruktor bude volán až po fyzickém vyrobení objektu a nebude moci vrátit jinou instanci nebo třeba úplně jiný objekt, atd. Takový jazyk by byl jen zkripleně objektový, třebaže dokonale zapouzdřuje.

Zachycení špatné zprávy není problém. To jen špatně navržené jazyky si s tím neporadí.

Re:Výběr vhodného OOP jazyka
« Odpověď #146 kdy: 08. 06. 2018, 14:16:39 »
Na druhou stranu můžu mít jazyk, který perfektně izoluje data od okolí a pevně spojuje metody s těmi daty, ale když bych náhodou zavolal špatnou metodu, tak neexistuje síla, jak takovou špatnou zprávu zachytit za běhu a vyrovnat se s ní nějak kreativně, než že mi už při kompilaci vyskočí error, konstruktor bude volán až po fyzickém vyrobení objektu a nebude moci vrátit jinou instanci nebo třeba úplně jiný objekt, atd. Takový jazyk by byl jen zkripleně objektový, třebaže dokonale zapouzdřuje.

Zachycení špatné zprávy není problém. To jen špatně navržené jazyky si s tím neporadí.

A objekt, co volal, se ma jit vycpat...

Inkvizitor

Re:Výběr vhodného OOP jazyka
« Odpověď #147 kdy: 08. 06. 2018, 14:23:53 »
Na druhou stranu můžu mít jazyk, který perfektně izoluje data od okolí a pevně spojuje metody s těmi daty, ale když bych náhodou zavolal špatnou metodu, tak neexistuje síla, jak takovou špatnou zprávu zachytit za běhu a vyrovnat se s ní nějak kreativně, než že mi už při kompilaci vyskočí error, konstruktor bude volán až po fyzickém vyrobení objektu a nebude moci vrátit jinou instanci nebo třeba úplně jiný objekt, atd. Takový jazyk by byl jen zkripleně objektový, třebaže dokonale zapouzdřuje.

Zachycení špatné zprávy není problém. To jen špatně navržené jazyky si s tím neporadí.

Zkus to prosím rozvést. Ne to se "špatně navrženými jazyky", ale proč bych to měl chtít a jak se takový chytrý objekt má typicky chovat.

anonym

Re:Výběr vhodného OOP jazyka
« Odpověď #148 kdy: 08. 06. 2018, 14:29:39 »
Na druhou stranu můžu mít jazyk, který perfektně izoluje data od okolí a pevně spojuje metody s těmi daty, ale když bych náhodou zavolal špatnou metodu, tak neexistuje síla, jak takovou špatnou zprávu zachytit za běhu a vyrovnat se s ní nějak kreativně, než že mi už při kompilaci vyskočí error, konstruktor bude volán až po fyzickém vyrobení objektu a nebude moci vrátit jinou instanci nebo třeba úplně jiný objekt, atd. Takový jazyk by byl jen zkripleně objektový, třebaže dokonale zapouzdřuje.

Zachycení špatné zprávy není problém. To jen špatně navržené jazyky si s tím neporadí.

Zkus to prosím rozvést. Ne to se "špatně navrženými jazyky", ale proč bych to měl chtít a jak se takový chytrý objekt má typicky chovat.

Dám ti radu, nepouštěj se do diskuze s Kitem.

Kiwi

Re:Výběr vhodného OOP jazyka
« Odpověď #149 kdy: 08. 06. 2018, 15:29:36 »
ou stranu můžu mít jazyk, který perfektně izoluje data od okolí a pevně spojuje metody s těmi daty, ale když bych náhodou zavolal špatnou metodu, tak neexistuje síla, jak takovou špatnou zprávu zachytit za běhu a vyrovnat se s ní nějak kreativně, než že mi už při kompilaci vyskočí error, konstruktor bude volán až po fyzickém vyrobení objektu a nebude moci vrátit jinou instanci nebo třeba úplně jiný objekt, atd. Takový jazyk by byl jen zkripleně objektový, třebaže dokonale zapouzdřuje.

Proč bych, do pytle, ale měl chtít, aby si objekt něco kreativně domýšlel? Jakože třeba (zjednodušeně) namísto operátoru + zmáčknu jedničku, objektu dojde, že je to na klávesnici někde poblíž a tudíž jsem chtěl asi říct objektu, že se má sečíst s nějakým objektem, který jsem mu poslal coby parametr zprávy? Tohle mi celé přijde na hlavu, pan Alan Kay navrhnul Smalltalk podle mě z nouze tak, jak je, protože tenkrát neviděl možnost, jak udělat jazyk s typovým systémem, který by mu přišel OK. A další a další apologeti "čistých objektů" se rozplývají nad tím, jak je super, když si objekt může nějak poradit se zprávou, kterou nemá explicitně definovanou.

Sorry, nic osobního, ale fakt Ti tohle nepřijde uhozené?
Pak je ale otázkou, co Ti z OOP zbyde, když dáš pryč věci, které Ti připadají uhozené. Chápal bych názor, že OOP je uhozené - když už. Ale OOP bez těch "uhozených" věcí mi připadá jen jako dost perverzní fetiš. To je pak něco naprosto k ničemu, jen obfuskátor strukturovaného návrhu (což je ovšem přesně to, s čím se většinou také setkávám - bohužel).

Proč by měl mít možnost objekt něco kreativně domýšlet? S těmi objekty se dá totiž dělat mnohem víc, než jen dědit a instanciovat, což mi připadá, že je taková průměrná představa o OOP u javistů a pluskařů. Dá se za běhu rozhodovat, který objekt bude nejvhodnější v dané situaci vrátit, dá se použít objekt, který vůbec nemusí být veřejně znám, dokonce ani jeho třída nemusí být veřejná. Dá se podstrčit objekt, který namísto objektu volajícím očekávaného třeba jen přesměrovává ty zprávy jinam, nebo je nějak filtruje. A to vše klidně dynamicky měnit za běhu. Dají se snadno vytvářet notifikační centra, observery, zástupné objekty - budoucí objekty, distribuované objekty, filtry, agenty, guardy, supervisory... Dají se tak snadno vyrábět třeba heterogenní kolekce, které samy přeposílají zprávy objektům, které obsahují, a vytvářet tak dynamicky komponované objekty - různé proxy apod. Je toho strašně moc, jak se taková volnost dá využít, přičemž lze jednoduše dosáhnout něčeho, co by se bez těchto možností dělalo jen dost komplikovaně a s hromadou kódu.

Já Ti nevím, ale mně to Tvoje "proč bych to měl chtít" připadá jak "proč by měl někdo chtít víc než 640 KB RAM".  ;)