Jste zastánci OOP programování?

Bone Flute X

Re: Jste zastánci OOP programování?
« Odpověď #195 kdy: 26. 02. 2011, 01:05:34 »
Byl by jsi schopen vysvětlit, co to monáda je?


JS

Re: Jste zastánci OOP programování?
« Odpověď #196 kdy: 26. 02. 2011, 09:04:04 »
1. No, jenže já dědičnost umím využít. Interface používám právě proto, že mi to překladač nedovolí přeložit. Takže to zkuste napsat znova a lépe.

To nejak nechapu. Takze ten interface tam mate proto, abyste obesel nejake omezeni?

Nebo uveďte příklad, jak by jste v procedurálním programování implementoval obecné rozhraní ICommand, k němu blíže neurčený počet implementací. Přičemž mám továrnu (ta může být funkce), která generuje příkazy, ty se někde sockují, a pak se předají další, třeba funkci, která s nich generuje nějaké výsledky. Jde mi o ten Command. Jako určitě bych to zvládl i v neOOP, ale proč si to komplikovat, ne?

V proceduralnim programu by se definovala struktura, ktera by obsahovala par ukazatelu na funkce s urcitou typovou signaturou. Pro kazdy prikaz by se definovaly funkce se stejnou signaturou, a ty by se pak predaly. Je to stejne typove bezpecne a interface to nepotrebuje.

Na druhou stranu, muj postoj k interfacum je ponekud ambivalentni. Jak rika Inkvizitor, interface ma urcitou dokumentacni hodnotu, i kdyz u zrovna tohohle si myslim, ze by to jazyk mel resit jinak (nebo spis ze by to mely resit nastroje jako IDE). Vec je, ze nevidim duvod, proc nepovazovat ekvivalentni objekty za ekvivalentni (2 tridy se stejnou podmnozinou metod), aniz by nekdo explicitne prohlasil, ze jsou ekvivalentni (definoval interface). Ale zatim mi neni zcela jasne, jake by to melo dusledky (napriklad pro dispatch metod), takze bych interface uplne nezavrhoval (treba pristup jazyka Go je zajimavy - v tomhle smeru je pak filozoficka otazka, do jake miry jsou interfacy soucasti OOP, nebo je to abstrakce sama o sobe).

2. Znám moduly v VB (očistec) a v pythonu. Určitě to lze použít. Ale to mám na každou jednu třídu/objekt kačenky vytvořit samostatný modul? Myslím, že v tomto je java pohodlná, že umí třeba i privátní třídy v třídách.

No a, tak ten modul bude trochu vetsi. Ja bych se toho nebal. Me prijde, ze tyhle Javove vynalezy se snazi strasne stavet nejruznejsi bariery (delit veci do trid), ktere ve skutecnosti vubec nejsou potreba. Ze bude v jednom modulu par promennych, co spolu nesouvisi? A pak musite delat silene veci (refaktoring pomoci IDE, ruzne patterny), abyste tyhle bariery, ktere jste si nakladli do programu, zase prekonali. Prijde mi to jako prace vynalozena navic, a ta udajna "typova bezpecnost", kterou to prinasi, se v te slozitosti zase ztrati.

Tak mi to proste pripada. Kdykoli prohlizim nejaky program v Jave (bez IDE), je to zoufale. Vsechno je roztahane v bilionu malych souboru v milionech podadresaru. Clovek to proste nemuze vzit a precist si to jako roman.

3. Na dekompozici problému se používaji metody a třídy. Proc si lámat hlavu tim, která funkce se používá na kterou strukturu, kdyz je mohu svázat k sobě? Dělat to jen jmennou konvencí mi z toho udělá nepořádek a pak je z toho změť podtržítek.

Protoze to svazani ma svoji cenu, a za tu platite tim, ze jste si vytvoril umelou barieru, kde tu funkci muzete pouzit. A to vsechno jen za subjektivni pocit toho, co je neporadek.

OOP je v boji proti entropii pokrok, jak by jste chtěl dokázat opak? Proč se většina komplexních systémů píše v Javě, přestože je to nenažraná potvora?

Me se hrozne libi Common Lisp. Nemyslim, ze se v nem nedaji psat komplexni systemy, i bez OOP nadstavby, kterou ma (CLOS). Kdyz ho zacnete studovat, prijdete na to, ze OOP je jen jedna z mnoha abstrakci. Kazda abstrakce je samozrejme pokrok v boji proti entropii, ale nesmi se to prehanet.

