Zdroje k rozvoji OOP myšlení

[Kit]

A kam dáš dočasné detaily? Přece bys nepoužíval ohavné komentáře, které vše zničí

Do proměnných.

[Reklama]

[lispman]

A kam dáš dočasné detaily? Přece bys nepoužíval ohavné komentáře, které vše zničí

Do závorek.

[Ondrej Nemecek]

Podle mě v praxi prostě vázne právě ta formální stránka kódu. Bez ručního přečtení kódu se nemůže člověk spolehnout skoro na nic. Není jasné, zda mají metody vedlejší efekty, není jasná kardinalita vztahů, není jasné, co se kde validuje, není jasné které entity jsou attached vzhledem k databázi, není jasné, kam všude se může dostat null hodnota, není jasné co je bezpečné pro běh ve více vláknech atd. atd. atd.

Samozřejmě různé návrhové vzory, rozhraní, anotace atd. se tohle všechno snaží nějak řešit, ale přijde mi to pořád takové nespolehlivé. Jako ideál bych si představil to, že si pro aplikaci postavím takový typový systém, který si pak už sám ohlídá, že se správné věci dějí na správných místech. Asi jako když si stavím strukturu relační databáze.

Nejspíš se tohle příliš nerozšířilo hlavně kvůli tomu, že to vyžaduje víc matematiky a víc abstrakce, než kolik je mezi programátory běžně k dispozici. Proto to zůstává spíš na akademické půdě a praxi se pořád „tak nějak prasí“.

Ale rád se poučím, pokud se to někde dělá jinak. Docela rád bych i viděl to „pravé OOP“. POřád mi není úplně jasné, co se tím míní a v čem se to liší od současného stavu.

[lispman]

http://lucacardelli.name/TheoryOfObjects.html

[Kit]

http://lucacardelli.name/TheoryOfObjects.html

Vždyť je tam jen obsah a rejstřík. Navíc je to podle obsahu spíš zaměřeno na C#, který mě vůbec nezajímá. Tady se snažíme dopátrat "toho pravého OOP".

[Reklama]

[javaman ()]

http://lucacardelli.name/TheoryOfObjects.html

Vždyť je tam jen obsah a rejstřík. Navíc je to podle obsahu spíš zaměřeno na C#, který mě vůbec nezajímá. Tady se snažíme dopátrat "toho pravého OOP".

Pravé OOP je dynamický shit, který se nepoužívá, protože je to shit. Používá se luxusní Java OOP, které se hodí na většinu běžných věcí. Nechápu, co za architekturu by člověk musel vymyslet, aby to s Javou nezvládl a hodilo se mu něco jiného.

[lispman]

http://lucacardelli.name/TheoryOfObjects.html

Vždyť je tam jen obsah a rejstřík. Navíc je to podle obsahu spíš zaměřeno na C#, který mě vůbec nezajímá. Tady se snažíme dopátrat "toho pravého OOP".

Pravé OOP je dynamický shit, který se nepoužívá, protože je to shit. Používá se luxusní Java OOP, které se hodí na většinu běžných věcí. Nechápu, co za architekturu by člověk musel vymyslet, aby to s Javou nezvládl a hodilo se mu něco jiného.

Vy dva tu reprezentujete nějaký syndikát idiotů?

[javaman ()]

O tom nic nevím.

[BoneFlute]

zdokumentované side-efekty mohou vést květší přehlednosti.

Nevěřím.
Uznávám, že side-efekty někdy být musí. Ale měli by tě k tomu donutit technické omezení.

Někdy by-design rezignuju u akumulátoru (logger apod.). Hlavně proto, že pracuju s lidma, kteří mají zatím jen imperativní a OOP výchovu a s kódem z takového myšlení vzniknuvším.

side efekty mohou být alternativou k vnořování funkcí. V perlu mohu napsat:

Kód: [Vybrat]

while(<>) {
    chomp;
    tr/ /_/;
    s/.*\.txt$/$&.old\n/;
    print if $&;
}

takový kód se mnohem snadněji debuguje než několik vnořených funkcí a současně nemusím vymýšlet názvy proměnných pro mezivýsledky. IMHO je to lepší než různá threading makra v lispech.

Takovej kód je v pořádku do okamžiku, dokavad je navrchu. Jakmile z něj uděláš funkci jsi v místě kam slunce nesvítí.
Zdůrazním: problém není vnořování funkcí ani vymýšlení názvů. Problém je side-efekt jako takovej. Prostě ten kód ti šáhne na výstup.

Bohužel ostatní nemohu komentovat, Perlem jsem nepolíben.

[jpu]

co je Java OOP? .

[gll]

zdokumentované side-efekty mohou vést květší přehlednosti.

Nevěřím.
Uznávám, že side-efekty někdy být musí. Ale měli by tě k tomu donutit technické omezení.

Někdy by-design rezignuju u akumulátoru (logger apod.). Hlavně proto, že pracuju s lidma, kteří mají zatím jen imperativní a OOP výchovu a s kódem z takového myšlení vzniknuvším.

side efekty mohou být alternativou k vnořování funkcí. V perlu mohu napsat:

Kód: [Vybrat]

