Zdroje k rozvoji OOP myšlení

[Kit]

Lepší je se učit OOP používáním dobrých knihoven, než čtením hloupých příkladů.

Ani dobré knihovny nám toho o OOP mnoho neřeknou. Dobré příklady jsou lepší.

[Reklama]

[balki]

Myslíme v C++ je hodně špatná kniha. Zejména první díl jsou jen obecné řeči a hloupé příklady.

Neřešíme C++, ale OOP.

Lepší je se učit OOP používáním dobrých knihoven, než čtením hloupých příkladů.

Nie je to dobre tak riesit, lebo v knizniciach byva pomiesanej vela roznej  nesuvisiacej funkcionality a clovek potom nevidi potom priklady v ich cistej forme. V knihach to byva explicitne pomenovane, cistejsie a nemusi byt v prikladoch nagrcane, z dovodu, aby to chodilo. V libkach tiez nezvyknu rozoberat vhodne a nevhodne sposoby pouzitia, tam to proste nakodia. (bud dobre, alebo zle)


Inac, eckel sa mi tiez tazsie cital, lebo je tak trosku grafoman.

[Inkvizitor]

Selský rozum je určitě potřeba, ale když už se mi na x-tém místě opakuje ta stejná podmínka, tak si říkám, že je asi něco špatně...

Proč i myslíš, že to znamená nedostatečně objektové myšlení?

Třeba protože stejné podmínky se v OOP téměř nevyskytují?

Na tom není nic objektového. Každý dostatečně bohatý jazyk kteréhokoli paradigmatu lze používat tak, aby se neduplikoval kód. A každý rozumný člověk píše programy tak, aby pokud možno nedocházelo k duplicitám.

[SB]

"Refactoring: Improving the Design of Existing Code od M.fowlera"   je podla mna tiez sucast povinnej jazdy, co sa tyka oop.

