Kniha Objektové programování od Čady

[zboj]

Jestli máš na mysli tu slavnou debatu o objektové hierarchii čísel (tam to klasicky dospělo, samotného by mě zajímalo, jak to dnes učí), tak tam bylo dost vidět, jak má Virius dost omezený pohled tím, jak je OOP implementováno v C++. On je na C++ hodně dobrej, ale chyběl mu rozhled.

Souhlasím. Mimochodem, když si někde obstaráte postupně starší skripta od Viriuse, tak zjistíte, že ještě tak v polovině 90. let v tom OOP velmi solidně plaval.

A ty debaty o hierarchii vejce-slepice nebo u čísel jsou docela úsměvné. Problém OOP je, že v životě se dají tytéž věci klasifikovat různě, záleží na úhlu pohledu a na tom, k čemu to má celé sloužit. Auta můžu hierarchizovat podle barvy, podle velikosti, podle účelu, podle počtu náprav, podle počtu míst, podle užitného nákladu, podle výrobce, podle druhu pohonu... Žádná z nich není ta jediná správná, každá se hodí k něčemu jinému. Ale při návrhu objektového modelu je třeba zvolit takovou, která usnadní implementaci. A která nemusí mít s reálným životem dokonce nic společného - ale za to může odrážet nějaké implementační souvislosti, jako třeba reprezentaci v paměti apod. A to je ten kámen úrazu, protože to je ve skutečnosti poměrně náročný úkol, který když uděláte špatně, tak už se to potáhne navždy celým projektem a nejde s tím nic udělat. U jiných paradigmat, např. strukturovaného, je samozřejmě také nezbytné navrhnout datový model a strukturu procedur, ale řekl bych, že tam to není tak fatální jako u OOP.

On to je trochu problém čistě technický, a sice (jednoduché) dědičnosti. Lepší je asi používat protokoly, pak jde totiž mít ty různé "hierarchizace" v kódu současně. Haskell, Swift nebo třeba Go jdou v tomto ohledu s dobou a vlastně se ukazuje, že dědičnost à la C++ až tak potřebná není. Celé by to mělo směřovat ke "complexion reduction". Kdy se to prosadí u většiny zkušených vývojářů, to už je věc jiná. Přinejmenším je ale přínosné kouknout se na tuto alternativu a zvážit, jak lze psát efektivněji. Pravděpodobně to bude pozvolný plynulý přechod.

[Reklama]

[Kit]

A ty debaty o hierarchii vejce-slepice nebo u čísel jsou docela úsměvné. Problém OOP je, že v životě se dají tytéž věci klasifikovat různě, záleží na úhlu pohledu a na tom, k čemu to má celé sloužit. Auta můžu hierarchizovat podle barvy, podle velikosti, podle účelu, podle počtu náprav, podle počtu míst, podle užitného nákladu, podle výrobce, podle druhu pohonu... Žádná z nich není ta jediná správná, každá se hodí k něčemu jinému. Ale při návrhu objektového modelu je třeba zvolit takovou, která usnadní implementaci. A která nemusí mít s reálným životem dokonce nic společného - ale za to může odrážet nějaké implementační souvislosti, jako třeba reprezentaci v paměti apod. A to je ten kámen úrazu, protože to je ve skutečnosti poměrně náročný úkol, který když uděláte špatně, tak už se to potáhne navždy celým projektem a nejde s tím nic udělat. U jiných paradigmat, např. strukturovaného, je samozřejmě také nezbytné navrhnout datový model a strukturu procedur, ale řekl bych, že tam to není tak fatální jako u OOP.

Super shrnutí. Proto mnozí na dědičnost rezignovali a všechno se snaží lepit kompozicí, což také není správně. Rozdělení tříd na třídy s metodami a třídy s atributy je pak už úplné zvěrstvo.

[SB]

Nevim, jestli spamovat vlakno o necem uplne jinem, ale kdyz uz jste s tim zacali... A koneckoncu je to mistni kolorit, tak snad v poho 

Pochopení FP do hloubky vyžaduje detailní znalost teorie kategorií. [...] Ovšem ne každý to potřebuje, takže se není o čem hádat.

To tvrzeni mi prijde vylozene zhoubne. Protoze uplne zbytecne od FP odrazuje lidi, kteri ho ani nezkusili, popr. ty, kdo ho zkusili a po prvnim zamotani se rychle skoncili, utvrdi v tom, ze udelali dobre. A pritom je dost zavadejici, kdyz uz nechci rict vylozene nepravdive...

,,...i skladník ve šroubárně si může přečísti Vergilia v originále..."

[Mirek Prýmek]

,,...i skladník ve šroubárně si může přečísti Vergilia v originále..."

Ale nikdo nebude tvrdit, že pochopení šroubárny do hloubky vyžaduje jeho znalost

[SB]

Zedník umí stavět zdi, ale pouze ve známém prostředí. Nespočítá si už například vliv náhrady materiálu izolace na tepelné ztráty zdi.

Zedník nemá nic počítat. Zedník má postavit zeď tak, jak je to v projektu. A s běžným programátorem je to dost často stejně - přílišná invence, která není na místě, k ničemu dobrému nevede. Imho není ani tak důležité znát všechno, důležitější je znát svoje limity a nepouštět se do věcí, na který nemám.

Programování bývalo spíše uměním, dnes je inženýrskou činností, ještě dlouho to nebude jen stavění zdi. Je to řemeslo, ne výroba. A každé řemeslo má v sobě tvůrčí složku, nikdy to není jen prostá reprodukce.