Jenze Java to prehnala. Vsechno v zivote zkratka neni trida. Tim se plete puvodni vyznam trid, totiz vyrobit novy typ (coz je to dobre pouziti), s vyznamem "usporadat veci k sobe" (ktery lepe resi modularni system prislusneho jazyka, v pripade CL jsou to balicky a systemy). A to neni dobre.

JS

Re: Jste zastánci OOP programování?
« Odpověď #197 kdy: 26. 02. 2011, 09:18:10 »
Obávám se, že tohle není argument. Všechny současné jazyky jsou turingovsky kompletní, tzn. že všechny jsou schopny používat OOP techniky bez přímé podpory, protože kód z OOP jazyka lze do jejich jazyka převést.

Je to argument proti tvrzeni, ze OOP prislo nejak vyrazne na pomoc bojovat proti entropii. Historicky to neni pravda. Vzato celkove byl daleko dulezitejsi pro boj s entropii vynalez konceptu funkce (v programovani, ne matematice) nez konceptu tridy. (A ze to trvalo.)  A nebo vynalez namespace.

OOP je navic jen jedna z rady abstrakci (nebo spis kombinace nekolika ruznych abstrakci z mnoha), a kazda z nich nejak pomaha v boji proti entropii. Vzit jednu podmnozinu z nich a oznacit ji za dulezitejsi mi prijde scestne.

Tady jde asi o něco jiného a souhlasím s původním příspěvkem. OOP techniky pomáhají hlavně při abstrakci daného problému a to jak při návrhu, tak při jeho údržbě. Dobře rozdělují role a zodpovědnost. Pokud nejsme někde schopni o zodpovědnosti rozhodnout, je program navržen špatně. To se mi osvědčilo už několikrát a vždycky to bylo tím, že jsem dával zodpovědnost té části programu (tomu objektu), který ji neměl dostat.

Jenze tohle bylo vynalezeno pred OOP, tehdy se tomu ovsem rikalo modularni programovani. Takze pripisovat to OOP je odvazne.

JS

Re: Jste zastánci OOP programování?
« Odpověď #198 kdy: 26. 02. 2011, 09:37:30 »
A uz jen fakt, ze vedeme tuto diskusi, a ze rada velmi chytrych lidi neni zastanci OOP, ukazuje, ze prinos OOP neni tak jednoznacny (spise ale nektere aspekty nekterych jazyku). Nikdo nevede diskuse typu "jste zastanci funkci" nebo "jste zastanci lexikalnich promennych" nebo "jste zastanci predavani jmenem", protoze to uz jsou koncepty, co se jasne ukazaly.

ondra.novacisko.cz

Re: Jste zastánci OOP programování?
« Odpověď #199 kdy: 26. 02. 2011, 11:28:28 »
A uz jen fakt, ze vedeme tuto diskusi, a ze rada velmi chytrych lidi neni zastanci OOP, ukazuje, ze prinos OOP neni tak jednoznacny (spise ale nektere aspekty nekterych jazyku). Nikdo nevede diskuse typu "jste zastanci funkci" nebo "jste zastanci lexikalnich promennych" nebo "jste zastanci predavani jmenem", protoze to uz jsou koncepty, co se jasne ukazaly.

Jenže to se pletete, protože vše co jste vyjmenoval jsou vyjadřovací prostředky, zatímco OOP je metodika návrhu aplikace a ne vyjadřovací prostředek. OOP jazyky obsahují vyjadřovací prostředky, jako právě ty interfacy, třídy, zápis s tečkou, nástroje pro vytváření objektů, alokace prostřední pro ně (paměť) atd, ale tyhle vyjadřovací techniky jsou určené jen proto, aby usnadňovali naplňovat metodiku OOP.

V zásadě existují dva přístupy návrhu. Klasický strukturalní, nebo databázový, kdy mám data organizované v nějakém storage a funkce, které různě s těmi daty pracují. Tam spadají relační databáze, globální proměnné, zásobníkové algoritmy. OOP naopak drží data pospolu ve skupině s operacemi, které s těmi daty pracují.

