Čada: Objektové programování

Re:Čada: Objektové programování
« Odpověď #60 kdy: 23. 06. 2015, 11:10:43 »


Kit

Re:Čada: Objektové programování
« Odpověď #61 kdy: 23. 06. 2015, 11:47:40 »
Tak, tak. G/S jsou zapouzdreni. Leckdy to neni dobry navrh, ale nikde neni psano, ze zapouzdreni + polymorfismus samo o sobe k dobremu navrhu staci...

Problémem G/S je, že často zbytečně rozšiřují rozhraní objektů. Dávat do interface G/S mi připadá odporné.

Re:Čada: Objektové programování
« Odpověď #62 kdy: 23. 06. 2015, 12:50:07 »
Tak, tak. G/S jsou zapouzdreni. Leckdy to neni dobry navrh, ale nikde neni psano, ze zapouzdreni + polymorfismus samo o sobe k dobremu navrhu staci...

Problémem G/S je, že často zbytečně rozšiřují rozhraní objektů. Dávat do interface G/S mi připadá odporné.

Tak to je ovsem uplne jine tvrzeni nez to puvodni ;)

Kit

Re:Čada: Objektové programování
« Odpověď #63 kdy: 23. 06. 2015, 13:02:26 »
Problémem G/S je, že často zbytečně rozšiřují rozhraní objektů. Dávat do interface G/S mi připadá odporné.

Tak to je ovsem uplne jine tvrzeni nez to puvodni ;)

V čem je úplně jiné?

SB

Re:Čada: Objektové programování
« Odpověď #64 kdy: 24. 06. 2015, 16:11:48 »
Rozhraní taky není mechanismus zapouzdření. Rozhraní je popis toho, co je přes zapouzdření vidět.

Příklad zapouzdření by bylo třeba několik exportovaných funkcí a data schovaná za nějaký abstraktní handle (void ptr, int). Tady to zapouzdření nedělají objekty, ale moduly.

A ten handle je tam na co???

Takže zapouzdření moduly. Na to jsem se už ale ptal, takže jen myšlenku dokončíme: Vystavění aplikace z tisíce modulů asi nebude moc jednoduché, kde se nacházejí stavy, netuším. Mimoto další objektové vlastnosti jako identitu a další to asi mít nebude, co?


Radek Miček

Re:Čada: Objektové programování
« Odpověď #65 kdy: 24. 06. 2015, 16:58:05 »
Vystavění aplikace z tisíce modulů asi nebude moc jednoduché

Například v Haskellu, OCamlu, Standard ML nebo Prologu se to normálně používá.

Je to jednodušší a v případě OCamlu i flexibilnější než OOP z Javy.

Citace
kde se nacházejí stavy, netuším

Stav můžete dát do záznamu v modulu. Tento záznam pak předáváte funkcím. Uvnitř modulu vidíte záznam včetně jednotlivých polí, zvenku se však záznam může tvářit jako abstraktní typ - jeho jednotlivá pole nejsou vidět.

SB

Re:Čada: Objektové programování
« Odpověď #66 kdy: 25. 06. 2015, 07:46:42 »
Vystavění aplikace z tisíce modulů asi nebude moc jednoduché

Například v Haskellu, OCamlu, Standard ML nebo Prologu se to normálně používá.

Je to jednodušší a v případě OCamlu i flexibilnější než OOP z Javy.

V pořádku, tyto jazyky neznám. Mimoto OOP Javy pro mě není etalonem.

Citace
kde se nacházejí stavy, netuším

Stav můžete dát do záznamu v modulu. Tento záznam pak předáváte funkcím. Uvnitř modulu vidíte záznam včetně jednotlivých polí, zvenku se však záznam může tvářit jako abstraktní typ - jeho jednotlivá pole nejsou vidět.

Takže
1. centrální data bez lokálního kontextu - nutnost explicitně funkcím předhazovat data, možnost použití funkcí s nevhodnými daty,
2. takové rádobyzapouzdření obfuskací, předpokládám přepisovatelné, takže negarantovaný stav.

Pořád mi nikdo neukázal stejně jednoduchou alternativu k objektovému paradigmatu. To je to, co se tu snažím získat a osobně by mě to dost zajímalo. Prosím proto reakce na mě pouze k tomuto cíli, ať tu nejsme do skonání světa. Děkuji.

Radek Miček

Re:Čada: Objektové programování
« Odpověď #67 kdy: 25. 06. 2015, 10:24:44 »
nutnost explicitně funkcím předhazovat data

To děláte i v jiných OO jazycích, ne? Když například napíši obj.met(), tak metodě met explicitně předávám objekt obj.

Citace
2. takové rádobyzapouzdření obfuskací, předpokládám přepisovatelné, takže negarantovaný stav.

Zapouzdření funguje spolehlivě. Například implementace zásobníku v OCamlu:

Kód: [Vybrat]
module type STACK = sig
  type 'a t
  val empty : 'a t
  val push : 'a -> 'a t -> 'a t
end