Tak Refaktorování je určitě povedená knížka, ale je spíše o organizaci kódu, dokonce některé úpravy nesouvisejí s OOP.
Ale co jsem používal a doporučil bych, tak Patterns of Enterprise Application Architecture (http://www.martinfowler.com/books/eaa.html) - zde jsou ukázky: http://www.martinfowler.com/eaaCatalog/. Kdo dělá nějakou obchodní aplikaci (a není patlal), hodně z toho použije (když teda nevyužije nějaký pochybný framework).
Každopádně Fowler je opravdový objektář, jeden z nejlepších, o tom žádná.

[SB]

Myslíme v C++ je hodně špatná kniha. Zejména první díl jsou jen obecné řeči a hloupé příklady.

Neřešíme C++, ale OOP.

Nechci tu vyvolávat flamewár, už se to řešilo jinde, ale osobně(!) si myslím, že vysvětlovat OOP na C++ je krajně nevhodné, na to jsou jiné jazyky, takže knihám kombinujícím C++ a OOP bych se osobně(!) zdaleka vyhnul.

[Reklama]

[SB]

Třeba protože stejné podmínky se v OOP téměř nevyskytují?

Na tom není nic objektového. Každý dostatečně bohatý jazyk kteréhokoli paradigmatu lze používat tak, aby se neduplikoval kód. A každý rozumný člověk píše programy tak, aby pokud možno nedocházelo k duplicitám.

Neříkáte to přesně - čím abstraktnější jazyk máte, tím znovupoužitelnější konstrukce můžete psát. Neboli duplicitám můžete zabránit jen na takové úrovni, na které vám to dovolí jazyk. Samo OOP má taky nástroje pro obecné konstrukce, např. dependency injection, dědičnost (ne nutně), delegování, ...

[Kit]

Myslíme v C++ je hodně špatná kniha. Zejména první díl jsou jen obecné řeči a hloupé příklady.

Neřešíme C++, ale OOP.

Nechci tu vyvolávat flamewár, už se to řešilo jinde, ale osobně(!) si myslím, že vysvětlovat OOP na C++ je krajně nevhodné, na to jsou jiné jazyky, takže knihám kombinujícím C++ a OOP bych se osobně(!) zdaleka vyhnul.

Nakoukl jsem do ní a zjistil jsem, že na začátku se ani moc nezabývá C++, jako spíš OOP v obecné rovině. Takže celkově ta kniha může být docela dobrá zejména kvůli: "... první díl jsou jen obecné řeči a hloupé příklady".

Právě ty obecné řeči a "hloupé" příklady jsou při výuce OOP nejdůležitější. Jinak to programátor začne mydlit procedurálně, protože C++ k tomu silně svádí.

[Kit]

Selský rozum je určitě potřeba, ale když už se mi na x-tém místě opakuje ta stejná podmínka, tak si říkám, že je asi něco špatně...

Proč i myslíš, že to znamená nedostatečně objektové myšlení?

Třeba protože stejné podmínky se v OOP téměř nevyskytují?

Na tom není nic objektového. Každý dostatečně bohatý jazyk kteréhokoli paradigmatu lze používat tak, aby se neduplikoval kód. A každý rozumný člověk píše programy tak, aby pokud možno nedocházelo k duplicitám.

Pokud je ta podmínka zapouzdřena v objektu společně s testovaným atributem, tak k duplicitě téměř dojít nemůže.

[Inkvizitor]

Pokud je ta podmínka zapouzdřena v objektu společně s testovaným atributem, tak k duplicitě téměř dojít nemůže.

Podmínka je v metodě a může být v té samé metodě kolikrát chce, může být v jiné metodě dané třídy (pokud má jazyk třídy a metody) a může být i v kterémkoli jiném objektu. Chtělo by to konkrétní příklady, kde OOP pomáhá nebo dokonce příklad, kde by to bez OOP rozumně nešlo.

A taky by mě zajímalo, v kterém konkrétním jazyce autor původního příspěvku ten neobjektový kód vidí. Protože by se mohlo ukázat, že to je třeba C++, které se bez objektů docela dobře obejde a pořád je možné přitom psát DRY kód.

[Inkvizitor]

Třeba protože stejné podmínky se v OOP téměř nevyskytují?

Na tom není nic objektového. Každý dostatečně bohatý jazyk kteréhokoli paradigmatu lze používat tak, aby se neduplikoval kód. A každý rozumný člověk píše programy tak, aby pokud možno nedocházelo k duplicitám.

Neříkáte to přesně - čím abstraktnější jazyk máte, tím znovupoužitelnější konstrukce můžete psát. Neboli duplicitám můžete zabránit jen na takové úrovni, na které vám to dovolí jazyk. Samo OOP má taky nástroje pro obecné konstrukce, např. dependency injection, dědičnost (ne nutně), delegování, ...

Chtělo by to příklad. Už i "blbé" C umožňuje používání callbacků, které toho vládnou pořešit opravdu hodně.

[zmija]

panove a com je rec? vzdyt C++ je jazyk kde sa da s OOP poradne vyhrat. Aspon nas na skole ucili, ze je to OOP jazyk. jste si jisti ze opravdu myslite OOP?

[gamer]

panove a com je rec? vzdyt C++ je jazyk kde sa da s OOP poradne vyhrat. Aspon nas na skole ucili, ze je to OOP jazyk. jste si jisti ze opravdu myslite OOP?

C++ je jedna z konkrétních implementací OOP a má svoje probémy. Namátkou nepodpora nativních interfaces, musí se to dělat přes abstraktní třídu, což vadí třeba když chci objekt implementující dva různé interface, vede to na vícenásobnou dědičnost se všemi negativními důsledky. V C++ je taky velice jednoduché střelit se do nohy, zapomenutý virtuální destructor v bázové třídě může být docela zábavný. Ze stejného důvodu není ani tohle dobrý nápad:

Kód: [Vybrat]

class MyVector : public std::vector
Pokud se OOP učím, nechci takové věci řešit.

[zmija]

ono nic neni dokonale a taky na 100%.

[gamer]

ono nic neni dokonale a taky na 100%.

Dokonalé není nic, ale na učení není dobrý jazyk, ve kterém nesmím dědit ze std::vector (a obecně žádné třídy, která nemá virtuální destructor), protože mi to může nedefinovaně rozbít aplikaci...

[zmija]

co tedy radis?