Je naprosto šumák, jestli si navrhnete aplikaci v OOP prostředí s objektovou databází, nebo použijete relační databázi, do které budete ukládat serializované struktury. V prvním případě vám objektová databáze půjde naproti a pomůže vám. V tom druhém případě budete vymýšlet obezličky a pak si plácat po ramenou, jak se můžete objektům vyhnout.

Někde tady na forech byl dotaz ohledně speciální databáze k e-shopu, která se velice těžko bude řešit strukturovaně, ale v OOP je to otázka na několik jednoduchých objektů. Takže asi tak


JS

Re: Jste zastánci OOP programování?
« Odpověď #200 kdy: 26. 02. 2011, 12:05:01 »
V zásadě existují dva přístupy návrhu. Klasický strukturalní, nebo databázový, kdy mám data organizované v nějakém storage a funkce, které různě s těmi daty pracují. Tam spadají relační databáze, globální proměnné, zásobníkové algoritmy. OOP naopak drží data pospolu ve skupině s operacemi, které s těmi daty pracují.

Ted jste smichal tolik veci dohromady, ze fakt nevim, s cim vlastne polemizujete. (Asi je to trochu strawman, protoze jste proti OOP postavil relacni model dat, ktery, podobne jako OOP, neni vselek.)

Pro me maji oba pristupy maji sve vyhody a nevyhody, neni mezi nimi ostre deleni (viz genericke funkce), a nelze rict, ze je jeden z nich horsi nebo lepsi. Vtip je v tom, ze ja se nesnazim dokazat, ze OOP pristup je striktne horsi nez proceduralni. Jen to, ze se to s nim prehani. Konkretne napriklad, nemam pocit, ze Linuxove jadro je horsi program jen proto, ze ovladace zarizeni nejsou objekty.

ondra.novacisko.cz

Re: Jste zastánci OOP programování?
« Odpověď #201 kdy: 26. 02. 2011, 12:27:59 »
Konkretne napriklad, nemam pocit, ze Linuxove jadro je horsi program jen proto, ze ovladace zarizeni nejsou objekty.

Já ano. Mimochodem, oni jsou to objekty. Kolikrát napsané v čistém C. Místo interfaců tam najdete třeba tabulky funkcí. Když se podíváte, jak jsou implementované interfacy, zjistíte, že to jsou tabulky funkcí. Jde o to, že tabulka funkcí se rychleji implementuje pomocí interface, než pomocí tabulky funkcí v čistém C. Asi tak 100x.

Další výhodou je, že zatímco v čistém C si každý autor udělá "ty svoje objekty", dá si k nim svoje pravidla, C++ zavádí jednotná pravidla, jak tyhle objekty a tabulky funkcí implementovat. A programátor se soustředí až na využití těchto technik a neřeší, jestli jeho kolega udělal ten interface jako pointer nebo jako dva pointery, nebo jako pointer na pointer, nebo tu tabulku narval přimo do te struktury představující objekt.