module Stack : STACK = struct
  type 'a t = 'a list
  let empty = []
  let push x xs = x :: xs
end

Zásobník je implementován strukturou/modulem Stack, jenž má signaturu STACK. Signatura říká, jak se struktura tváří zvenčí. V našem případě je typ t (jediný typ ve struktuře) abstraktní - nikdo zvenčí neuvidí, že je zásobník implementován jako spojový seznam, jediný, kdo to vidí, jsou funkce ze struktury Stack - v našem případě funkce empty a push.

Na rozdíl od mainstreamových jazyků jsou signatury srovnávány strukturálně, nikoliv nominálně - to zvyšuje flexibilitu. Například stuktura

Kód: [Vybrat]
module AnotherStack = struct
  type 'a t = 'a list
  let empty = []
  let push x xs = x :: xs
  let pop (_ : 'a t) = failwith "TODO"
end

jde použít v místě, kde je očekávána struktura se signaturou STACK - struktuře AnotherStack nebylo nutné přiřadit signaturu STACK (nevadí ani to, že AnotherStack obsahuje funkci navíc). Jelikož jsme struktuře AnotherStack explicitně nepřiřadili signaturu, kompilátor jí přiřadí signaturu automaticky, tato signatura odhalí vše - i zvenčí bude vidět, že je zásobník implementován jako spojový seznam.

Struktura AnotherStack může být uvnitř jiné struktury například M. Při přiřazování signatury struktuře M můžeme přiřadit i signaturu struktuře AnotherStack, anebo strukturu AnotherStack můžeme úplně vynechat - pak tato struktura bude vidět pouze uvnitř M, nikoliv zvenčí.

Citace
Pořád mi nikdo neukázal stejně jednoduchou alternativu k objektovému paradigmatu. To je to, co se tu snažím získat a osobně by mě to dost zajímalo.

Moduly v OCamlu můžete chápat jako objekty bez dědičnosti - můžete je předávat funkcím i vracet z funkcí. Mj. pokud potřebujete dědičnost, má OCaml i objektový systém s dědičností (zapouzdření se tam však vynucuje pomocí modulů). Nicméně na rozdíl od modulů/struktur nemohou objekty (z objektového systému) obsahovat typy. Dá se například říci, že Scala sjednotila systém modulů a objektů do jednoho - tam objekty mohou obsahovat i typy a funguje tam i dědičnost.

JSH

Re:Čada: Objektové programování
« Odpověď #68 kdy: 25. 06. 2015, 10:32:46 »
A ten handle je tam na co???
Za tím handlem jsou schovaná data. Mohl bych říct, že je to handle "objektu", ale v podstatně volnějším smyslu než v OOP. Ono to celé bude vlastně dost podobně k OOP, akorát ty "objekty" jsou tupé balíčky dat.
Citace
Takže zapouzdření moduly. Na to jsem se už ale ptal, takže jen myšlenku dokončíme: Vystavění aplikace z tisíce modulů asi nebude moc jednoduché, kde se nacházejí stavy, netuším. Mimoto další objektové vlastnosti jako identitu a další to asi mít nebude, co?
Stavy jsou schované za tím handlem (např ukazatel na haldu). Identita vyplývá zase z toho handlu.
Citace
1. centrální data bez lokálního kontextu - nutnost explicitně funkcím předhazovat data, možnost použití funkcí s nevhodnými daty,
Moduly nejsou objekty. Modul nemusí mít data jen globálně. Právě proto je tam ten handle. Modul je blíž třídě než objektu.
U silně typovaných jazyků je to použití funkcí s nevhodnými daty dost omezené. U staticky typovaných jazyků to navíc chytne už překladač. Použití funkce s nevhodnými daty je stejné jako zaslání nevhodné zprávy nějakému objektu.
Citace
2. takové rádobyzapouzdření obfuskací, předpokládám přepisovatelné, takže negarantovaný stav.
Jaká obfuskace. Data jsou schovaná za nějaký handle a dá se s nima manipulovat jen omezenou množinou finkcí. Pokud to rozhraní nenavrhne prase, tak každá funkce nechá data v konzistentním stavu.
Citace
Pořád mi nikdo neukázal stejně jednoduchou alternativu k objektovému paradigmatu.
Jednoduchou alternativu pro jakou aplikaci? OOP je jedno z paradigmat. Na něco se hodí víc, na něco míň. Já osobně ani nepsal že by OOP mělo nějakou univerzální alternativu. Jen jsem psal, že zapouzdření není rozhodně nějaká specialita OOP.

SB

Re:Čada: Objektové programování
« Odpověď #69 kdy: 26. 06. 2015, 10:41:57 »
nutnost explicitně funkcím předhazovat data

To děláte i v jiných OO jazycích, ne? Když například napíši obj.met(), tak metodě met explicitně předávám objekt obj.


Ne!!! Nemůžu si vybírat stavy (objekt) pro jednu metodu, nemůžu napsat jiný_obj.ta_samá_met(), protože metoda je součástí objektu a pracuje s jeho stavy! To je nepochopení OOP. V OOP se nemůžu kdykoli šťourat ve stavech cizími metodami.

Zapouzdření funguje spolehlivě. Například implementace zásobníku v OCamlu...

Jde ten seznam zásobníku z venku přečíst či něčím přepsat, i když neznám jeho strukturu? Jde => nejedná se o zapouzdření, nejde => je zapouzdření.

Moduly v OCamlu můžete chápat jako objekty bez dědičnosti - můžete je předávat funkcím i vracet z funkcí.

To je typický imperativní přístup - obecným funkcím předhazuju nějaká specifická data/stavy. Nic takového OOP nemá.


Nicméně na rozdíl od modulů/struktur nemohou objekty (z objektového systému) obsahovat typy.

Čistě objektový systém NESMÍ obsahovat typy, není k tomu důvod a komplikuje to celý výpočetní model.

SB

Re:Čada: Objektové programování
« Odpověď #70 kdy: 26. 06. 2015, 10:55:57 »
Za tím handlem jsou schovaná data. Mohl bych říct, že je to handle "objektu", ale v podstatně volnějším smyslu než v OOP. Ono to celé bude vlastně dost podobně k OOP, akorát ty "objekty" jsou tupé balíčky dat.

Vzhledem k tomu, že klíčovou podstatou objektu je, že není tupý, tak kde je potom podobnost?

Stavy jsou schované za tím handlem (např ukazatel na haldu). Identita vyplývá zase z toho handlu.

„Schované“ už jsme probírali.

U silně typovaných jazyků je to použití funkcí s nevhodnými daty dost omezené. U staticky typovaných jazyků to navíc chytne už překladač. Použití funkce s nevhodnými daty je stejné jako zaslání nevhodné zprávy nějakému objektu.

Klasický argument, že typová kontrola řeší chyby - neřeší, garantuje, že do stringu nedáte číslo, ale už negarantuje, že tam nestrčíte řetězec, který tam vůbec nemá smysl. Kdežto zapouzdření garantuje, že se vůbec nedostanete k datům, ke kterým se dostat nemáte, takže s nimi ani pracovat nemůžete.

Citace
Pořád mi nikdo neukázal stejně jednoduchou alternativu k objektovému paradigmatu.
Jednoduchou alternativu pro jakou aplikaci? OOP je jedno z paradigmat. Na něco se hodí víc, na něco míň. Já osobně ani nepsal že by OOP mělo nějakou univerzální alternativu. Jen jsem psal, že zapouzdření není rozhodně nějaká specialita OOP.

Pro modelování složitých grafových vztahů a zpracování v obchodních aplikacích. Pořád platí nezodpovězený dotaz, zda lze z modulu (OCamlu?) cokoliv číst či zapisovat, když neznám jeho strukturu.

SB

Re:Čada: Objektové programování
« Odpověď #71 kdy: 26. 06. 2015, 10:58:11 »
Rozmyslete, zda chcete ještě reagovat, protože už jsme všechno probrali a začínáme mlátit prázdnou slámu (a už mě to docela přestává bavit).

v

Re:Čada: Objektové programování
« Odpověď #72 kdy: 26. 06. 2015, 11:15:29 »
Čistě objektový systém NESMÍ obsahovat typy, není k tomu důvod a komplikuje to celý výpočetní model.

jaká je definice objektového systému? resp. jak je definován "objektový výpočetní model"?

JSH

Re:Čada: Objektové programování
« Odpověď #73 kdy: 26. 06. 2015, 11:18:10 »
Pro modelování složitých grafových vztahů a zpracování v obchodních aplikacích. Pořád platí nezodpovězený dotaz, zda lze z modulu (OCamlu?) cokoliv číst či zapisovat, když neznám jeho strukturu.
Na grafové věci je OOP to nejstrašnější, co jsem kdy viděl. Obzvlášť jak se objeví visitor pattern.

Vaše neznalosti věcí mimo OOP už opravovat nebudu. Taky mě to nebaví.

v

Re:Čada: Objektové programování
« Odpověď #74 kdy: 26. 06. 2015, 11:21:31 »
U silně typovaných jazyků je to použití funkcí s nevhodnými daty dost omezené. U staticky typovaných jazyků to navíc chytne už překladač. Použití funkce s nevhodnými daty je stejné jako zaslání nevhodné zprávy nějakému objektu.

Klasický argument, že typová kontrola řeší chyby - neřeší, garantuje, že do stringu nedáte číslo, ale už negarantuje, že tam nestrčíte řetězec, který tam vůbec nemá smysl. Kdežto zapouzdření garantuje, že se vůbec nedostanete k datům, ke kterým se dostat nemáte, takže s nimi ani pracovat nemůžete.


to není pravda, např. v Haskellu je možné definovat pro typ (např.) String "newtype" a následně "type class" určující jak je s ním možno pracovat, to že jej nikdo jiným neprohlédne se pak zajisté neexportováním konstruktoru z modulu
(ale pokud kriticky záleží na formátu řetězce, tak by ta hodnota neměla být vyjádřena řetězcem )