Co si myslíte o OOP?

[Mirek Prýmek]

Dobré přednášky o pokročilejších vlastnostech má David Beazley.

No, když tyhle "pokročilejší" věci porovnám třeba s C++, tak bych je rozhodně nenazval "komplexní"

(to není kritika, to je dobře)

[Reklama]

[operator]

Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict

Modul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?

Jo, ale misto toho, abych zavadel zbytecne koncepty trida, objekt a modul, muzu pouzit proste jen dict.

Dedicnost muzes v dictu naimplementovat jednoduse. Prolinkujes par dictu dohromady a kdyz hledas konkretni metodu/odpoved na prichazejici zpravu projedes ten seznam dictu dokud nenajdes tu funkci.

[dict1, dict2, dict3]

ekvivalentni

class C: pass
class B(C): pass
class A(B): pass

kde A odpovida dict1, B dict2, C dict3

Kdybys implementoval novej jazyk tak udelas nejpravdepodobneji prave tohle.

Tim ale neimplementujes dedicnost v dictu, a dedicnost pomoci seznamu dictu a kodu, ktery to osetri, pricemz seznam je zase jen nadstavba nad dictem. Jestli tim chces rict, ze dokazes pomoci dictu emulovat chovani trid, tak asi ano, ale budes k tomu potrebovat slozity kod, c3 linearizaci a bude to tezkopadne na pouzivani. A v tom spociva smysl trid, modulu atd. Je to abstrakce, ktera ti zjednodusi a zprehledni programovy kod. Pokud to nepotrebujes, muzes zkusit programovat primo ve strojovem kodu. Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.

Dict se v pythonu pouziva na implementaci objektu, a protoze vsechno je v pythonu objekt, muzeme rict, ze dict je soucasti vseho, je to zakladni datova struktura Pythonu, proto taky na vsechno funguje dir(). Ale neznamena, ze kdyz to pouziva dict, tak muzeme rikat, ze je to dict a nic jineho nepotrebujeme. Protoze s takovou muzeme jit hloub a prohlasit, ze vsechno je jen cislo, resp. organizovany seznam jednicek a nul, cimz jsme zpatky u strojoveho kodu.

[gll]

Dobré přednášky o pokročilejších vlastnostech má David Beazley.

No, když tyhle "pokročilejší" věci porovnám třeba s C++, tak bych je rozhodně nenazval "komplexní"

(to není kritika, to je dobře)

nemůžeš hodnotit komplexitu toho co neznáš.

[operator]

zvláště u poměrně komplexního pythonu

Co je na Pythonu komplexního?

a) pisu pomerne, kde jsi vytrhl z kontextu, že ho pomeruji k JS
b) python jako jazyk ma mnoho ruznych abstrakci a pokryva nekolik paradigmat
c) python ma dynamickou introspekci a umoznuje programovat program
d) a po teto diskusi mohu dodat, python je dynamicky, coz predstavuje slozitost, kterou mnozi neumi pobrat

[gll]

Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict

Modul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?

Jo, ale misto toho, abych zavadel zbytecne koncepty trida, objekt a modul, muzu pouzit proste jen dict.

Dedicnost muzes v dictu naimplementovat jednoduse. Prolinkujes par dictu dohromady a kdyz hledas konkretni metodu/odpoved na prichazejici zpravu projedes ten seznam dictu dokud nenajdes tu funkci.

[dict1, dict2, dict3]

ekvivalentni

class C: pass
class B(C): pass
class A(B): pass

kde A odpovida dict1, B dict2, C dict3

Kdybys implementoval novej jazyk tak udelas nejpravdepodobneji prave tohle.

Tim ale neimplementujes dedicnost v dictu, a dedicnost pomoci seznamu dictu a kodu, ktery to osetri, pricemz seznam je zase jen nadstavba nad dictem. Jestli tim chces rict, ze dokazes pomoci dictu emulovat chovani trid, tak asi ano, ale budes k tomu potrebovat slozity kod, c3 linearizaci a bude to tezkopadne na pouzivani. A v tom spociva smysl trid, modulu atd. Je to abstrakce, ktera ti zjednodusi a zprehledni programovy kod. Pokud to nepotrebujes, muzes zkusit programovat primo ve strojovem kodu. Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.

