Jste zastánci OOP programování?

[D.A. Tiger]

duck typing prohlašuje, že "chodí to jako kachna, plave to jako kachna, kváká to jako kachna - je to kachna", od toho to má i to jméno, tak klasicky, bez duck typingu se pracuje tak, že "Je to kachna? Sice to kváká, plave, chodí jako kachna, ale má to na sobě cedulku, že je to veterán z vojny, takže to kachna není."

Bez urážky ale z toho čo som prečítal tak na tomto fóre je naozaj minimum ludí, ktorí vedia programovať a rozumejú OOP a preto tu splietate takéto nezmysli o kachnách. Sú to naozaj drísty. Na roote by sa mala zaviesť sekcia vtipy a všetky príspevky z tohoto threadu do nej presunúť.

Myslím, že by jsi tu sekci s takovými prohlášeními vedl, to jednak. Druhak, nikde jsem o sobě nepsal, že jsem nějaký excelentní programátor, programování je pro mě odreagování a zábavný druh seberealizace, avšak v žádném případě filozofie a smysl života - takže si na rozdíl od tebe uvědomuji, že nemám patent na rozum a nemám potřebu bez nějakých argumentů shazovat někoho jiného, kdo daný problém vidí jinak, nebo zastává trochu jiný názor.

[Reklama]

[Petr Mejzlík]

Přiřazování do tříd je velmi oblíbenou technikou v OOP, akorát je třeba umět přiřadit objekt do vícero tříd, což je třeba problém Javy a jiných jazyků, jdoucí třetí cestou.

Příklad kachny jako objektu, který patří do třídy plavající, kvákající a vypadající jako kachna.

To jde dobře v prototypových jazycích, např. Javascript. Kam objekt patří je určeno jeho atributy (vlastnostmi) - tj. duck typing; nejsou tam žádné třídy. Python používá taky duck typing na určení, kam objekt patří, ale třídy narozdíl od prototypových jazyků má - objekty patřící do jedné třídy můžou sdílet atributy a metody (tzv. třídní atributy a metody).

[JS]

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.

Diky, tohle jsem hledal. Vedel jsem, ze jsem tak nejak fanda strukturalniho systemu a ne nominalniho (zejmena co se tyce interfaces), ale nevedel jsem, ze to rozliseni existuje.

[JS]

To jde dobře v prototypových jazycích, např. Javascript. Kam objekt patří je určeno jeho atributy (vlastnostmi) - tj. duck typing; nejsou tam žádné třídy. Python používá taky duck typing na určení, kam objekt patří, ale třídy narozdíl od prototypových jazyků má - objekty patřící do jedné třídy můžou sdílet atributy a metody (tzv. třídní atributy a metody).

No ale kdyz chcete mit dispatch (tj. virtualni metody), tak prece musite nejak oznacit ten typ. Nemuzete vsechno resit jen strukturalne.

[Viky]

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).

Já myslím, že jak Lisp (a nejen Common), tak Forth se tomu blíží ze všech nejvíc. V těchto jazycích programuji tak, že nejdřív inkrementálně zmatlám něco dohromady - ono totiž ani při nejlepší vůli není možné dopředu odhanout všechny detaily, jež se člověku nachomýtnou přes cestu a z některých těch zdánlivých detailů se mohou vyklubat pěkné oříšky - a pak to udělám z jedné vody načisto. To v podstatě doporučuje i Chuck Moore (kolik let před Grahamem? :-) Ovšem už se znalostí těch problémů a vytvořiv si k tomu potřebné syntaktické nástroje, v jejichž rámci a s jejichž pomocí to budu realisovat.

[Reklama]

[Sten]

No ale kdyz chcete mit dispatch (tj. virtualni metody), tak prece musite nejak oznacit ten typ. Nemuzete vsechno resit jen strukturalne.

V duck typingu samozřejmě virtuální metody fungují, ale jsou řešeny jinak. Objekt tam s sebou nese jména svých členů a dispatch tak řeší program za běhu (prostě řeknete objektu jméno metody, kterou chcete volat, a on vám ji dodá). U nominálně typovaných jazyků objekty nenesou jména svých členů a dispatch tak řeší kompilátor (rovnou určí, kde v objektu bude umístěn ukazatel na příslušnou metodu, nemusí se hledat v mapě členů). Výhody a nevýhody jsou zřejmé: druhé stojí méně paměti a výkonu, ale omezuje možnosti dynamických změn chování.

Ještě existuje střední cesta, kterou se vydalo třeba Qt. Je sice nominálně typované, takže většina dispatchů řeší kompilátor, ale stále si nese s sebou i jména členů tříd a tedy lze v nich i dynamicky hledat jako v duck typingu. Stojí to paměť, ale hledá se, jenom když to jinak nejde.

