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?
...
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?
...
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.
Ufff, to je hukot...
Matici je možno modelovat vektory, pak půjde o skládání!!! Dědičnost tu nemá co pohledávat! Nebo je možno matici modelovat bez vektorů, aniž by to mělo vliv na funkcionalitu. Provedení je ponecháno na soudruhovi.
K čemu je mi matice či vektor, do kterého nevidím?!!! Neboli asi budou immutable, ale není důvod, aby jejich hodnoty nebyly viditelné!
Chybí metoda? Je několik možností:
1. Specializace: vytvořit podtřídu - její zvláštností je, že umí něco navíc. V pořádku.
2. Extended method (u některých jazyků).
3. V Smalltalku: třídy (i z jiných balíčků) je možno běžně rozšiřovat o vlastní metody (ve svých balíčcích), takže stačí doplnit.
4. Skládání: Vyrobím objekt, který bude obsahovat původní matici (její vytvoření ap.), a doplním jej o požadovanou metodu. V jazyku s pozdní vazbou (Smalltalk, ...) to mám o to jednodušší, že na předelegování metod seru a vyřeším je jedním vrzem přeposláním zprávy z doesNotUnderstand (to kdyby někdo potřeboval vědět, na co že ta hovadina je).
5. Vždy (jako všude jinde) můžu třídu vyrobit znovu, nechci-li použít něco existujícího.
Opět snadná uchopitelnost OOP v GUI, protože to jde vidět?
Takže opět a pořád dokola: Chyba není v OOP, ale v znalosti jeho použití.