Dict se v pythonu pouziva na implementaci objektu, a protoze vsechno je v pythonu objekt, muzeme rict, ze dict je soucasti vseho, je to zakladni datova struktura Pythonu, proto taky na vsechno funguje dir(). Ale neznamena, ze kdyz to pouziva dict, tak muzeme rikat, ze je to dict a nic jineho nepotrebujeme. Protoze s takovou muzeme jit hloub a prohlasit, ze vsechno je jen cislo, resp. organizovany seznam jednicek a nul, cimz jsme zpatky u strojoveho kodu.

javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.

[Reklama]

[operator]

Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict

Modul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?

Jo, ale misto toho, abych zavadel zbytecne koncepty trida, objekt a modul, muzu pouzit proste jen dict.

Dedicnost muzes v dictu naimplementovat jednoduse. Prolinkujes par dictu dohromady a kdyz hledas konkretni metodu/odpoved na prichazejici zpravu projedes ten seznam dictu dokud nenajdes tu funkci.

[dict1, dict2, dict3]

ekvivalentni

class C: pass
class B(C): pass
class A(B): pass

kde A odpovida dict1, B dict2, C dict3

Kdybys implementoval novej jazyk tak udelas nejpravdepodobneji prave tohle.

Tim ale neimplementujes dedicnost v dictu, a dedicnost pomoci seznamu dictu a kodu, ktery to osetri, pricemz seznam je zase jen nadstavba nad dictem. Jestli tim chces rict, ze dokazes pomoci dictu emulovat chovani trid, tak asi ano, ale budes k tomu potrebovat slozity kod, c3 linearizaci a bude to tezkopadne na pouzivani. A v tom spociva smysl trid, modulu atd. Je to abstrakce, ktera ti zjednodusi a zprehledni programovy kod. Pokud to nepotrebujes, muzes zkusit programovat primo ve strojovem kodu. Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.

Dict se v pythonu pouziva na implementaci objektu, a protoze vsechno je v pythonu objekt, muzeme rict, ze dict je soucasti vseho, je to zakladni datova struktura Pythonu, proto taky na vsechno funguje dir(). Ale neznamena, ze kdyz to pouziva dict, tak muzeme rikat, ze je to dict a nic jineho nepotrebujeme. Protoze s takovou muzeme jit hloub a prohlasit, ze vsechno je jen cislo, resp. organizovany seznam jednicek a nul, cimz jsme zpatky u strojoveho kodu.

javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.

Protirecis si, marketing je uspokojovani potreb zakaznika. Cim komplexnejsi veci se v JS programuji, tim vice takove abstrakce jsou potreba. Proto byly pozadovany a proto byly implementovany. 

Mne v JS v prohlizecich treba porad jeste chybi moznost importovat z jednoho js souboru druhy.

[operator]

Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.

Aby nedoslo k nedorozumeni. Programem tady minim programovy kod. Vzhledem k tomu, ze to zjednodusi programovani, to umoznuje ve vysledku vznik komplexnejsich programu ve smyslu aplikaci.

[Kit]

Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.

Aby nedoslo k nedorozumeni. Programem tady minim programovy kod. Vzhledem k tomu, ze to zjednodusi programovani, to umoznuje ve vysledku vznik komplexnejsich programu ve smyslu aplikaci.

Jinak řečeno pro každou úroveň abstrakce použiješ jiný syntaktický cukr. Čitelnost a přehlednost programu se tím zvýší a sníží se riziko chyb.

[operator]

Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.

Aby nedoslo k nedorozumeni. Programem tady minim programovy kod. Vzhledem k tomu, ze to zjednodusi programovani, to umoznuje ve vysledku vznik komplexnejsich programu ve smyslu aplikaci.

Jinak řečeno pro každou úroveň abstrakce použiješ jiný syntaktický cukr. Čitelnost a přehlednost programu se tím zvýší a sníží se riziko chyb.

Asi bych nemluvil o urovni, ale jinak ano, presne to je cil, zjednoduseni programoveho kodu. Krome toho se take zvysi efetivita tvorby programu.

[gll]

Asi bych nemluvil o urovni, ale jinak ano, presne to je cil, zjednoduseni programoveho kodu. Krome toho se take zvysi efetivita tvorby programu.

