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.
Možností je více. Matice např. může poskytnout nějaký vhodný iterátor pro přístup ke svým prvkům. Vektor může jít zkonstruovat s pomocí takového iterátoru, pomocí něhož si bude prvky příslušné (sub)matice obstarávat přímo od ní skrze něj.
Tím skrýváním dat v OOP se myslí skrývání jejich
implementace, nikoli dat jako takových. Myšlenka je taková, že mám-li objekt řetězec, je jeho konkrétní implementace (např. jako pole bajtů v nějaké konkrétní podobě nějakého konkrétního kódování, nebo navíc třeba i nějak zkomprimované, zašifrované, opatřené CRC a co já vím, co ještě) skryta. Ale rozhodně to neznamená, že bych se k tomu řetězci nemohl dostat. To by bylo poněkud... nepraktické.
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.
Ale v OOP přece taky ne, pokud by to nebylo k ničemu. Už to tu píšu asi tak potřetí, že odvodit podtřídu je v daných příkladech jen jedna z možností. Vhodná-li, to by záleželo na konkrétním kontextu. Zrovna tak tu můžeme hloubat, jak řešit (anti)symetrické matice, (tri)diagonální matice atd., ale nic nevyhloubáme, protože takto obecně se o tom moc říci nedá. Takový je zkrátka život, že na jednu věc se dá dívat z různých stran.
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.
Pokud k tomu
rozšíření nepotřebuji znát implementační detaily dat oné třídy, půjde ve většině případů o
kompozici. Tato otázka se ovšem nedá rozřešit teoreticky, ale jedině případ od případu, protože se silně dotýká optimalizace přístupu k datům.
(v daném příkladu je to další možnost, jak doplnit matici o ten permanent, pokud nechci nebo nemohu upravit původní třídu)
Jinými slovy: modelování světa do stromu, kde děti mají vždycky jenom jednoho rodiče a vždycky se jenom specializují, je prostě trochu problematický, reálnýmu světu to moc neodpovídá
Rozhodně. Jenže na tom taky OOP založeno není, ačkoli si to většina lidí zblbnutých javským a cépluspluskovým pojetím myslí. Objektový program jsou škatulky, které si vzájemně vyměňují
zprávy, a pochopení tohoto konceptu zpráv je naprosto klíčové k správnému pochopení celého objektového programování, protože právě v tom vězí celá ta síla a tvárnost.
Velmi správně píšeš, že vztah potomka k rodiči musí být zásadně specializační. A velmi správně píšeš, že to sotva může stačit k modelování problémů reálného světa. Ale je třeba mít na paměti, že odvozování podtříd je jen jedním z pomocných nástrojů objektového modelování.