Zdroje k rozvoji OOP myšlení

[SB]

Seznam a proud jsou 2 zcela odlišné abstrakce, to, že zahrnují podobnou funkcionalitu, není důvodem, abych jeden z oněch konceptů řešil tím druhým.

[Reklama]

[Ondra Satai Nekola]

Seznam a proud jsou 2 zcela odlišné abstrakce, to, že zahrnují podobnou funkcionalitu, není důvodem, abych jeden z oněch konceptů řešil tím druhým.

Whatever. V realu tohle vazne je ten posledni problem, co te pri psani v Jave trapi, protoze jedno z druheho umis na jedno code completion...

[BoneFlute]

Opravovat zobjektizovaný kód je dost na prd.
Opravovat funkcionální kód mi přišlo mnohem snazší. Přijde mi, že v tom nemůžeš udělat takové špagety jako v OOP. Aktivněji ti v tom brání.

No... ne že by v tom přímo bránil, ale v OOP je víc špagetovacích možností... třeba právě dědičnost. Už jsem viděl objekt, který se jmenoval nějak mainobject, jedinou vlastností bylo nějaký ID a všechny ostatní objekty byly jeho potomkem. V podobném duchu se to neslo dál, takže než se člověk prokousal přes x úrovní, aby zjistil, proč se to se.. kazí, tak měl skoro fousatý děti.

Ano, to je takříkajíc ze života.

Zatímco zvrtej použití funkce. Teď z fleku mě napadají jen tyto způsoby:
- vracení hodnoty argumentem
- side-efekt
- vracení funkce (ne že by to bylo špatně, ale je to takovej kandidát na znečitelnění)
- ob rekurze (funkce `a` volá `b` a ta volá `a`)

[gll]

Ano, to je takříkajíc ze života.

Zatímco zvrtej použití funkce. Teď z fleku mě napadají jen tyto způsoby:
- vracení hodnoty argumentem
- side-efekt
- vracení funkce (ne že by to bylo špatně, ale je to takovej kandidát na znečitelnění)
- ob rekurze (funkce `a` volá `b` a ta volá `a`)

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

[Ondra Satai Nekola]

Ano, to je takříkajíc ze života.

Zatímco zvrtej použití funkce. Teď z fleku mě napadají jen tyto způsoby:
- vracení hodnoty argumentem
- side-efekt
- vracení funkce (ne že by to bylo špatně, ale je to takovej kandidát na znečitelnění)
- ob rekurze (funkce `a` volá `b` a ta volá `a`)

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

Az do okamziku, kdy se rozjdede dokumentace a kod. Takze zhruba po dobu jednoho tydne realneho vyvoje.

[Reklama]

[Kit]

Zrovna koukám na aplikaci napsanou v shellu "lineárně". Aby to nebylo v jednom souboru, je tam hromada "source", tedy includů jiných souborů. V objektech to určitě bude vypadat mnohem lépe, ale v podstatě tu aplikaci budu muset navrhnout znovu a pořádně. O nějakém "zobjektování" nemůže být řeč. V případě ponechání shellu by se jednalo spíš o "zfunkcionálnění".

No a jsme u toho. OOP vyžaduje rozumný návrh a pokud se očekává, že aplikace poroste a budou jí přibývat nové funkcionality, musí se na to včas myslet. Tím nechci říct, že u procedurálního programování se špatný návrh ztratí, ale u OOP mně to přijde kritičtější. Ono takový dohledávání dědičností, dědiců, vyděděnců, nevlastních dětí a retardovaných bratranců, to je masakr.

V žádném případně se však nesmí optimalizovat předčasně. Pokud se udělá dědičnost správně, nebývá s tím problém - stačí dodržet LSP. Mnohem větší hrůzu mívám z dlouhatánských tříd s hromadou veřejných metod a protected atributů.

Jakmile má třída > 4 atributy, je okamžitě kandidátem na refaktorování.

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

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

[Kit]

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.

Líný vývojář, který není schopen vymyslet název proměnné pro mezivýsledky, je největší pohromou pro ostatní vývojáře v týmu. Významně totiž zvyšuje počet WTF za hodinu.

[gll]

Líný vývojář, který není schopen vymyslet název proměnné pro mezivýsledky, je největší pohromou pro ostatní vývojáře v týmu. Významně totiž zvyšuje počet WTF za hodinu.

Jde o eliminaci code noise. Naopak to snižuje počet WTF, protože je vynucováno použítí standartizovaných názvů.

[Ondra Satai Nekola]

Pokud mne mel ten kus kodu presvedcit o skvelosti sideefektu, tak se mu to nepodarilo...

[Kit]

Líný vývojář, který není schopen vymyslet název proměnné pro mezivýsledky, je největší pohromou pro ostatní vývojáře v týmu. Významně totiž zvyšuje počet WTF za hodinu.

Jde o eliminaci code noise. Naopak to snižuje počet WTF, protože je vynucováno použítí standartizovaných názvů.

Za code noise považuji hlavně komentáře, které překladač/interpretr ignoruje. Za nejlepší komentáře považuji správnou volbu názvů. Dodávají kódu sémantiku.

[javaman ()]

getValueButLastCompilerVersionHasBugSoWeNeedAddTwoToResult()

[Kit]

getValueButLastCompilerVersionHasBugSoWeNeedAddTwoToResult()

To má být vtip? Obvykle si vystačím s jedním či maximálně dvěma slovy.

[javaman ()]

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