Dědičnost dnes

[JS]

Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad. A s tim bych souhlasil, vede to k problemum. Chces poprit, ze to vede k problemum? Klasicky priklad je trida matice a vektor, ktery se treba v C++ resi pres spratelene tridy.

Popravdě, aniž bych si to zkusil napsat mě teď od židle nenapadá, v čem že je u matic a vektorů problém. Mohl bys naznačit?

Predne, abych se trochu opravil - jadro Armstrongova argumentu je ze skryvani dat uvnitr objektu vede k problemum.

Mame operaci nasobeni matice a vektoru - patri do tridy matice, nebo do tridy vektor? A pokud si jednu vybereme, jak se dostaneme k prvkum te druhe? (Samozrejme, muzeme modelovat oboji jako matici, ale pak jsme se ponekud vyhnuli tomu skryvani.)

Jiny priklad. Mame tridu matice, a ta ma nejake metody. Potrebuji spocitat permanent, ale na to tam metoda neni. Jak to implementovat, aniz bych nemel pristup k vnitrnostem te tridy matice?

(Jeste bych tady mohl vlozit otazku, jak implementovat ctvercovou matici, ale to uz se tady probiralo...)

Nebo obecne, vezmi si jakykoli algoritmus. Je existence toho algoritmu vlastnosti objektu, s kterymi pracuje? Je treba moznost vypoctu maximalniho toku vlastnosti elektricke site? Zda se mi, ze ne. Jenze ten algoritmus typicky o tech objektech neco predpoklada a potrebuje k nim pristupovat. Takze pro implementaci toho algoritmu neni lhostejne, jaka je vnitrni struktura tech objektu.

Jsou situace, kde OOP funguje pomerne dobre - treba GUI. Protoze na to v naivni implementaci zadny algoritmus nepotrebujes. Tam pokud spolu veci nejak musi interagovat, tak maji spolecneho predka (treba Widget). OOP je proste postavene na nejake analogii s realnym svetem, ktery tak nejak prirozene delime do objektu, a prisuzujeme jim duvod, proc neco delaji. Ale to je do jiste miry dost nepresny popis reality a na mnoho problemu selhava.

To se ale týká právě těch jazyků typu C++ či Java, v nichž se pomocí design patterns dohání ta jejich objektová polovičatost.

Ano, zajima me to v Jave, to je kanonicky pripad jazyka, co pouzivaji zastanci OOP. Ale klidne muzes naznacit, jak bys to resil ve Smalltalku; pochybuji, ze pujde o skutecne skryvani dat.

[Reklama]

[gll]

...

OOP v pythonu a podobných jazycích je jen syntaktický cukr, který usnadňuje psaní kódu pomocí autodoplňování. obj.metoda() je to stejné co Trida.metoda(obj). obj může být libovolného typu. Je možné sdílet metody Trida1.metoda = Trida2.metoda. V ničem to neomezuje. Souhlasím, že je přínos OOP zveličován. Ale ta kritika platí jen pro jazyky typu Java.

[Mirek Prýmek]

Souhlasím, že je přínos OOP zveličován. Ale ta kritika platí jen pro jazyky typu Java.

Já myslím, že to kritici vidí trochu jinak: z OOP-jak-ho-dnes-každý-chápe je děláno zlaté tele, je přeceňován význam konkrétních konceptů, které zas tak zásadní nejsou (typicky ta dědičnost) na úkor jiných důležitých konceptů (třeba toho skládání nebo posílání zpráv), a takhle zmršené OOP se vydává za "to OOP" (čti zlaté tele).

