Můžete doporučit knížku $PŘEDMĚT? Nějak jsem k ni nenašel recenze kromě jedné přímo v e-shopu (https://www.kosmas.cz/knihy/181112/objektove-programovani/), a ta je dost hrozná. Tak nevím, jakou knížku byste eventuálně doporučili k naučení základů OOP?
Můžete doporučit knížku $PŘEDMĚT? Nějak jsem k ni nenašel recenze kromě jedné přímo v e-shopu (https://www.kosmas.cz/knihy/181112/objektove-programovani/), a ta je dost hrozná. Tak nevím, jakou knížku byste eventuálně doporučili k naučení základů OOP?
Squeak by Example
Tam se OOP vysvětluje na Smalltalku
Squeak by Example
Tam se OOP vysvětluje na Smalltalku
Squak i Smalltalk používá jiné OOP než to OOP které se používá masivně v praxi, začátečníkům doporučit nelze, jsou pak zmatení.
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
chce-li se někdo naučit a opravdu pochopit objektové programování, tak Smalltalk je tou nejlepší cestou, jak toho dosáhnout.
A niečo k pôvodnej otázke nebude?
:D Ještěže chodím na Root, protože tohle mi otevřelo oči! Hned jsem vypnul pár bankovních SW a zítra je s klukama budeme přepisovat!
Můžete doporučit knížku $PŘEDMĚT? Nějak jsem k ni nenašel recenze kromě jedné přímo v e-shopu (https://www.kosmas.cz/knihy/181112/objektove-programovani/), a ta je dost hrozná. Tak nevím, jakou knížku byste eventuálně doporučili k naučení základů OOP?
Squeak by Example
Squak i Smalltalk používá jiné OOP než to OOP které se používá masivně v praxi, začátečníkům doporučit nelze, jsou pak zmatení.
1. ...
2. ...
3. ...
4. ...
:D Původní návrh OOP byl asynchronní remote procedure call mezi různými procesy. To se ukázalo jako nepraktické, tak se vytvořila prakticky použitelná realizace objektů tak jak je v C++ nebo C# nebo v Javě. Ve Smalltalku je proto jedna z nejvíce doku*vených implementací OOP, ani jedno, ani druhé, pro začátečníka největší ztráta času.
Dnes se používají oba způsoby, pod názvem OOP praktická realizace objektů a pod názvem RPC původní idea.
Asynchronní ve smyslu spouštění metod nebo paralelismu? Nepraktické v čem? Prakticky použitelná díky čemu? Co myslíte pod slovy „jedno“ a „druhé“? Odstavec vůbec nic nevysvětluje, jen obecně plácá.
V životě jsem neslyšel, že by se původnímu objektovému paradigmatu říkalo RPC (a to se kolem toho pohybuju), ani mi není jasné, co to s tím má společného. Naopak jsem slyšel, že mezitímco zneužívané „object oriented programming“ bylo přenecháno hybridním bastlům typu C++, původní myšlenka se označuje jako „object programming“ nebo „pure object programming“.
Naopak: Nejdříve na čisté formě pochopit (Smalltalk), pak se seznámit s dobastlenými implementacemi v ostatních jazycích. Jestliže nedojde k pochopení podstaty, nemá smysl OOP ani používat, jinak to dopadne právě tak, jak je vidět v praxi.Na Smalltalk opravdu doporučuju kouknout. Na něm jsem pochopil, jak odtržené od reality můžou být čisté formy. A taky to, že mainstream jazyky připomínají prase s křídly spíš z nutnosti než díky špatnému návrhu.
Můžete doporučit knížku $PŘEDMĚT? Nějak jsem k ni nenašel recenze kromě jedné přímo v e-shopu (https://www.kosmas.cz/knihy/181112/objektove-programovani/), a ta je dost hrozná. Tak nevím, jakou knížku byste eventuálně doporučili k naučení základů OOP?
...objektovému programování vůbec nerozumí a nepochopili ho...
Asynchronní ve smyslu spouštění metod nebo paralelismu? Nepraktické v čem? Prakticky použitelná díky čemu? Co myslíte pod slovy „jedno“ a „druhé“? Odstavec vůbec nic nevysvětluje, jen obecně plácá.
V životě jsem neslyšel, že by se původnímu objektovému paradigmatu říkalo RPC (a to se kolem toho pohybuju), ani mi není jasné, co to s tím má společného. Naopak jsem slyšel, že mezitímco zneužívané „object oriented programming“ bylo přenecháno hybridním bastlům typu C++, původní myšlenka se označuje jako „object programming“ nebo „pure object programming“.
Asynchronní ve smyslu samostatně fungující počítač, asynchronní spouštění metod. Nepraktické v tom, že není možné mít pro každý objekt proces nebo vlákno. Praktická realizace OOP v C++/C#/Java je dost jiná.
Smalltalk neumí ani původní návrh OOP ani OOP použité v C++/C#/Java, je to tedy největší ztráta času.
Pod pojmy object programming a pure object programming si každý představuje něco jiného, co je asynchronní RPC je poměrně jasné.
Takže…
Knížku jsem si prolistoval v knihovně a můj dojem je, že to autor dané recenze evidentně sám vůbec nechápe objektové programování a sám nejspíš patří mezi ty prasitele „objektového” kódu, pokud – nedej bože – sám aktivně programuje.
Naopak, knížka ukazuje rozdíly mezi různými implementacemi objektového přístupu, od těch neohrabanějších (Java) až po ty čistší (Objective C + Cocoa), ukazuje, jak se i v té Javě dá navrhnout relativně čistý design při vědomí jejích omezení, rozebírá různé modely a přístupy v objektovém návrhu, na příkladech ukazuje jejich výhody i úskalí, nezabíhá do zbytečného teoretizování, ale je prakticky orientovaná a srozumitelná i pro začátečníky. Zabývá se problémy, které většina jiných knih vůbec neřeší, ačkoli povědomí o nich je pro kvalitní objektový návrh nezbytné, naopak neřeší různé kosmetické nesmysly, jimiž se ty neohrabané objektové jazyky snaží maskovat svou neohrabanost a jež jsou prezentovány jako ty jedním z předřečníků zmiňované samospásné metody návrhu.
Celé toto nedorozumění tkví v tom, že 90% vývojářů, včetně těch, kteří dostanou ten hloupý nápad místo sebevzdělávání se a čtení napsat knihu a o své „rozumy” se podělit s nebohými čtenáři, ve skutečnosti objektovému programování vůbec nerozumí a nepochopili ho, čehož dokladem jsou jejich programátorské výtvory. V tomto ohledu bych knížku pana Čady považoval za jednu z mála světlých výjimek na českém trhu.
...objektovému programování vůbec nerozumí a nepochopili ho...
mohl byste prosím definovat "objektové programování"?
Jaký je ten původní OOP?
Jaký je ten původní OOP?
Původní OOP je zasílání zpráv samostatným počítačům v síti. Nejblíže tomu má RPC.
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful).
...objektovému programování vůbec nerozumí a nepochopili ho...
mohl byste prosím definovat "objektové programování"?
Celé toto nedorozumění tkví v tom, že 90% vývojářů, včetně těch, kteří dostanou ten hloupý nápad místo sebevzdělávání se a čtení napsat knihu a o své „rozumy” se podělit s nebohými čtenáři, ve skutečnosti objektovému programování vůbec nerozumí a nepochopili ho, čehož dokladem jsou jejich programátorské výtvory.
Nevím o tom, že by to nějaký z vámi zmiňovaných hybridů uměl bez „homogenizátorů“ (jak taky).
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.
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í.
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 :)
...že "OOP = zapouzdření + dědičnost". Jenže realita je taková, že "OOP = polymorfismus + pozdní vazba" ...
...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.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.
"definiční požadavky" OOP (polymorfismus + (extrémně) pozdní vazbu)
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..
$this->result(); např možná :) .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?
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 ? :)
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í jenKód: [Vybrat]$this->result();např možná :) .
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.
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ě.
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.
OOP je v první řadě systém organizace modelu a jeho výpočtu, který má zjednodušit vedení velkých projektů.
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 :)
Pozdní vazba je univerzální, jde s ní udělat víc než s časnou
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í.
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í.
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.
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.
Kéž by vývojáři takové zapouzdření dělali. Místo toho tam nacpou hromady getterů a setterů...
Kéž by vývojáři takové zapouzdření dělali. Místo toho tam nacpou hromady getterů a setterů...
Getter a Setter je zapouzdření. G/S jsou normální metody jako každé jiné a můžeš si tam napsat cokoliv jako do každé jiné metody. Není pravda že Setter je povinně this->m_variable=new_value Pokud si to takhle myslíš, žiješ v hlubokém omylu. Je pravda, že spousta programátorů v tomto hlubokém omylu žije.
Sorry, nechápu dotaz. Ten původní jsem pochopil jako "Dá se zapouzdření využít někde mimo objektový model?" Vzhledem k tomu, že zapouzdření není nic jiného než skrytí nepodstatných detailů, tak se využívá v čistých i nečistých, objektových i neobjektových jazycích.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í.
Rozhraní má i objekt. Rozhraní čeho máte na mysli? Jak je realizována zvenku nepřístupná doména? Knihovnou? Nějak jinak?
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í jenKó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.
Sorry, nechápu dotaz. Ten původní jsem pochopil jako "Dá se zapouzdření využít někde mimo objektový model?" Vzhledem k tomu, že zapouzdření není nic jiného než skrytí nepodstatných detailů, tak se využívá v čistých i nečistých, objektových i neobjektových jazycích.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í.
Rozhraní má i objekt. Rozhraní čeho máte na mysli? Jak je realizována zvenku nepřístupná doména? Knihovnou? Nějak jinak?
A na mysli mám rozhraní čehokoliv.
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í jenKó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.
Myslel jsem to v obecné rovině. Ne ve Smalltalku. Neříkám, pro blbce, ale asi logicky, je něco jiného programovat v nižším jazyce, než ve vyšším.Kde mám většinu nízkoúrovňových věcí hotovou. A hezky si dělám ten svůj estetický přehledný kód se syntaktickým cukrem.
Já zase nechápu odpověď. Rozhraní je jen předpis funkcionality systému, který popisuje, kterou funkcionalitu systém určitě implementuje, ale neznamená, že neimplementuje nic dalšího, takže nijak neomezuje využití jeho dalších funkcionalit, např. přes další rozhraní či např. objektově posláním zprávy (u hybridních jazyků třeba před „posláním“ (čti voláním) přetřídovat (čti přetypovat)). Takže rozhraní mechanismem zapouzdření není.Rozhraní taky není mechanismus zapouzdření. Rozhraní je popis toho, co je přes zapouzdření vidět.
Uveďte jiný příklad implementace zapouzdření.
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...
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é.
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 ;)
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.
Vystavění aplikace z tisíce modulů asi nebude moc jednoduché
kde se nacházejí stavy, netuším
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.
Citacekde 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.
nutnost explicitně funkcím předhazovat data
2. takové rádobyzapouzdření obfuskací, předpokládám přepisovatelné, takže negarantovaný stav.
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
module AnotherStack = struct
type 'a t = 'a list
let empty = []
let push x xs = x :: xs
let pop (_ : 'a t) = failwith "TODO"
endPořá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.
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.
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.
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.
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.
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.
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.
Zapouzdření funguje spolehlivě. Například implementace zásobníku v OCamlu...
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í.
Nicméně na rozdíl od modulů/struktur nemohou objekty (z objektového systému) obsahovat typy.
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.
Stavy jsou schované za tím handlem (např ukazatel na haldu). Identita vyplývá zase z toho handlu.
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.
CitacePořá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.
Čistě objektový systém NESMÍ obsahovat typy, není k tomu důvod a komplikuje to celý výpočetní model.
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.
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.
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.
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.
test_parseLit_pos : so $ parseLit "c" == Right (MkLit Pos "c")
test_parseLit_pos = oh
Č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"?
Č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"?
Model, jehož hodnoty a výpočty jsou realizovány objekty. Kupodivu. Hybridní model je něco jiného.
Uvedu na příkladu:
řekněme, že máme třídu psa. A chceme vytvořit jednu instanci na základě dat s db, ale po načtení zjistíme,
že je požadováno vytvořit psa se 3 nohama....(neřeším jak tato věc v db vznikla).
A) Včasné řešení neumožní psa ani vytvořit. Vyjímku vyhodí už constructor.
B) Pozdní řešení psa vytvoří, ale vyjímky vyhodí až metoda běhej. Metoda podej pac bude normálně fungovat pro zdravé nohy.
OOP teorie říkají, že A) je správně..objekt lze založit jen pokud jsou stavy vnitřně konzistentní.
Bohužel praxe ukazuje, že B) je významně lepší, neboť nám dává možnost na nekorektní stavy reagovat a
chybný stav opravit (psa zoperovat, aby měl 4 nohy a mohl pak běhat).
Pro A) musím explicitně řešit jak se vypořádat s nekonzistencí, ale to je někdy problém, nekonzistnce je vně systému.
Pro B mám tedy volnější podmínky na konzistenci vnitřních stavů a getry a setry, zde často postrádají úplně smysl.
neboť konzistenci hodnot nekontrolují....
PeVa
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í.
PeVa :
Tady bych nesouhlasil. Možnost A podstatně zmenšuje množství stavů, které musím jako programátor řešit. Pokud mám konzistentního Psa, tak nemusím řešit jestli umí běhat na každém místě, kde ho chci použít. Přišití nohy můžu řešit na jediném místě a to tam, kde ten objekt vytvářím.
Takhle veškeré nekonzistence zvenku řeším právě na hranici systému a uvnitř je všechno konzistentní.
Samozřejmě pokud modeluju veterinu, tak budou požadavky na konzistentního psa trochu jiné, než když modeluju K9. :)
PeVa :
Tady bych nesouhlasil. Možnost A podstatně zmenšuje množství stavů, které musím jako programátor řešit. Pokud mám konzistentního Psa, tak nemusím řešit jestli umí běhat na každém místě, kde ho chci použít. Přišití nohy můžu řešit na jediném místě a to tam, kde ten objekt vytvářím.
Takhle veškeré nekonzistence zvenku řeším právě na hranici systému a uvnitř je všechno konzistentní.
Samozřejmě pokud modeluju veterinu, tak budou požadavky na konzistentního psa trochu jiné, než když modeluju K9. :)
Není to úplně přesné, jak to popisuješ...při B) test na nohy musíš implementovat ve všech metodách, kde pes nohy bude používat, při štěkání pochopitelně ne. Není to ani tak, že každé běhání psa má vlastni implementaci, ta je pochopitelně jen jedna.
B) je sice pracnější, ale za to názorné a dokumentuje nutné předpoklady pro úspěšné zvládnutí funkcionality-činnosti. Když se nějakej mimozemšťan zeptá, k čemu ten pes vlastně nohy potřebuje, a jaké musí být, tak je to hned jasné. Podobně je to s ocasem a ušima.
Ano v tvém kontextu při A) se situace zjednodušší, nicméně jsi jen přenesl zodpovědnost za řešení nekonzistence vně.
Nekonzistenci tak jako tak někdo musí nakonec vyřešit. Jak ji chceš ale vyřešit, když nemužes vytvořit ani psa, že?
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 )
A) také nepotřebuje getry/setry. Pokud potřebuji mít možnost třínohého psa, ošetřím to v konstruktoru, resp. tuto kontrolu mohu vypustit. Pokud však čtyřnohému psu budu chtít nohu amputovat, místo setteru provedu chirurgický zákrok. Tedy pokud urizniNohu() nepovažuješ za setter.
B) je sice pracnější, ale za to názorné a dokumentuje nutné předpoklady pro úspěšné zvládnutí funkcionality-činnosti. Když se nějakej mimozemšťan zeptá, k čemu ten pes vlastně nohy potřebuje, a jaké musí být, tak je to hned jasné. Podobně je to s ocasem a ušima.
Ano v tvém kontextu při A) se situace zjednodušší, nicméně jsi jen přenesl zodpovědnost za řešení nekonzistence vně.
Nekonzistenci tak jako tak někdo musí nakonec vyřešit. Jak ji chceš ale vyřešit, když nemužes vytvořit ani psa, že?
Ve stavu se nešťouráte cizími funkcemi - jsou to funkce z toho modulu.
Nejde.
Nerozumím. Vždyť i v OOP mohu metodám předat/poslat jiný objekt.
Podobně jako máte virtuální metody, můžete mít i virtuální třídy...
...typy ve třídách dávají dobrý smysl. Viz třeba OO jazyky BETA nebo Scala.
Obecně typy ve třídách zvyšují vyjadřovací schopnosti jazyka
A) také nepotřebuje getry/setry. Pokud potřebuji mít možnost třínohého psa, ošetřím to v konstruktoru, resp. tuto kontrolu mohu vypustit. Pokud však čtyřnohému psu budu chtít nohu amputovat, místo setteru provedu chirurgický zákrok. Tedy pokud urizniNohu() nepovažuješ za setter.
Nohu neamputuješ, ty máš už nažačátku psa, kterej má 3 nohy.
V pořádku, v Haskellu i jinde to funguje, je to jen otázkou deklarace, já jsem narážel na argumenty takových, kteří považují omezení na String za dostatečnou kontrolu správnosti dat.Pokud jste tak pochopil ten můj příspěvek, tak jste ho pochopil špatně. Typová kontrola tak, jak jsem ji popsal zhruba odpovídá "Porozumí tenhle objekt mojí zprávě?" A jestli ne, tak to zjistím už při překladu a nemusím si na to psát unit test.
Pokud mám třínohého psa, uvedu to v konstruktoru. Setter nepotřebuji.
Pokud mám třínohého psa, uvedu to v konstruktoru. Setter nepotřebuji.
Ja se nepřu, ale nepotřebuješ to uvádět ani v konstrukoru ani nepotřebuješ setter....Neboť je to úplně jedno jak je na tom pes s nohama...Jednou je to podle DNA pes a ostatní věci jsou podružné...Jestli pes může běhat je dáno jenom tím, jak je na tom momentálně s nohama...to se může pochopitelně celkem snadno měnit.
K čemu je pak objekt, který nemá žádné atributy a nemůže tedy držet žádný stav?
Ano pokud implementuji vnitřní stavy, pak musím implementovat settery a gettery, aby vnitřní stav byl konzistentní.