[ondra.novacisko.cz]

Při psaní šablon (kde objektem je "typ") používáme taku duck typing. Ale občas by se nějaký interface hodil. Když překladač při instanciování šablony zjistí, že nějaký typ nějaké metody neposkytuje, tak se ta chyba dost blbě loví.

[pravdokop]

Jsem, ale není nutno je používat dogmaticky vždy.
Nejraději mám C++ právě proto, že tam není nevypočitatelný garbage collector a mám tak všechny alokace i dealokace paměti pod naprostou kontrolou. A kdybych už moc chtěl, tak si jej napíši a jedu dál. Nebo si udělám objekty, které vše budou řešit samy (něco jako smart pointery). To vše se zachováním superrychlosti jazyka C a s možností psát kritické smyčky třeba i v assembleru!. Tomu se prostě nic nevyrovná!

[JS]

V duck typingu samozřejmě virtuální metody fungují, ale jsou řešeny jinak. Objekt tam s sebou nese jména svých členů a dispatch tak řeší program za běhu (prostě řeknete objektu jméno metody, kterou chcete volat, a on vám ji dodá).

No, to je pravda. Me slo spis o to, ze uz musite rict "trida ta a ta ma ty a ty metody", a tim padem jste castecne nominativni. Pritom by mohlo docela dobre strukturalne platit, ze nejaka metoda tridy zavisi na jinych metodach te tridy, takze by nebyl duvod neimplementovat tuto metodu ve vsech tridach, ktere implementuji predpoklady teto metody.

Asi jde o urcity druh dalsi urovne strukturalniho typovani, podobne jako jsou generika dalsi urovni nominativniho typovani. (A jsou s tim take spojene dalsi problemy, tezko rict, zda se to vubec vyplati resit.)

[Sten]

No, to je pravda. Me slo spis o to, ze uz musite rict "trida ta a ta ma ty a ty metody", a tim padem jste castecne nominativni. Pritom by mohlo docela dobre strukturalne platit, ze nejaka metoda tridy zavisi na jinych metodach te tridy, takze by nebyl duvod neimplementovat tuto metodu ve vsech tridach, ktere implementuji predpoklady teto metody.

Asi jde o urcity druh dalsi urovne strukturalniho typovani, podobne jako jsou generika dalsi urovni nominativniho typovani. (A jsou s tim take spojene dalsi problemy, tezko rict, zda se to vubec vyplati resit.)

Ale tohle všechny duck typing jazyky také řeší, jen jinak. Vezmete nějaký existující objekt (třeba medvěda), přidáte mu metodu pro kvákání a hned máte medvědokachnu. Pak samozřejmě lze implementovat i tovární objekty, které vytváří jiné objekty podle zadání (tak jsou implementovány třídy v Pythonu). Tyto dvě vlastnosti můžete libovolně kombinovat, takže klidně můžete vytvořit továrnu, která nechá jinou továrnu vytvořit objekt a pokud ten objekt má určité metody, tak je použije v přidané („virtuální“) metodě, a pokud je nemá, tak to implementuje jinak (nebo neimplementuje vůbec, jak chcete), v Pythonu by to bylo třeba takto:

Kód: [Vybrat]

class Kure:
    def kvakni(self):
        print 'Pip'

class Medved:
    def __init__(self, name='grizzly'):
        self.name = name

def tovarnaNaKachny(tovarna, *params, **kwparams):
    import new
    objekt = tovarna(*params, **kwparams)
    if hasattr(objekt, 'kvakni'):
        def kvakej(self):
            for i in xrange(5):
                self.kvakni()
        objekt.kvakej = new.instancemethod(kvakej, objekt, type(objekt))
    else:
        def kvakej(self):
            for i in xrange(5):
                print 'Kvak'
        objekt.kvakej = new.instancemethod(kvakej, objekt, type(objekt))
    return objekt

kachnokure = tovarnaNaKachny(Kure)
kachnomedved = tovarnaNaKachny(Medved, name='brtnik')

kachnokure.kvakej()
kachnomedved.kvakej()

[ondra.novacisko.cz]

Největší nevýhodu duck typingu vidím v tom, že chyby vyplývající z použití nevhodného objektu se kolikrát mohou objevit hodne hluboko v interní kódu, aniž by na první pohled bylo zřejmé, jak je to možné. Označit objekt rozhraním přeci jen lépe označuje očekávané chování, než abych musel ke každé funkci na vnějším API psát do dokumentace, které operace má kachna umět, případně to na první úrovni složitě testovat, aby případná polokachna nepropadla až někam dovnitř, kde způsobí katastrofu.