Pokud by se místo C++ a Javy masově programovalo v ObjC, myslím, že by s tím nikdo neměl moc problém, protože problémy takového přístupu by byly srovnatelné s problémy jinde (there's no silver bullet). Ale ten standard povědomí o OOP, který nastavilo především C++, je prostě k zblití...

[balki]

Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad. A s tim bych souhlasil, vede to k problemum. Chces poprit, ze to vede k problemum? Klasicky priklad je trida matice a vektor, ktery se treba v C++ resi pres spratelene tridy.

Popravdě, aniž bych si to zkusil napsat mě teď od židle nenapadá, v čem že je u matic a vektorů problém. Mohl bys naznačit?

Predne, abych se trochu opravil - jadro Armstrongova argumentu je ze skryvani dat uvnitr objektu vede k problemum.

Mame operaci nasobeni matice a vektoru - patri do tridy matice, nebo do tridy vektor? A pokud si jednu vybereme, jak se dostaneme k prvkum te druhe? (Samozrejme, muzeme modelovat oboji jako matici, ale pak jsme se ponekud vyhnuli tomu skryvani.)

Jiny priklad. Mame tridu matice, a ta ma nejake metody. Potrebuji spocitat permanent, ale na to tam metoda neni. Jak to implementovat, aniz bych nemel pristup k vnitrnostem te tridy matice?

(Jeste bych tady mohl vlozit otazku, jak implementovat ctvercovou matici, ale to uz se tady probiralo...)

Nebo obecne, vezmi si jakykoli algoritmus. Je existence toho algoritmu vlastnosti objektu, s kterymi pracuje? Je treba moznost vypoctu maximalniho toku vlastnosti elektricke site? Zda se mi, ze ne. Jenze ten algoritmus typicky o tech objektech neco predpoklada a potrebuje k nim pristupovat. Takze pro implementaci toho algoritmu neni lhostejne, jaka je vnitrni struktura tech objektu.

Jsou situace, kde OOP funguje pomerne dobre - treba GUI. Protoze na to v naivni implementaci zadny algoritmus nepotrebujes. Tam pokud spolu veci nejak musi interagovat, tak maji spolecneho predka (treba Widget). OOP je proste postavene na nejake analogii s realnym svetem, ktery tak nejak prirozene delime do objektu, a prisuzujeme jim duvod, proc neco delaji. Ale to je do jiste miry dost nepresny popis reality a na mnoho problemu selhava.

To se ale týká právě těch jazyků typu C++ či Java, v nichž se pomocí design patterns dohání ta jejich objektová polovičatost.

Ano, zajima me to v Jave, to je kanonicky pripad jazyka, co pouzivaji zastanci OOP. Ale klidne muzes naznacit, jak bys to resil ve Smalltalku; pochybuji, ze pujde o skutecne skryvani dat.

To su cisto filozoficke problemy.
1. ci nasobenie vektora a matice ma byt metoda vektora alebo matice, alebo brontosaura, o tom rozhoduje programator. Ak to dokaze logicky odovodnit, potom je to v poriadku.
2. kazdy oop (aj smalltalk) jazyk je  vskutocnosti multiparadigmovy, takze sa nikdy nevyhneme proceduralnym konstrukciam, pripadne funkcionalnym konstrukciam.
3. navrhove vzory boli vytvorene pre OOP jazyky vseobecne, neriesi sa nimi nedokonalost jazykov, ale su to vypozorovane vztahy objektov nezavisle na implementacii, ktore sa pouzivali v praxi. Vo fundamentalnej knihe od gang of four su priklady uvadzane v jazyku smalltalk. To, ze v niektorych modernejsich jazykoch su vzory nahraditelne idiomom znamena, ze uz vytvorili abstrakciu, ktora vzory zahrnuje, nie ze by ich spravili neuzitocnymi.

[Kiwi]

Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad. A s tim bych souhlasil, vede to k problemum. Chces poprit, ze to vede k problemum? Klasicky priklad je trida matice a vektor, ktery se treba v C++ resi pres spratelene tridy.

Popravdě, aniž bych si to zkusil napsat mě teď od židle nenapadá, v čem že je u matic a vektorů problém. Mohl bys naznačit?

Predne, abych se trochu opravil - jadro Armstrongova argumentu je ze skryvani dat uvnitr objektu vede k problemum.

Mame operaci nasobeni matice a vektoru - patri do tridy matice, nebo do tridy vektor? A pokud si jednu vybereme, jak se dostaneme k prvkum te druhe? (Samozrejme, muzeme modelovat oboji jako matici, ale pak jsme se ponekud vyhnuli tomu skryvani.)

Jiny priklad. Mame tridu matice, a ta ma nejake metody. Potrebuji spocitat permanent, ale na to tam metoda neni. Jak to implementovat, aniz bych nemel pristup k vnitrnostem te tridy matice?

(Jeste bych tady mohl vlozit otazku, jak implementovat ctvercovou matici, ale to uz se tady probiralo...)

Nebo obecne, vezmi si jakykoli algoritmus. Je existence toho algoritmu vlastnosti objektu, s kterymi pracuje? Je treba moznost vypoctu maximalniho toku vlastnosti elektricke site? Zda se mi, ze ne. Jenze ten algoritmus typicky o tech objektech neco predpoklada a potrebuje k nim pristupovat. Takze pro implementaci toho algoritmu neni lhostejne, jaka je vnitrni struktura tech objektu.

Jsou situace, kde OOP funguje pomerne dobre - treba GUI. Protoze na to v naivni implementaci zadny algoritmus nepotrebujes. Tam pokud spolu veci nejak musi interagovat, tak maji spolecneho predka (treba Widget). OOP je proste postavene na nejake analogii s realnym svetem, ktery tak nejak prirozene delime do objektu, a prisuzujeme jim duvod, proc neco delaji. Ale to je do jiste miry dost nepresny popis reality a na mnoho problemu selhava.

To se ale týká právě těch jazyků typu C++ či Java, v nichž se pomocí design patterns dohání ta jejich objektová polovičatost.

Ano, zajima me to v Jave, to je kanonicky pripad jazyka, co pouzivaji zastanci OOP. Ale klidne muzes naznacit, jak bys to resil ve Smalltalku; pochybuji, ze pujde o skutecne skryvani dat.

Jedna z možných implementací by byla např. takováto:

Definuji vektor a skalární součin jakožto jednu z jeho operací.
Matice bude mít vnitřní reprezentaci pole m×n, budu-li potřebovat přistupovat k řádkovým/sloupcovým vektorům, nabídne je matice ad hoc pomocí vektoru.
Maticové násobení bude umět matice a realizováno bude pomocí skalárních součinů.
Čtvercová matice by byla potomkem obecné matice a operace nad ní, jako třeba determinant (to měl být asi ten "permanent"?), by byly realizovány v jejím rámci.

[Reklama]

[Ondra Satai Nekola]

Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad. A s tim bych souhlasil, vede to k problemum. Chces poprit, ze to vede k problemum? Klasicky priklad je trida matice a vektor, ktery se treba v C++ resi pres spratelene tridy.

Popravdě, aniž bych si to zkusil napsat mě teď od židle nenapadá, v čem že je u matic a vektorů problém. Mohl bys naznačit?

Predne, abych se trochu opravil - jadro Armstrongova argumentu je ze skryvani dat uvnitr objektu vede k problemum.

Mame operaci nasobeni matice a vektoru - patri do tridy matice, nebo do tridy vektor? A pokud si jednu vybereme, jak se dostaneme k prvkum te druhe? (Samozrejme, muzeme modelovat oboji jako matici, ale pak jsme se ponekud vyhnuli tomu skryvani.)

Jiny priklad. Mame tridu matice, a ta ma nejake metody. Potrebuji spocitat permanent, ale na to tam metoda neni. Jak to implementovat, aniz bych nemel pristup k vnitrnostem te tridy matice?

(Jeste bych tady mohl vlozit otazku, jak implementovat ctvercovou matici, ale to uz se tady probiralo...)

Nebo obecne, vezmi si jakykoli algoritmus. Je existence toho algoritmu vlastnosti objektu, s kterymi pracuje? Je treba moznost vypoctu maximalniho toku vlastnosti elektricke site? Zda se mi, ze ne. Jenze ten algoritmus typicky o tech objektech neco predpoklada a potrebuje k nim pristupovat. Takze pro implementaci toho algoritmu neni lhostejne, jaka je vnitrni struktura tech objektu.

Jsou situace, kde OOP funguje pomerne dobre - treba GUI. Protoze na to v naivni implementaci zadny algoritmus nepotrebujes. Tam pokud spolu veci nejak musi interagovat, tak maji spolecneho predka (treba Widget). OOP je proste postavene na nejake analogii s realnym svetem, ktery tak nejak prirozene delime do objektu, a prisuzujeme jim duvod, proc neco delaji. Ale to je do jiste miry dost nepresny popis reality a na mnoho problemu selhava.

To se ale týká právě těch jazyků typu C++ či Java, v nichž se pomocí design patterns dohání ta jejich objektová polovičatost.

Ano, zajima me to v Jave, to je kanonicky pripad jazyka, co pouzivaji zastanci OOP. Ale klidne muzes naznacit, jak bys to resil ve Smalltalku; pochybuji, ze pujde o skutecne skryvani dat.

Jedna z možných implementací by byla např. takováto:

Definuji vektor a skalární součin jakožto jednu z jeho operací.
Matice bude mít vnitřní reprezentaci pole m×n, budu-li potřebovat přistupovat k řádkovým/sloupcovým vektorům, nabídne je matice ad hoc pomocí vektoru.
Maticové násobení bude umět matice a realizováno bude pomocí skalárních součinů.
Čtvercová matice by byla potomkem obecné matice a operace nad ní, jako třeba determinant (to měl být asi ten "permanent"?), by byly realizovány v jejím rámci.

Permanent a determinant jsou dve ruzne (prestoze podobne) veci.

[čumil]

Souhlasím, že je přínos OOP zveličován. Ale ta kritika platí jen pro jazyky typu Java.

Já myslím, že to kritici vidí trochu jinak: z OOP-jak-ho-dnes-každý-chápe je děláno zlaté tele, je přeceňován význam konkrétních konceptů, které zas tak zásadní nejsou (typicky ta dědičnost) na úkor jiných důležitých konceptů (třeba toho skládání nebo posílání zpráv), a takhle zmršené OOP se vydává za "to OOP" (čti zlaté tele).

Pokud by se místo C++ a Javy masově programovalo v ObjC, myslím, že by s tím nikdo neměl moc problém, protože problémy takového přístupu by byly srovnatelné s problémy jinde (there's no silver bullet). Ale ten standard povědomí o OOP, který nastavilo především C++, je prostě k zblití...

Opravdu musím souhlasit, celí koncept dědičnosti je bullshit na osrani statického typování.

[JS]

To su cisto filozoficke problemy.

Nejsou, jak bys mohl nahlednout, kdyby sis zkusil je vyresit..

1. ci nasobenie vektora a matice ma byt metoda vektora alebo matice, alebo brontosaura, o tom rozhoduje programator. Ak to dokaze logicky odovodnit, potom je to v poriadku.

Ta hlavni otazka ovsem je, jak se z metody te jedne tridy dostanes k prvkum te druhe, kdyz aplikujes "data hiding". Ten priklad neni muj - pochazi z knizky C++ od Stroustrupa jako motivace pro spratelene tridy.

Ale mas castecne pravdu, je to jedna z veci, kterou OOP vytykam. Pokud totiz nebudes dusledny v data hiding, pak cela ta sarada s tridami nedava zadny smysl, a jsou to pseudoproblemy.

2. kazdy oop (aj smalltalk) jazyk je  vskutocnosti multiparadigmovy, takze sa nikdy nevyhneme proceduralnym konstrukciam, pripadne funkcionalnym konstrukciam.

Takze k cemu je podle tebe OOP dobre? Zase, tohle trochu napovida, ze to neni uplne promysleny koncept.

3. navrhove vzory boli vytvorene pre OOP jazyky vseobecne, neriesi sa nimi nedokonalost jazykov, ale su to vypozorovane vztahy objektov nezavisle na implementacii, ktore sa pouzivali v praxi. Vo fundamentalnej knihe od gang of four su priklady uvadzane v jazyku smalltalk.

Muj hlavni problem s navrhovymi vzory je v tom, ze jakmile budeme stejny koncept modelovat pomoci vic trid (treba v MVC - stejny widget ma casto svuj protejsek ve vsech trech pismenkach), a nikoli jako jen jednu tridu, pak cela myslenka OOP (a data hiding) se tak nejak stava zbytecnou. To uz muzeme rovnou delit svet na datove typy a funkce (coz jsou daleko jasneji definovane zalezitosti) a tridam se vyhnout uplne.

[gll]

3. navrhove vzory boli vytvorene pre OOP jazyky vseobecne, neriesi sa nimi nedokonalost jazykov, ale su to vypozorovane vztahy objektov nezavisle na implementacii, ktore sa pouzivali v praxi. Vo fundamentalnej knihe od gang of four su priklady uvadzane v jazyku smalltalk. To, ze v niektorych modernejsich jazykoch su vzory nahraditelne idiomom znamena, ze uz vytvorili abstrakciu, ktora vzory zahrnuje, nie ze by ich spravili neuzitocnymi.

to není pravda. V dynamických jazycích některé klasické návrhové vzory nedávají smysl.

http://mishadoff.com/blog/clojure-design-patterns/

[JS]

Definuji vektor a skalární součin jakožto jednu z jeho operací.
Matice bude mít vnitřní reprezentaci pole m×n, budu-li potřebovat přistupovat k řádkovým/sloupcovým vektorům, nabídne je matice ad hoc pomocí vektoru.

To neni uplne idealni, protoze ta matice bude muset pro dany radek/sloupec vytvorit novy vektor.

Čtvercová matice by byla potomkem obecné matice

Asi jako ma byt ctverec potomkem obdelnika?

a operace nad ní, jako třeba determinant (to měl být asi ten "permanent"?), by byly realizovány v jejím rámci.

Mel to byt permanent, a z dobreho duvodu.  U determinantu se da predpokladat, ze ho autor te tridy matice zahrnul jako metodu. Ale u permanentu.. uz to nebyva bezne. Ale co kdyz ja takovou metodu potrebuji?

Znovu opakuji fundamentalni otazku: Mam novy algoritmus a chci ho aplikovat na stavajici objekty (tridy). Jak to udelam, aniz bych porusil data hiding?

Ja jsem presvedceny o tom, ze data hiding je v podstate posetilost. Je to snaha vyhnout se slozite necemu, cemu se ve finale vyhnout neda.

Popisu strucne, jak by se takovy problem resil ve funkcionalnim programovani. Je to pomerne primocare. Kdo by psal ten algoritmus by ho parametrizoval nejakymi funkcemi (predanymi jako argument), ktere z obecnych objektu vyberou presne to, co ten algoritmus potrebuje znat, aby fungoval. V miste, kde se ten algoritmus vola, se pak takove funkce bud explicitne vytvori, nebo se pouziji uz existujici, a dodaji se spolu s temi konkretnimi objekty jako parametry toho algoritmu.

Takze napriklad, funkce pro vypocet permanentu potrebuje pristup k obecnemu prvku matice, takze bude parametrizovana funkci, ktera pro obecny typ (ktery bude predstavovat neco, co ma tu matici) a dany index vrati prislusny prvek. Autor algoritmu na vypocet permanentu tuto funkci nemusi znat.

Teprve v miste volani se zvoli tato funkce na zaklade struktury, s kterou chceme pracovat, a vlozi se jako parametr do toho algoritmu na vypocet permanentu. Ovsem k tomu, abychom tu funkci mohli zvolit, musime znat konretni vnitrni strukturu objektu, s kterym chceme pracovat, a tudiz musime porusit data hiding.

(Odbocka: Tohle reseni pak tak nejak prirozene vede k definici typovych trid - typova trida je vlastne soubor funkci, ktere muzeme volat nad ruznymi typy, neco jako interface, ale rozsiritelne.)

Chci zduraznit jednu vec - to funkcionalni reseni je v zasadni veci odlisne od pristupu, kdy treba ta trida matice poskytuje metodu, ktera vrati dany prvek. Kompilator totiz muze prislusnout funkci, ktera poskytuje prvky matice, zahrnout primo do prislusneho algoritmu a spolu s ni ho optimalizovat. Coz je v protikladu k data hiding, kde se ta metoda chape jako nejaka "poslana zprava". Ja nechci poslat zpravu, ja chci aby ten algoritmus mohl primo pracovat s prvky te matice. (Jinak vysvetleny ten rozdil jsem uz naznacil o x-prispevku driv - kdyz jsem psal o vyhodach FP vuci OOP - ze se jen predavaji stejna data je netrivialni poznat, ale ze se nekde vzdy aplikuje funkce identity pozna prekladac pomerne snadno.)

[balki]

To su cisto filozoficke problemy.

Nejsou, jak bys mohl nahlednout, kdyby sis zkusil je vyresit..

1. ci nasobenie vektora a matice ma byt metoda vektora alebo matice, alebo brontosaura, o tom rozhoduje programator. Ak to dokaze logicky odovodnit, potom je to v poriadku.

Ta hlavni otazka ovsem je, jak se z metody te jedne tridy dostanes k prvkum te druhe, kdyz aplikujes "data hiding". Ten priklad neni muj - pochazi z knizky C++ od Stroustrupa jako motivace pro spratelene tridy.

Ale mas castecne pravdu, je to jedna z veci, kterou OOP vytykam. Pokud totiz nebudes dusledny v data hiding, pak cela ta sarada s tridami nedava zadny smysl, a jsou to pseudoproblemy.

2. kazdy oop (aj smalltalk) jazyk je  vskutocnosti multiparadigmovy, takze sa nikdy nevyhneme proceduralnym konstrukciam, pripadne funkcionalnym konstrukciam.

Takze k cemu je podle tebe OOP dobre? Zase, tohle trochu napovida, ze to neni uplne promysleny koncept.

3. navrhove vzory boli vytvorene pre OOP jazyky vseobecne, neriesi sa nimi nedokonalost jazykov, ale su to vypozorovane vztahy objektov nezavisle na implementacii, ktore sa pouzivali v praxi. Vo fundamentalnej knihe od gang of four su priklady uvadzane v jazyku smalltalk.

Muj hlavni problem s navrhovymi vzory je v tom, ze jakmile budeme stejny koncept modelovat pomoci vic trid (treba v MVC - stejny widget ma casto svuj protejsek ve vsech trech pismenkach), a nikoli jako jen jednu tridu, pak cela myslenka OOP (a data hiding) se tak nejak stava zbytecnou. To uz muzeme rovnou delit svet na datove typy a funkce (coz jsou daleko jasneji definovane zalezitosti) a tridam se vyhnout uplne.

1.Dolezita je enkapsulacia, tj zviazanie objektu* s datami, to nemusi narusovat. Je mozne prvky matice, alebo vektoru spristupnit cez rozhranie. Ci to rozhranie poskytuje skutocnu maticu, dummy hodnoty, alebo vypocitane hodnoty, kopie hodnot je uz na samotnom objekte.  Data hiding je trosku o inom, to je o tom, aby nesiahal programator tam, kam nema. To je volitelne rozhodnutie programatora, ako napise svoje objekty, ci chce data schovavat (najcastejsie kvoli setreniu si vlastnych nervov), alebo poskytovat dalej.

2. OOP je dobre na to, ze umoznuje dalsiu uroven abstrakcie aplikacie.  Teda nie je nutne vediet nic o konkretnej vnutorenej reprezentacii, staci volat prislusne spravy. Ale to ze umoznuje, neznamena ze prikazuje. Ked si to biznis logika aplikacie vyzaduje, tak je mozne pouzit proceduralny pristup.

3. Model-view-controller je architektonicky vzor, nie navrhovy vzor. Sam je zlozeny z troch navrhovych vzorov. Observer, composite a strategy.  Navrhove vzory su iste overene opakujuce sa priklady z praxe riesenia urcitych problem (protichodnych sil) v urcitom kontexte. Je to dalsia uroven abstrakcie, ktora umoznuje opisy komplexnejsich foriem bez specifikovania detailov.

Pri architektonickom vzore mvc nejde o to, ze by jeden objekt existoval tri krat, ale ide o to, ze objekt z domenoveho sveta ma svoj obraz v objekte technologickeho sveta.  Nie je to problem objektoveho sveta ale je to problem pretinajucich zalezitosti (crosscuting concerns), ktore su v kazdej paradigme a bez nich by aplikacie neboli funkcne.


https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612
https://en.wikipedia.org/wiki/Separation_of_concerns
http://www.javaworld.com/article/2075271/core-java/encapsulation-is-not-information-hiding.html

*Schvalne pouzivam pojem objekty a nie triedy, kedze trieda-instancia je dualizmus vyjadrenia objektu a nie vzdy platny. Ale rozumiem, co je slovo trieda a co je instancia. A na objektoch netrvam.

[gll]

2. OOP je dobre na to, ze umoznuje dalsiu uroven abstrakcie aplikacie.

Přidávat úrovně abstrakce nemusí být vždy dobrý nápad.

[Kiwi]

Definuji vektor a skalární součin jakožto jednu z jeho operací.
Matice bude mít vnitřní reprezentaci pole m×n, budu-li potřebovat přistupovat k řádkovým/sloupcovým vektorům, nabídne je matice ad hoc pomocí vektoru.

To neni uplne idealni, protoze ta matice bude muset pro dany radek/sloupec vytvorit novy vektor.

Psal jsem, že to je jedna z možných implementací. Jiná je např. taková, že matice má přístupové metody k svým blokům a vektor může být generován dynamicky (klidně i bezinstančně).

Čtvercová matice by byla potomkem obecné matice

Asi jako ma byt ctverec potomkem obdelnika?

Ach jo. Tento akademický pseudoproblém je dobrý jen k tomu, aby poukázal na fakt, že v různých případech se mohou hodit různé přístupy. Ne, že jeden je dobře a druhý špatně, nebo snad že to je neřešitelný problém. Tím méně to představuje problém u matic. Takže znovu:
Se čtvercovou maticí mohu dělat všechno co s obecnou a pár operací navíc. Pokud jsem mezi ty operace zahrnul i možnost přidání/odebrání libovolného řádku/sloupce, tak, celkem logicky, předchozí věta neplatí. Zatímco u obdélníka mohu v určitých případech potřebovat změnit velikost stran, u matic to zrovna obvyklá věc není. Matice X má daný nějaký rozměr. Pokud ho změním, tak už to nebude matice X, ale přinejmenším X'. Kdybych to přesto potřeboval, pořád existují další možnosti, jako jsou sdružené třídy, skryté podtřídy, změna třídy, žádná podtřída...
(kdybych to potřeboval z toho důvodu, že dělám numerické operace s obrovskými maticemi, tak to budu dělat ve Fortranu a nebude mě to trápit vůbec)

a operace nad ní, jako třeba determinant (to měl být asi ten "permanent"?), by byly realizovány v jejím rámci.

Mel to byt permanent, a z dobreho duvodu.  U determinantu se da predpokladat, ze ho autor te tridy matice zahrnul jako metodu. Ale u permanentu.. uz to nebyva bezne. Ale co kdyz ja takovou metodu potrebuji?

Tak ji přidám přímo do té třídy.

[JS]

1.Dolezita je enkapsulacia, tj zviazanie objektu* s datami, to nemusi narusovat. Je mozne prvky matice, alebo vektoru spristupnit cez rozhranie. Ci to rozhranie poskytuje skutocnu maticu, dummy hodnoty, alebo vypocitane hodnoty, kopie hodnot je uz na samotnom objekte.  Data hiding je trosku o inom, to je o tom, aby nesiahal programator tam, kam nema. To je volitelne rozhodnutie programatora, ako napise svoje objekty, ci chce data schovavat (najcastejsie kvoli setreniu si vlastnych nervov), alebo poskytovat dalej.

Proc je enkapsulace tak dulezita? Z perspektivy nekoho, jako je Armstrong, zastance funkcionalniho programovani, to nedava smysl, protoze data jsou immutable (jinak receno, pracuje se s hodnotami, nikoli s promennymi).

Rozumim tomu, proc je enkapsulace oblibena v jazycich, ktere pochazeji (rekneme) z C, kde prirazeni a volani funkce jsou dve ruzne veci. Tam ma smysl abstrahovat prirazeni jako funkci. Ale ve funkcionalnich jazycich to tak uz je (protoze tam prirazeni neni), a pokud tedy nebudes delat ten "data hiding", tak to ani nepotrebujes delat.

Kdyz ve funkcionalnim programu definuji nejaky datovy typ, a pak definuji funkci, ktera ten datovy typ bere jako argument, svazal jsem funkce a data. Nemusim deklarovat zadny objekt, k cemu? Je to uz enkapsulovane.

Takze, pointa je, ze z pohledu FP je enkapsulace (bez skryvani dat) prazdny koncept. Takze se muzeme podivat dal a vidime, ze skryvani dat pak prinasi jen nevyhody, a tedy to odmitnout jako nesmysl.

2. OOP je dobre na to, ze umoznuje dalsiu uroven abstrakcie aplikacie.  Teda nie je nutne vediet nic o konkretnej vnutorenej reprezentacii, staci volat prislusne spravy. Ale to ze umoznuje, neznamena ze prikazuje. Ked si to biznis logika aplikacie vyzaduje, tak je mozne pouzit proceduralny pristup.

Moje otazka je, co ti tato abstrakce prinasi navic oproti funkcni abstrakci (funkcim). Podle me nic, coz je videt z toho, ze objekty muzeme simulovat pomoci funkci (pres uzavery). K cemu tedy mit v jazyce tento koncept navic.

Navrhove vzory su iste overene opakujuce sa priklady z praxe riesenia urcitych problem (protichodnych sil) v urcitom kontexte. Je to dalsia uroven abstrakcie, ktora umoznuje opisy komplexnejsich foriem bez specifikovania detailov.

Stejna namitka jako predtim. Proc ti nestaci funkcni abstrakce? Ve skutecnosti bylo ukazano, ze spousta navrhovych vzoru (pokud ne vsechny) lze modelovat pomoci funkci. Matematikum staci funkce.. Je to jenom zavadeni zbytecnych pojmu (ktere navic nejsou az tak zazracne vystizne, jelikoz nejsou uplne presne formalne definovane).

Ono by to bylo na delsi debatu... Ale v zasade jde o to, ze pokud se pokusime vetsinu tech vzoru nejak konkretneji uchopit, hodne rychle se to rozpadne na neco velmi trivialniho, co si vlastne ani jmeno moc nezaslouzi, protoze vysvetleni, jak to aplikovat, je delsi, nez popis pomoci treba funkci.

V podstate je mi tech GoF autoru (a podobnych vynalezcu) lito, protoze se heroicky snazi vyrobit neco nad OOP, co uz matematici udelali v FP a nekolikrat lepe (predevsim formalne presneji).

Pri architektonickom vzore mvc nejde o to, ze by jeden objekt existoval tri krat, ale ide o to, ze objekt z domenoveho sveta ma svoj obraz v objekte technologickeho sveta.

Ja si myslim, ze pokud bys OOP aplikoval dusledne, bude to zridkakdy pravda - na jeden objekt z domenoveho sveta budes potrebovat vicero objektu v programovacim jazyce. Coz naznacuje, ze to neni uplne dobry popis.

[JS]

Psal jsem, že to je jedna z možných implementací. Jiná je např. taková, že matice má přístupové metody k svým blokům a vektor může být generován dynamicky (klidně i bezinstančně).

Neni mi uplne jasne, jak si to predstavujes, protoze ta implementace vektoru muze treba predpokladat, ze prvky jsou v pameti za sebou. Pak bude muset ta matice pro radek nebo sloupec ten vektor explicitne vytvorit.

Cela pointa je, ze proste vektory a matice nejsou nezavisle a neni dost dobre mozne implementovat jedno bez znalosti implementace druheho. Jak rikam, pokazde, kdyz potrebujes implementovat nejaky algoritmus, jde to proti skryvani dat.

Ach jo. Tento akademický pseudoproblém je dobrý jen k tomu, aby poukázal na fakt, že v různých případech se mohou hodit různé přístupy. Ne, že jeden je dobře a druhý špatně, nebo snad že to je neřešitelný problém. Tím méně to představuje problém u matic.

Ja souhlasim, ze je to pseudoproblem, protoze OOP je pseudoreseni.

Zase, v FP na to bude primocara odpoved. Budeme mit typ (pripadne typovou tridu) matice, a typ ctvercova matice, a funkci, ktera nam z matice vyrobi ctvercovou matici (napriklad otestuje, ze je ctvercova). Nepotrebujeme vyvolavat dedicnost.

Tak ji přidám přímo do té třídy.

Pokud tu tridu muzes kdykoli zmenit, postrada ten koncept tridy smysl. Byl to jisty slib OOP, ze budou ty tridy "znovupouzitelne", tzn. nebudu je muset menit, abych je mohl treba rozsirit. To tady porusis.