Class v Javascriptu nic nezjednodušuje. Kód nezkracuje. Je to jen omáčka navíc.

[Dor]

Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Alespon v erlangu je objekt nejaka isolovana vypocetni jednotka (actor, agent, proces, vlakno, apod.) a ne pouze obycejny dict v prestrojeni.

Tohle už je na mě příliš konkrétní. Chtěl jsem se jen svěřit se zkušeností, že hodně malé "izolované výpočetní jednotky" pak mají často skoro všechno veřejné, protože jsou tak malé, že už v nich není co schovávat.

Pokud je problem ze kolegove nemuzou byt svazani sveraci kazajkou jazyka, jako v pripade chybejicich rozhrani v dynamickych jazycich, pak je to organizacni problem. V dynamickym jazyce bouchne driv nez ve statickym. Co je lepsi, tezko rict. Pro me je lepsi kdyz ten bolak praskne driv nez pozdeji a zacne se resit skutecny problem - spatna organizace lidi.

Tohle mi přijde tak trochu jako argument: nedávejte na školní schodiště zábradlí, ať se dříve ukáže, že máte nevychované žáky. Jako jasně že se místo interface dá napsat lepší komentář. Ale když tam musí být interface, je o problém méně.

Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.

Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.

[Kit]

Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.

Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.

Funkcionální programování propagují zejména programátoři, kteří nepochopili principy OOP. Vždycky mi ukážou blbě napsaný objektový program a začnou mi tvrdit, že takhle programovat nechtějí. Já také ne. Nad každým objektem je třeba se zamyslet tak, aby nebyl kuchařskou knihou nebo spíží, ale kuchařem.

Funkcionální programování však nepovažuji za špatné - je jen jiné. Dá se skvěle kombinovat s objektovým - zejména v jazycích, které podporují obojí.

[v]

Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.

Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.

Funkcionální programování propagují zejména programátoři, kteří nepochopili principy OOP. Vždycky mi ukážou blbě napsaný objektový program a začnou mi tvrdit, že takhle programovat nechtějí. Já také ne. Nad každým objektem je třeba se zamyslet tak, aby nebyl kuchařskou knihou nebo spíží, ale kuchařem.

Funkcionální programování však nepovažuji za špatné - je jen jiné. Dá se skvěle kombinovat s objektovým - zejména v jazycích, které podporují obojí.

zkuste častěji ukazovat příklady dobře napsaných OO programů

[Ondra Satai Nekola]

Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.

Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.

Funkcionální programování propagují zejména programátoři, kteří nepochopili principy OOP. Vždycky mi ukážou blbě napsaný objektový program a začnou mi tvrdit, že takhle programovat nechtějí. Já také ne. Nad každým objektem je třeba se zamyslet tak, aby nebyl kuchařskou knihou nebo spíží, ale kuchařem.

Funkcionální programování však nepovažuji za špatné - je jen jiné. Dá se skvěle kombinovat s objektovým - zejména v jazycích, které podporují obojí.

zkuste častěji ukazovat příklady dobře napsaných OO programů

Jo.... Kit by nam mohl konecne neco ukazat

[Kadet]

Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.

Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.

Funkcionální programování propagují zejména programátoři, kteří nepochopili principy OOP. Vždycky mi ukážou blbě napsaný objektový program a začnou mi tvrdit, že takhle programovat nechtějí. Já také ne. Nad každým objektem je třeba se zamyslet tak, aby nebyl kuchařskou knihou nebo spíží, ale kuchařem.

Funkcionální programování však nepovažuji za špatné - je jen jiné. Dá se skvěle kombinovat s objektovým - zejména v jazycích, které podporují obojí.

Problem je mozna v tom, ze OOP neni programovaci paradigma, ale vypocetni model. Podobny Petriho sitim. System, kde si mnozina objektu posila zpravy, muzu naimplementovat v cemkoliv. Muzu k tomu pouzit dokonce i C++ nebo Javu, tedy jazyky s dvoji koncepci modulu, tj. modul a trida.


The AlanKay definition of OO is largely that given by CarlHewitt for the ActorsModel which is a model of computation, not a programming paradigm. AlanKay has acknowledged explicitly this derivation.

http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented