Co si myslíte o OOP?

[Kadet]

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.

Nejak nechapu tu neustalou potrebu v OO neco schovavat. Resit co bude schovane a co verejne. Ja radsi resim zadani problemu.

Zabradli a zaci. Pokud bychom zili v systemu, kde jsou zaci lehce nahraditelni, pak by to bylo skutecne dobre reseni. V nasem svete ale zaci nejsou lehce nahraditelni. V nasem svete ale jsou programy lehce nahraditelne. Alespon v nekterych organizacich. Zacal bych se divat na zdroj problemu zde.

funkcionalni vs objektove jazyky. Zmin jsem to v prispevku pred. OO jako simulace, objekty posilajici si zpravy, je vypocetni model, ne zpusob programovani. OO jako modularni programovani (java,C++) tj. vsemozne zapouzdrovani, zavislosti mezi moduly (dedicnost), mi prijde jako prekomplikovane imperativni a funkcionalni programovani v jednom. Napr. Trida neni nic jineho nez mnozina nekolika funkci.

[Reklama]

[Dor]

Nejak nechapu tu neustalou potrebu v OO neco schovavat. Resit co bude schovane a co verejne. Ja radsi resim zadani problemu.

Modifikátory přístupu (public, protected, private) považuji za takový lepší komentář, který je mi připomínán i překladačem.

Zabradli a zaci. Pokud bychom zili v systemu, kde jsou zaci lehce nahraditelni, pak by to bylo skutecne dobre reseni. V nasem svete ale zaci nejsou lehce nahraditelni. V nasem svete ale jsou programy lehce nahraditelne. Alespon v nekterych organizacich. Zacal bych se divat na zdroj problemu zde.

Zas až takový darvinista nejsem. Nahraditelnost softwaru je docela dobře vyjádřena jeho cenou.

funkcionalni vs objektove jazyky. Zmin jsem to v prispevku pred. OO jako simulace, objekty posilajici si zpravy, je vypocetni model, ne zpusob programovani. OO jako modularni programovani (java,C++) tj. vsemozne zapouzdrovani, zavislosti mezi moduly (dedicnost), mi prijde jako prekomplikovane imperativni a funkcionalni programovani v jednom. Napr. Trida neni nic jineho nez mnozina nekolika funkci.

Jádro našeho "sporu" je možná právě v tom, že ty počítáš každý konstrukt, který nemusíš napsat a já naopak počítám každý konstrukt, který napsat můžu. Samozřejmě že si můžu pamatovat, že tyhle 3 funkce jsou na sobě závislé a že má smysl volat jen tu jednu, protože ty zbylé dvě té první jen pomáhají a pro nic jiného nejsou použitelné. Nebo to můžu napsat do komentáře. Nebo můžu použít prefixy v názvu. Nebo to můžu zavřít do třídy a pomocí public označit tu metodu, kterou má smysl volat. A pak k tomu může přijít i Ind, který neumí slovo anglicky a na první pokus se trefí. No a nebo můžu hrdě tvrdit, že žádnýho pologramotnýho Inda do svého masterpiece kódu nepustím a hledat na pracovním trhu jenom samé guru s 200k platem.

[BoneFlute]

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.

To s tím Javascriptem je docela dobrá paralela. Protože díky tomu, že Javascript neměl žádný zvláštní cukr na vytváření objektů, vzniklo pár zajímavejch článků na toto téma. Díky tomu (a taky proto, že jsem si to zkusil :-) ) je mi jasné, že v tom Pythonu je objekt opravdu jen převlečený slovník. S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".

[Dor]

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.

Platí tedy i věta, že require, který načítá modul, byl přidán z marketingových důvodů a je to jen nadbytečný syntax sugar? A ty "marketingové důvody" znamenají, "Chceme aby to používalo více lidí, kteří nevědí, co je pro ně dobré."? Já jen aby to zaznělo pěkně naplno.

[gll]

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.

Platí tedy i věta, že require, který načítá modul, byl přidán z marketingových důvodů a je to jen nadbytečný syntax sugar? A ty "marketingové důvody" znamenají, "Chceme aby to používalo více lidí, kteří nevědí, co je pro ně dobré."? Já jen aby to zaznělo pěkně naplno.

ES6 moduly a importy. Require není jazykový konstrukt, to je jen obyčejná funkce.

[Reklama]

[Kadet]

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.

Platí tedy i věta, že require, který načítá modul, byl přidán z marketingových důvodů a je to jen nadbytečný syntax sugar? A ty "marketingové důvody" znamenají, "Chceme aby to používalo více lidí, kteří nevědí, co je pro ně dobré."? Já jen aby to zaznělo pěkně naplno.

Nevim jak vypada implementace require. Ale prislo mi, ze je to jen funkce. A javascript uz koncept funkce ma, takze nic nemuzel pridavat. Kdyby museli upravit jazyk kvuli necemu, co jde implementovat pouhou funkci, pak ano, bylo by to pridani nadbytecneho cukru.

Marketingove dduvody, aby to pouzivalo vic lidi, jsou dost presne vyjadreni situace. Javascript mel prototypy vychazejici ze Selfu. To je presne co tady popisuju. Prolinkovany dicty. Nic vic. Nekdo ted pridal cukr na classy. Proc? Za me je odpoved marketing.

[Kadet]

Nejak nechapu tu neustalou potrebu v OO neco schovavat. Resit co bude schovane a co verejne. Ja radsi resim zadani problemu.

Modifikátory přístupu (public, protected, private) považuji za takový lepší komentář, který je mi připomínán i překladačem.

Zabradli a zaci. Pokud bychom zili v systemu, kde jsou zaci lehce nahraditelni, pak by to bylo skutecne dobre reseni. V nasem svete ale zaci nejsou lehce nahraditelni. V nasem svete ale jsou programy lehce nahraditelne. Alespon v nekterych organizacich. Zacal bych se divat na zdroj problemu zde.

Zas až takový darvinista nejsem. Nahraditelnost softwaru je docela dobře vyjádřena jeho cenou.

funkcionalni vs objektove jazyky. Zmin jsem to v prispevku pred. OO jako simulace, objekty posilajici si zpravy, je vypocetni model, ne zpusob programovani. OO jako modularni programovani (java,C++) tj. vsemozne zapouzdrovani, zavislosti mezi moduly (dedicnost), mi prijde jako prekomplikovane imperativni a funkcionalni programovani v jednom. Napr. Trida neni nic jineho nez mnozina nekolika funkci.

Jádro našeho "sporu" je možná právě v tom, že ty počítáš každý konstrukt, který nemusíš napsat a já naopak počítám každý konstrukt, který napsat můžu. Samozřejmě že si můžu pamatovat, že tyhle 3 funkce jsou na sobě závislé a že má smysl volat jen tu jednu, protože ty zbylé dvě té první jen pomáhají a pro nic jiného nejsou použitelné. Nebo to můžu napsat do komentáře. Nebo můžu použít prefixy v názvu. Nebo to můžu zavřít do třídy a pomocí public označit tu metodu, kterou má smysl volat. A pak k tomu může přijít i Ind, který neumí slovo anglicky a na první pokus se trefí. No a nebo můžu hrdě tvrdit, že žádnýho pologramotnýho Inda do svého masterpiece kódu nepustím a hledat na pracovním trhu jenom samé guru s 200k platem.

Popravde se v tom ztracim. Ani se nedivim, kdyz existuje tolik ruznych konceptu, ktery jsou vlastne jedna stejna vec.

Tridy = moduly. Inda nepustim do svyho kodu tak, ze mu hodim nektery funkce private v modulu kam nema sahat. Nepotrebuju k tomu N konceptu, kazdej pripominajici modul a umoznujici skryvani atributu.

[Dor]

Nejak nechapu tu neustalou potrebu v OO neco schovavat. Resit co bude schovane a co verejne. Ja radsi resim zadani problemu.

Tridy = moduly. Inda nepustim do svyho kodu tak, ze mu hodim nektery funkce private v modulu kam nema sahat. Nepotrebuju k tomu N konceptu, kazdej pripominajici modul a umoznujici skryvani atributu.

Takže ta potřeba "schovávat" asi není zase tak nepochopitelná.

Jinak asi nikdo nepotřebuje N konceptů. Každému stačí ten jeden, který zrovna on používá.

Jestli skrývat kromě metod i atributy nebo nechávat atributy veřejné, do toho už se pouštět nechci. To strašně záleží na případu použití i na tom, jak to má jaký jazyk zrovna řešeno a návrh to imho nijak zvlášť neovlivňuje. Ale já to mám rád, když můžu některé atributy označit jako private, kvůli lepší čitelnosti kódu. Samozřejmě když má třída/modul desítky privátních atributů, tak v tom návrhu nejspíše něco smrdí.

[gll]

To s tím Javascriptem je docela dobrá paralela. Protože díky tomu, že Javascript neměl žádný zvláštní cukr na vytváření objektů, vzniklo pár zajímavejch článků na toto téma. Díky tomu (a taky proto, že jsem si to zkusil :-) ) je mi jasné, že v tom Pythonu je objekt opravdu jen převlečený slovník.

slovník je defaultní reprezentace, ale existují  __slots__, namedtuple, recordclasses, atd. Kde můžu používám knihovnu attrs, se slots=True.

S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".

to v Pythonu nejde. To si asi pleteš s Javascriptem.

[Kit]

Stejně nechápu, proč většina jazyků má v návrhu slovo "private". Privátní by mělo být defaultně všechno. Jen ty komponenty, které chci mít veřejné, označím "public" nebo "protected".

Mezi object a dict bývá jeden významný rozdíl: Object se předává odkazem, ale dict hodnotou. Platí to například v PHP.

[Kadet]

Nejak nechapu tu neustalou potrebu v OO neco schovavat. Resit co bude schovane a co verejne. Ja radsi resim zadani problemu.

Tridy = moduly. Inda nepustim do svyho kodu tak, ze mu hodim nektery funkce private v modulu kam nema sahat. Nepotrebuju k tomu N konceptu, kazdej pripominajici modul a umoznujici skryvani atributu.

Takže ta potřeba "schovávat" asi není zase tak nepochopitelná.

Jinak asi nikdo nepotřebuje N konceptů. Každému stačí ten jeden, který zrovna on používá.

Jestli skrývat kromě metod i atributy nebo nechávat atributy veřejné, do toho už se pouštět nechci. To strašně záleží na případu použití i na tom, jak to má jaký jazyk zrovna řešeno a návrh to imho nijak zvlášť neovlivňuje. Ale já to mám rád, když můžu některé atributy označit jako private, kvůli lepší čitelnosti kódu. Samozřejmě když má třída/modul desítky privátních atributů, tak v tom návrhu nejspíše něco smrdí.

Ja chapu potrebu schovavat. Akorat debaty o OO navrhu zacinaji tim, co schovat, zapouzdrit a zdedit, nez tim, co je vysledkem vyreseni problemu.

Kdyz jsi sam, kdo pouziva program, tak je fajn, ze si muzes vybrat tridu nebo modul nebo package nebo cokoliv k tomu ucelu. Jenze kdyz pracujes s indem, tak on si vybere jedno a ty druhy. Ja bych na to mel radsi jen jeden koncept.

V Selfu zjistili, ze je lepsi povazovat atribut stejne jako metodu. Jinak jestli se nekdo rozhoduje, jestli schovat nebo ne podle toho, co mu umoznuje jazyk, pak je otazka, jestli nema prilis svazujici jazyk.

[Kadet]

Stejně nechápu, proč většina jazyků má v návrhu slovo "private". Privátní by mělo být defaultně všechno. Jen ty komponenty, které chci mít veřejné, označím "public" nebo "protected".

Mezi object a dict bývá jeden významný rozdíl: Object se předává odkazem, ale dict hodnotou. Platí to například v PHP.

Jestli nechat defaultne private nebo public je otazka jestli pracuju v prototypovacim nebo produkcnim modu.

Je vlastnosti 'zpusob predani' nejaka vnitrni vlastnost objektu nebo dictu? Jinymi slovy, dict nelze predat jako odkaz a objekt nelze predat hodnotou?

[Kit]

Stejně nechápu, proč většina jazyků má v návrhu slovo "private". Privátní by mělo být defaultně všechno. Jen ty komponenty, které chci mít veřejné, označím "public" nebo "protected".

Mezi object a dict bývá jeden významný rozdíl: Object se předává odkazem, ale dict hodnotou. Platí to například v PHP.

Jestli nechat defaultne private nebo public je otazka jestli pracuju v prototypovacim nebo produkcnim modu.

Je vlastnosti 'zpusob predani' nejaka vnitrni vlastnost objektu nebo dictu? Jinymi slovy, dict nelze predat jako odkaz a objekt nelze predat hodnotou?

Public by nechyběl ani v prototypovém módu. Není mnoho komponent, které potřebuji sdílet - obvykle to jsou jen 2-3 metody.

Dict se v PHP dá předat odkazem, ale nedoporučuje se to. Podobně i object se dá naklonovat a tedy předat hodnotou. Jenže obvykle použiji právě takový typ, se kterým mohu pracovat nativně.

[BoneFlute]

S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".

to v Pythonu nejde. To si asi pleteš s Javascriptem.

Ty jo, zaváhal jsem, ale:

Kód: [Vybrat]


class A:
pass

class B (A):
def boo(self):
return 'B'

def goo(self):
return 'C'

b = B()
print(dir(b))
A.goo = goo
print(dir(b))
print b.goo
print b.goo()

[operator]

To s tím Javascriptem je docela dobrá paralela. Protože díky tomu, že Javascript neměl žádný zvláštní cukr na vytváření objektů, vzniklo pár zajímavejch článků na toto téma. Díky tomu (a taky proto, že jsem si to zkusil :-) ) je mi jasné, že v tom Pythonu je objekt opravdu jen převlečený slovník.

slovník je defaultní reprezentace, ale existují  __slots__, namedtuple, recordclasses, atd. Kde můžu používám knihovnu attrs, se slots=True.

S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".

to v Pythonu nejde. To si asi pleteš s Javascriptem.

Proc by to nemelo jit, objekty lze dynamicky modifikovat. Jde nejen pridat, ale i z(a)menit. Podívej se také na bound a unbound methods.