Dokud nebude softwareové inženýrství dostatečně formalizované jako např. stavebnictví (a to nyní v žádném případě není), programátor-dělník nebude dostačovat. Toto je zároveň odpovědí na srovnání zedníka s vývojářem.

[Reklama]

[SB]

Souhlasim s tebou, otazka ovsem je, jak pak vubec nekomu doporucit/ohodnotit nejakou knihu o OOP, kdyz plati ty dve tvrzeni.

Reagoval jsem především na to, že už tu někdo startoval, že bude doporučovat funkcionální programování jako náhradu OOP.

[gll]

Diskuzi o objektovém myšlení celkově moc nechápu. Mě stačí vědět, že fun(obj) je to stejné co obj.fun().

Není to stejné. Funkce fun(obj) se ve většině jazyků přetížit ani překrýt nedá.

To už se řeší v každém jazyku jinak a je hloupost o tom obecně teoretizovat.

[SB]

V každém jazyce se používají jiná paradigmata a jiné best practices. Zobecňovat to podle mě moc nejde. Správné je se přizpůsobit konvencím jazyka. Ne naopak. Učit se zobecnění bez znalosti jednotlivých případů, které zobecňuje, je k ničemu.

Bavíme se o pochopení jednoho paradigmatu, ne o směsi v nějakém jazyku! Začnete-li vysvětlováním na jazyku, vysvětlil jste implementaci, ne myšlenku. Jazyk není specializací myšlenky, jazyk je její implementací!!!

Diskuzi o objektovém myšlení celkově moc nechápu. Mě stačí vědět, že fun(obj) je to stejné co obj.fun().

Tak jestli je to pro vás to samé, tak co tu ještě řešíme?

[SB]

Co mají šablony a generické programování společné s OOP?

Budu hádat: C++

Pro některé i tak.

[gll]

V každém jazyce se používají jiná paradigmata a jiné best practices. Zobecňovat to podle mě moc nejde. Správné je se přizpůsobit konvencím jazyka. Ne naopak. Učit se zobecnění bez znalosti jednotlivých případů, které zobecňuje, je k ničemu.

Bavíme se o pochopení jednoho paradigmatu, ne o směsi v nějakém jazyku! Začnete-li vysvětlováním na jazyku, vysvětlil jste implementaci, ne myšlenku. Jazyk není specializací myšlenky, jazyk je její implementací!!!

Od používání různých pseudokódů v literatuře a ve výuce se postupně ustupuje. Lepší je vysvětlovat na konkrétním přesně specifikovaném jazyku. Neformální okecávání do technických oborů nepatří.

[SB]

...který když uděláte špatně, tak už se to potáhne navždy celým projektem a nejde s tím nic udělat. U jiných paradigmat, např. strukturovaného, je samozřejmě také nezbytné navrhnout datový model a strukturu procedur, ale řekl bych, že tam to není tak fatální jako u OOP.

Řekl byste, nebo víte?
Jednou z klíčových myšlenek OOP je rozdělení domény na malé části nezávislé tak moc, jak to jen jde. Jejich refaktorizace je potom téměř či úplně nezávislá. K tomu má přispět i zapouzdření, nad kterým zde kdekdo mávne rukou. Dědičnost je nepovinná, i tak refaktorizovatelná. Není mi jasné, v čem spočívá ta horší pozice oproti strukturovanému programování.

[SB]

,,...i skladník ve šroubárně si může přečísti Vergilia v originále..."

Ale nikdo nebude tvrdit, že pochopení šroubárny do hloubky vyžaduje jeho znalost

Samozřejmě že ne, právě pro onu rozporuplnost jsem tuto neskutečnou větu uvedl.

[SB]

Není to stejné. Funkce fun(obj) se ve většině jazyků přetížit ani překrýt nedá.

To už se řeší v každém jazyku jinak a je hloupost o tom obecně teoretizovat.

To se vůbec neřeší, jsou to 2 rozdílné mechanismy, které fungují zcela jinak a nemají nic polečného!

[Ondra Satai Nekola]

Od používání různých pseudokódů v literatuře a ve výuce se postupně ustupuje. Lepší je vysvětlovat na konkrétním přesně specifikovaném jazyku. Neformální okecávání do technických oborů nepatří.

A inzenyri maji zakazano delat nacrtky a museji vsechno presne narysovat?

To uz je dneska podruhe: ruzne urovne abstrakce (a presnosti) pro ruzne situace. Nekdy potrebujes mit moznost psat realny kod (treba kdyz je ucis test-driven), jindy ti staci nacrtnout (treba kdyz ukazujes variace nejakeho algoritmu).

[Ivan Nový]

,,...i skladník ve šroubárně si může přečísti Vergilia v originále..."

Ale nikdo nebude tvrdit, že pochopení šroubárny do hloubky vyžaduje jeho znalost

Právě, že vyžaduje. Lidé co nečetli Vergilia, či něco podobného, většinou nechápou svět kolem sebe i když si myslí, že ho chápou. A pak ho taky stěží mohou modelovat. Naopak, čtenář Vergilia nemusí pracovat ve šroubárně, aby ji pochopil a mohl ji modelovat.

Jinak i ve stavebnictví, v oboru s tisíciletou tradicí, se od nepaměti vede boj mezi stavebními konstruktéry, architekty na jedné straně a políry a zedníky na druhé straně. Jedni o druhých si myslí, že to jsou blbci a jejich výtvory stojí za zlámanou grešli :-)))