while(<>) {
    chomp;
    tr/ /_/;
    s/.*\.txt$/$&.old\n/;
    print if $&;
}

takový kód se mnohem snadněji debuguje než několik vnořených funkcí a současně nemusím vymýšlet názvy proměnných pro mezivýsledky. IMHO je to lepší než různá threading makra v lispech.

Takovej kód je v pořádku do okamžiku, dokavad je navrchu. Jakmile z něj uděláš funkci jsi v místě kam slunce nesvítí.
Zdůrazním: problém není vnořování funkcí ani vymýšlení názvů. Problém je side-efekt jako takovej. Prostě ten kód ti šáhne na výstup.

Bohužel ostatní nemohu komentovat, Perlem jsem nepolíben.

$_ ve while je lokální, dynamicky scopované. Jinak mohu napsat local $_; na začátku funkce.

[BoneFlute]

zdokumentované side-efekty mohou vést květší přehlednosti.

Nevěřím.
Uznávám, že side-efekty někdy být musí. Ale měli by tě k tomu donutit technické omezení.

Někdy by-design rezignuju u akumulátoru (logger apod.). Hlavně proto, že pracuju s lidma, kteří mají zatím jen imperativní a OOP výchovu a s kódem z takového myšlení vzniknuvším.

side efekty mohou být alternativou k vnořování funkcí. V perlu mohu napsat:

Kód: [Vybrat]

while(<>) {
    chomp;
    tr/ /_/;
    s/.*\.txt$/$&.old\n/;
    print if $&;
}

takový kód se mnohem snadněji debuguje než několik vnořených funkcí a současně nemusím vymýšlet názvy proměnných pro mezivýsledky. IMHO je to lepší než různá threading makra v lispech.

Takovej kód je v pořádku do okamžiku, dokavad je navrchu. Jakmile z něj uděláš funkci jsi v místě kam slunce nesvítí.
Zdůrazním: problém není vnořování funkcí ani vymýšlení názvů. Problém je side-efekt jako takovej. Prostě ten kód ti šáhne na výstup.

Bohužel ostatní nemohu komentovat, Perlem jsem nepolíben.

$_ ve while je lokální, dynamicky scopované. Jinak mohu napsat local $_; na začátku funkce.

No a?

[gll]

No a?

tím side-efektem jsi myslel změnu $_, nebo print? Print je tam nepodstatný, šlo ukázku použití $_ k ukládání mezivýsledků.

[Polymath]

Podle mě v praxi prostě vázne právě ta formální stránka kódu. Bez ručního přečtení kódu se nemůže člověk spolehnout skoro na nic. Není jasné, zda mají metody vedlejší efekty, není jasná kardinalita vztahů, není jasné, co se kde validuje, není jasné které entity jsou attached vzhledem k databázi, není jasné, kam všude se může dostat null hodnota, není jasné co je bezpečné pro běh ve více vláknech atd. atd. atd.

Samozřejmě různé návrhové vzory, rozhraní, anotace atd. se tohle všechno snaží nějak řešit, ale přijde mi to pořád takové nespolehlivé. Jako ideál bych si představil to, že si pro aplikaci postavím takový typový systém, který si pak už sám ohlídá, že se správné věci dějí na správných místech. Asi jako když si stavím strukturu relační databáze.

Nejspíš se tohle příliš nerozšířilo hlavně kvůli tomu, že to vyžaduje víc matematiky a víc abstrakce, než kolik je mezi programátory běžně k dispozici. Proto to zůstává spíš na akademické půdě a praxi se pořád „tak nějak prasí“.

Ale rád se poučím, pokud se to někde dělá jinak. Docela rád bych i viděl to „pravé OOP“. POřád mi není úplně jasné, co se tím míní a v čem se to liší od současného stavu.

OOP je široký pojem neimplikující dědičnost ani konkrétní způsob typování. Někteří fanatici považují za pravé OOP jen Smalltalk nebo ObjC - prostě jazyk s dynamickým typováním. Nicméně cokoliv s polymorfismem umožňuje mít objekty a virtuální dispatch. Dynamický dispatch je super na určité věci jako distribuované objekty, ale to se už stejně nepoužívá (kdo dnes tvoří COM a NEO?), takže nemá smysl to řešit. Mnohem důležitější je efektivita a výkon, což je k výše uvedenému ortogonální.

[Kit]

http://lucacardelli.name/TheoryOfObjects.html

Vždyť je tam jen obsah a rejstřík. Navíc je to podle obsahu spíš zaměřeno na C#, který mě vůbec nezajímá. Tady se snažíme dopátrat "toho pravého OOP".

Pravé OOP je dynamický shit, který se nepoužívá, protože je to shit. Používá se luxusní Java OOP, které se hodí na většinu běžných věcí. Nechápu, co za architekturu by člověk musel vymyslet, aby to s Javou nezvládl a hodilo se mu něco jiného.

Vy dva tu reprezentujete nějaký syndikát idiotů?

Jestli si myslíš, že si po přečtení toho nevalného obsahu půjdu tu mizernou knihu koupit, tak jsi na omylu. To si raději znovu přečtu knihu od Bruce Eckela: Thinking in Java, která je skvělá hlavně díky kvalitnímu OOP.