(mimochodem, doporučuju tento článek: http://zdrojak.root.cz/clanky/konec-starych-programatorskych-casu/ )

Bone Flute X

Re: Jste zastánci OOP programování?
« Odpověď #202 kdy: 26. 02. 2011, 15:43:50 »
Citace
To nejak nechapu. Takze ten interface tam mate proto, abyste obesel nejake omezeni?
Ne, naopak. To interface tam mám proto, aby na mě překladač řval, když se uklepnu.

Citace
Vec je, ze nevidim duvod, proc nepovazovat ekvivalentni objekty za ekvivalentni (2 tridy se stejnou podmnozinou metod), aniz by nekdo explicitne prohlasil, ze jsou ekvivalentni (definoval interface).
Tak na to jsem našel někde příklad, který mne přesvědčil:

class Loď:
  def potopit():
     pass

class Potápěč:
  def potopit():
     pass

inst.potopit()

Citace
No a, tak ten modul bude trochu vetsi. Ja bych se toho nebal. Me prijde, ze tyhle Javove vynalezy se snazi strasne stavet nejruznejsi bariery (delit veci do trid), ktere ve skutecnosti vubec nejsou potreba.
No, v tom je ten problém. Mě ty Javovské vynálezy vyhovují. A mě ty bariéry pomáhají. Pro mě jsou potřeba. Je to stejné, jako když má auto kapotu, který vypne nastartování. Můžete tam zmáčknout ten čudlík, a tím tuto ochranu obejít, ale faktem je, že je dost užitečné, že se vám auto nerozjede když se mu vrtáte v motoru. Takové ochrany jsou v tiskárně, v cirkulárce, v ledasčems. A považuji to za výhodu, ne zbytečné omezování.
Opravdu hodně by mě vadilo, když bych měl v jednom modulu věci, které spolu nesouvisejí, a které umožňují interakce = sideoefect, když je špatně použiju. To by mi opravdu hodně vadilo.
Je to jeden ze základů programování, který ctím. Žádné sideefekty, páč, když se k tomu po čase vrátím, tak to musí být naprosto jasné.

Citace
Protoze to svazani ma svoji cenu, a za tu platite tim, ze jste si vytvoril umelou barieru, kde tu funkci muzete pouzit. A to vsechno jen za subjektivni pocit toho, co je neporadek.
Já tam žádnou cenu nevidím.
Pokud je to funkce/metoda patřící k oběktu, tak ji jinde použít nechci.
Pokud je to funkce, která k tomu objektu nepatří, tak o tom se nebavíme.
Takže jaká cena? Jaká umělá bariéra? Nerozumím.

Citace
Me se hrozne libi Common Lisp. Nemyslim, ze se v nem nedaji psat komplexni systemy, i bez OOP nadstavby, kterou ma (CLOS). Kdyz ho zacnete studovat, prijdete na to, ze OOP je jen jedna z mnoha abstrakci. Kazda abstrakce je samozrejme pokrok v boji proti entropii, ale nesmi se to prehanet.
Mě se Lisp také líbí. A s tímto textem s vámi souhlasím.

Citace
Jenze Java to prehnala. Vsechno v zivote zkratka neni trida.
Dle mého má java jiné problémy, než že to přehnala. A druhak, když si přečtete znovu můj první příspěvek, já jsem netvrdil, že OOP reflektuje realitu. Podle mne vůbec. Podle mne je OOP metodika, jak popsat problém, a jak bojovat s entropií a vlastní blbostí. V tom je OOP velmi dobré.

Citace
Tim se plete puvodni vyznam trid, totiz vyrobit novy typ (coz je to dobre pouziti), s vyznamem "usporadat veci k sobe" (ktery lepe resi modularni system prislusneho jazyka, v pripade CL jsou to balicky a systemy). A to neni dobre.
S tím bych nemohl souhlasit.

Žádný původní význam tříd neznám. Třída definuje a) datovou strukturu, b) přístup k prvků datové struktury, c) metody nad objektem/zprávy objektu. a) definuje typ, b) a c) se sice dá dá dělat pomocí modulů, dokonce i v Javě, ale ty třídy to prostě lépe reprezentují. Je to v jednom chumlu. To se mi líbí, to mi přijde čitelné. Proč by to nebylo dobré? Proč by jste ty metody/funkce odtrhával a dával někam pryč?


JS

Re: Jste zastánci OOP programování?
« Odpověď #203 kdy: 26. 02. 2011, 15:56:12 »
Já ano. Mimochodem, oni jsou to objekty. Kolikrát napsané v čistém C. Místo interfaců tam najdete třeba tabulky funkcí. Když se podíváte, jak jsou implementované interfacy, zjistíte, že to jsou tabulky funkcí. Jde o to, že tabulka funkcí se rychleji implementuje pomocí interface, než pomocí tabulky funkcí v čistém C. Asi tak 100x.

Ja tedy ten pocit nemam. Udelat tabulku funkci znamena v podstate tu stejnou praci - definujete signatury funkci ve strukture, definujete ty clenske funkce, definujete tu tabulku. Pokud byste chtel neco jako dedicnost, muzete tam dat nulovy odkaz, a hned vidite, zda ten objekt tu metodu implementuje nebo ne. S interfacy by tohle bylo pres ruku, protoze musite definovat vic interfacu, zjistovat, zda funkce podporuje dany interface .. atd. (Ale jak je definovat? Ruzna zarizeni maji ruzne pozadavky a ty se muzou ruzne krizit.) A jak rikas dal, lze to implementovat ruzne, takze pouzit abstrakci z jazyka me zavazuje k urcitemu druhu implementace. Je zrejme, ze oboji sve vyhody a nevyhody, tak proc se prit? (Ostatne, mam pocit, ze tohle zacina duplikovat tvou predchozi diskusi s Blekem.)

Proste, OOP je abstrakce jako kazda jina, nema smysl se prit. Je jasne, ze by vyvojari Linuxu usetrili, kdyby se rozhodli psat ho v jazyce s makry (myslim poradna makra, ktera dovoluji definovat veci jako OOP, ne jen C makra, i ta jim ale dost pomahaji). Ovsem takovy jazyk na trhu neni (mozna se tomu blizi Forth).

JS

Re: Jste zastánci OOP programování?
« Odpověď #204 kdy: 26. 02. 2011, 16:35:12 »
Ne, naopak. To interface tam mám proto, aby na mě překladač řval, když se uklepnu.

No, stale mi prijde, ze vam to sice chyby najde, ale za cenu vetsiho psani, takze nula od nuly pojde. Rad bych videl priklad. Dejme tomu, ze to mame implementovane proceduralne pres tabulku. Jakym druhum chyb zabrani implementovat to pres rozhrani?

Citace
Tak na to jsem našel někde příklad, který mne přesvědčil:
...

Mel jsem podobny priklad v hlave, kdyz jsem to psal, ale moc jsem to nezkoumal. Na prvni pohled je to asi pravda, ale i tak mi prijde, ze to za tenhle (ne az tak casty) omyl moc nestoji, definovat vsude interface. A kdybyste bral interface jako zpusob, jak predejit jmennym konfliktum, tak vam to stejne nepomuze, az budete chtit zavest tridu Ponorka. Budu se nad tim muset jeste zamyslet, zda neexistuje lepsi reseni; je to legitimni problem.

Citace
No, v tom je ten problém. Mě ty Javovské vynálezy vyhovují. A mě ty bariéry pomáhají. Pro mě jsou potřeba. Je to stejné, jako když má auto kapotu, který vypne nastartování. Můžete tam zmáčknout ten čudlík, a tím tuto ochranu obejít, ale faktem je, že je dost užitečné, že se vám auto nerozjede když se mu vrtáte v motoru. Takové ochrany jsou v tiskárně, v cirkulárce, v ledasčems. A považuji to za výhodu, ne zbytečné omezování.

Me se libi Paul Grahamova filozofie, ze nejprve se ten program vytvori na hrubo, a pak se pozdeji vylepsuje a stabilizuje (asi se tomu rika rapid-prototyping?). Proto se na to divam z hlediska hypotetickeho budouciho jazyka, ktery na zacatku necha programatorovi velkou svobodu, a teprve pozdeji (castecne nezavisle na funkcnim kodu, a castecne na zkusenosti z jeho chovani) pomuze programatorovi vztycit tyto bariery a najit tak dalsi chyby. Zatim takovy jazyk neni, Common Lisp se mu blizi, ale aniz by si to nejak uvedomoval. Takze ja jsem spis proti predcasnemu staveni techto barier (a jejich fakticke nemoznosti je pozdeji ignorovat).

Citace
Opravdu hodně by mě vadilo, když bych měl v jednom modulu věci, které spolu nesouvisejí, a které umožňují interakce = sideoefect, když je špatně použiju. To by mi opravdu hodně vadilo.

Nevim. Snazit se definovat vsechno tak, aby byly nezavisle veci maximalne explicitne oddelene mi prijde jako diminishing returns. Od jiste urovne detailu uz se to proste nemuze vyplatit. Ale jinak bych s tim souhlasil, ale nemyslim, ze to je neco, co prinesl OOP pristup.

Citace
Já tam žádnou cenu nevidím.
Pokud je to funkce/metoda patřící k oběktu, tak ji jinde použít nechci.
Pokud je to funkce, která k tomu objektu nepatří, tak o tom se nebavíme.
Takže jaká cena? Jaká umělá bariéra? Nerozumím.

Co kdyz ta funkce pracuje s vic nez jednim objektem? Pak ji priradit konkretnimu z nich je umela bariera.

Citace
Žádný původní význam tříd neznám. Třída definuje a) datovou strukturu, b) přístup k prvků datové struktury, c) metody nad objektem/zprávy objektu. a) definuje typ, b) a c) se sice dá dá dělat pomocí modulů, dokonce i v Javě, ale ty třídy to prostě lépe reprezentují. Je to v jednom chumlu. To se mi líbí, to mi přijde čitelné. Proč by to nebylo dobré? Proč by jste ty metody/funkce odtrhával a dával někam pryč?

Existuji jiste i funkce, ktere zadny novy typ nepotrebuji (a odpada tak duvod mit je v tride). Stejne tak, existuji funkce, ktere zpracovavaji vice ruznych typu. Tohle IMHO krasne resi v CLOSu genericke funkce. Proto je dobre funkce (alespon nektere) odtrhnout od datovych typu. Co kdyz si date funkci dvou typu do tridy toho prvniho, a pozdeji ji budete chtit rozsirit v tom druhem (ale kod muze zustat stejny)? OOP v Jave vam v tom zabrani, v CLOSu (nebo Go, ktere tento napad tusim prejalo) to bude snadne.

Bone Flute X

Re: Jste zastánci OOP programování?
« Odpověď #205 kdy: 26. 02. 2011, 17:23:32 »
Citace
No, stale mi prijde, ze vam to sice chyby najde, ale za cenu vetsiho psani, takze nula od nuly pojde. Rad bych videl priklad. Dejme tomu, ze to mame implementovane proceduralne pres tabulku. Jakym druhum chyb zabrani implementovat to pres rozhrani?
No, to já hlavně nevím jak by to fungovalo přes tabulku...
Interface mi zajistí, že objekt, který přišel má metodu getIvoicer() a getRule(). Díky tomu mohu v kódu napsat něco jako:

inst.getInvoicer().process(inst.getRule)

Já už jsem z céčka vypadl, ale v Pythonu bych musel po vstupu kontrolovat, zda ty metody ten objekt má. Klasické duck typing. Navíc, když vytvořím implementaci nějaké struktury, nesoucí tuto logiku, tak mě to nezkontroluje, že jsem zapoměl na jednu metodu dokavad to nepoužiju. V praxi samozřejmě to bude tak, že problémy vzniknou až v okamžiku refactoringu.

Tedy shrnuto, rozhraní zajištuje:
Že funkci/metodě předávám správný objekt. Třeba, že mi tam něco neuteklo.
Že objekt implementuje všechny povinné metody.

Citace
Me se libi Paul Grahamova filozofie, ze nejprve se ten program vytvori na hrubo...
To je sice hezký, ale má to dva háčky: Jednak je to metodika, kterou se budou muset lidé naučit. Já třeba podobný přístup v pythonu opustil, protože mě iritovalo, jak to furt nefunguje - tedy je to přesný opak XP. A druhý háček je v tom, že jak sám říkáte, nemáme implementaci do jazyka.
A tady se bavíme o tom, zda jsme zastánci OOP, ne co je nejlepší. Nejlepší je Ferda, to už víme.

Citace
Nevim. Snazit se definovat vsechno tak, aby byly nezavisle veci maximalne explicitne oddelene mi prijde jako diminishing returns.
No, moje zkušenost je taková, že když si práci zjednoduším, a dělám noname objekty s veřejnými atributy, tak pak honím chyby po všech čertech. Takže já prohlašuji, že je to ještě daleko před tou hranicí.

Citace
nemyslim, ze to je neco, co prinesl OOP pristup
Podle wikipedie, je zapouzdření jedním ze základních kamenů OOP. Céčko, Paskal, nedejbože Basic zapouzdření před příchodem Smalltaku, Objective C, nebo C++ neumožňovali. Takže já si myslím, že to OOP přístup přinesl.

Citace
Co kdyz ta funkce pracuje s vic nez jednim objektem? Pak ji priradit konkretnimu z nich je umela bariera.
Ano. Je. Proč bych takovou kravinu dělal?

Citace
Existuji jiste i funkce, ktere zadny novy typ nepotrebuji (a odpada tak duvod mit je v tride).
Samozřejmě. No a? To není nic proti OOP. Prostě mám izolované funkce, které nějakým způsobem pracují s objekty. Pokud si to jazyk vynucuje je přiřadit nějaké třídě (Java), tak si na to vytvořím třídu. Nejdřív budu prskat, jako vy, že je to zbytečnost, ale pak zjistím, že vlastě ještě potřebuju, aby tu funkci používali jen a pouze tyto a tyto třídy, a tak spřísním oprávnění a umístím to do modulu. Nakonec zjistím, že to stejně někam umístit musím, ve vzduchu to bejt nemůže.
Fajn, v čem je problém?
Po pravdě řečeno, když bych měl projekt, ve kterém by se tato situace stávala často, pravděpodobně bych změnil styl, nebo jazyk. A nedělal to dle OOP. V mé praxi je to ale přesně naopak. Většinou těchto izolovaných funkcí je minimum. A to prosím nedělám GUI.

Citace
Co kdyz si date funkci dvou typu do tridy toho prvniho, a pozdeji ji budete chtit rozsirit v tom druhem (ale kod muze zustat stejny)?
Nevím zda vám rozumím. Není to ten samej problém co víše?

ondra.novacisko.cz

Re: Jste zastánci OOP programování?
« Odpověď #206 kdy: 26. 02. 2011, 19:28:47 »
Co kdyz ta funkce pracuje s vic nez jednim objektem? Pak ji priradit konkretnimu z nich je umela bariera.

Můžete si vybrat. Záleží zpravidla na tom, jak který objekt má blíže k operaci té funkce.

obj.save(stream)
nebo
stream.save(obj)
?

No v tom prvním případě musí obj znát stream. V tom druhém musí stream znát obj. Pokud chci psát univerzální streamy, a objekty, které se chtějí serializovat do streamu, pak volím první metodu, protože stream nic o objektech vědět nemusí, ale objekty ano.

(jde o to, že abych mohl deklarovat metodu save u objektu, musím říct co je stream. Pokud to budu chtít deklarovat u streamu, musím dodat objekt. Je zde taky docela pěkně vidět zodpovědnost. V prvním případě je za uložení do streamu zodpovědný objekt sám. V druhém případě tu zodpovědnost nese stream, což uznáte, že je blbost)

D.A. Tiger

  • ****
  • 486
  • Tygr, který žere tučňáka ;-)
    • Zobrazit profil
    • E-mail
Re: Jste zastánci OOP programování?
« Odpověď #207 kdy: 27. 02. 2011, 00:13:11 »

Citace
Vec je, ze nevidim duvod, proc nepovazovat ekvivalentni objekty za ekvivalentni (2 tridy se stejnou podmnozinou metod), aniz by nekdo explicitne prohlasil, ze jsou ekvivalentni (definoval interface).
Tak na to jsem našel někde příklad, který mne přesvědčil:

class Loď:
  def potopit():
     pass

class Potápěč:
  def potopit():
     pass

inst.potopit()


Tak tohle je přesně věc, která se mi na těch tzv. "čistě objektových" jazycích vůbec nelíbí. Loď a potápěč je něco absolutně jiného a v tomto kontextu i potopení daného objektu je odlišná akce, s diametrálně odlišnými důsledky. Zlatá typová kontrola C++...

Re: Jste zastánci OOP programování?
« Odpověď #208 kdy: 27. 02. 2011, 00:37:32 »
Tak tohle je přesně věc, která se mi na těch tzv. "čistě objektových" jazycích vůbec nelíbí. Loď a potápěč je něco absolutně jiného a v tomto kontextu i potopení daného objektu je odlišná akce, s diametrálně odlišnými důsledky. Zlatá typová kontrola C++...
To není vlastnost "čistě objektových" jazyků, to je vlastnost jazyků používajících duck typing. V duck-typingu a ve strukturálních typových systémech můžou být typy kompatibilní i bez toho, aby tak byly explicitně deklarovány. V typovém systému, který má C++, na to explicitně deklarovány být musí - je to tzv. nominální typový systém.

S tím, jestli je jazyk čistě objektový (jako např. Ruby - to neobsahuje žádné jiné datové typy než třídy), to nemá nic společného. Mimochodem, Python čistě objektový není.

Re: Jste zastánci OOP programování?
« Odpověď #209 kdy: 27. 02. 2011, 01:11:20 »
Vy sa tu hádate čo je lepšie a ja furt neviem o čom... Každý o tom hovorí, už mi ľudia posielali siahodlhé články, ale nikde v tých tonách slov som nevidel príklad a uvedené rozdiely (ne)OOP programovania.
Mohol by mi to prosím niekto vysvetliť (najlepšie na nejakom príklade v PHP, ale v podstate je to jedno)? Ďakujem.