Přechod z Javy na Rust. Ano či ne?

[Kit]

Slovo ROZŠÍŘIT je ošemetné, protože se do toho vejde zbytečně moc vztahů. Potom vznikají nesmysly typu BaseController jako rodič apod. Místo toho používám slovo JE, které je pro pochopení vztahu mnohem lepší a hlavně psychologicky zamezí vzniku dědictví tam, kde být nemá.

Jaký máš názor třeba na MouseAdapter nebo jiné *Adapter třídy? Případně Default* implementace různých rozhraní? V principu jde o to, že rozhraní má více metod, ale ty chceš implementovat specifické chování třeba jen jedné z nich. Když podědíš ten adaptér, tak implementuješ jen tu jednu metodu, která tě zajímá. Pokud adaptér nebude, tak co s tím?

a) implementuješ všechny metody a necháš je prázdné
b) těch rozhraní bude mnohem víc a každé bude mít jen jednu metodu
c) řešení na úrovni programovacího jazyka (v některých to jde, ale za cenu vyšší komplexity jazyka oproti Javě)
d) něco jiného?

Ono to sice jde udělat „čistě“ a podle všech dobrých rad, pravidel a doporučení, ale to ještě neznamená, že se to bude dobře používat.

Těch rozhraní bude víc - je to popsáno v SOLID. V každém z nich bude tolik metod, kolik bude třeba - klidně i jen jedna. Dělám to tak a nejsou s tím problémy. Dokonce se ta rozhraní pojmenovávají mnohem snáze, než kdyby tam těch metod bylo víc.

Něco jiného jsou zvěrstva, o kterých píše Standa:

Ze je potreba selsky rozum, abych dovedl poznat, ktery objekt je v danem kontextu aktorem, ktery je prosty objekt, se kterym aktor manipuje.
Vidle.naberHnuj(hnuj) je spravny pristup
Hnuj.naskocNaVidle(vidle) je magorina.

Když vidím, co jsou někteří schopní vyrobit a prezentovat jako OOP, tak se pak nedivím, že hodně lidí na druhé straně OOP nesnáší a utíkají od něj pryč. Ale nemyslím si, že by problém byl ve společném předkovi typu MouseAdapter.

Připadá mi to jako divočina, hlavně mi vadí pleonasmy. Proč má v tom svém "správném přístupu" 2× slovo "hnuj", když stačí jedno?
Vidle.naber(hnuj)
Vidle.naber(seno)

Připadá mi logické, když MouseAdapter extends Adapter. Otázkou samozřejmě je, zda takového předka potřebuji.

[Reklama]

[Franta Kučera]

Připadá mi to jako divočina, hlavně mi vadí pleonasmy. Proč má v tom svém "správném přístupu" 2× slovo "hnuj", když stačí jedno?
Vidle.naber(hnuj)
Vidle.naber(seno)

Souhlas. Pokud jazyk umožňuje přetěžování metod/funkcí  (např. Java ano, Céčko ne) tak tam nadbytečná slova taky nedávám. Líp se to čte a kód je kratší.

Nicméně v tom příkladu šlo o tu logiku, který objekt je aktivní a který pasivní a kde se nachází implementace. Jde třeba o různé ukládání nebo načítání – ať už do různých souborových formátů nebo třeba do databáze nebo odeslání na po síti. Ve většině případů považuji za špatný návrh to, aby ten datový objekt měl takovou metodu. Většinou patří spíš do jiného objektu, který se o de/serializaci příslušného formátu (PNG, XML atd.) nebo obsluhu příslušného úložiště a správu spojení stará. Je to pružnější návrh, který umožňuje přidávat další formáty a úložiště (i jiným autorům) a nezanáší to rozhraní toho objektu a nezvyšuje to komplexitu jeho implementace (v něm je jen metoda a kód pro vrácení nebo načtení nějaké kanonické implementace třeba RGB bitmapy, zatímco implementace jednotlivých kodeků je jinde).

Těch rozhraní bude víc - je to popsáno v SOLID. V každém z nich bude tolik metod, kolik bude třeba - klidně i jen jedna. Dělám to tak a nejsou s tím problémy. Dokonce se ta rozhraní pojmenovávají mnohem snáze, než kdyby tam těch metod bylo víc.

Ta doporučení a principy je dobré znát, ale aplikovat je až příliš „nábožensky“ je někdy na škodu. Podobné je to s novějšími konstrukty jazyka (třeba lambdy od Javy 8 ). Kolikrát si napíšu více variant kódu a porovnávám je, přemýšlím nad tím z hlediska čitelnosti, budoucího rozvoje, výkonu… někdy z toho vyjde, že to „modernější“ nebo „správnější“ řešení slouží hůře, je méně užitečné, méně praktické. Podobně člověk někdy poruší normální formy při návrhu databáze.

Připadá mi logické, když MouseAdapter extends Adapter. Otázkou samozřejmě je, zda takového předka potřebuji.

Ten Adapter v Javě je návrhový vzor nebo spíš jen konvence. Pokud má rozhraní více metod, tak se k němu dodá i pomocná abstraktní třída Adapter, která ty metody implementuje prázdné. Pokud programátor nechce implementovat všechny metody, ale třeba jen jednu, tak podědí tuhle třídu.

To rozhraní by samozřejmě šlo rozsekat na více menších, kde v každém bude jedna metoda. Ale přínos takto vysoké granularity je sporný až záporný. Taky už jsem párkrát návrh přehnal tímhle způsobem… nebo jsem používal cizí kód napsaný tímto způsobem – a byť je to teoreticky „správnější“ není to moc užitečné.

Je dobré nad tím přemýšlet i z hlediska strukturování… v tom odkazovaném článku o komplexitě taky píšu:

Je možné, že už jsme blízko hranice dané inherentní složitostí a další zjednodušení už není bez změny zadání možné. V tomto případě si můžeme ještě trochu pomoci přeskupením prvků. Člověk není stroj a jeho kognitivní schopnosti mají svoje limity. Millerovo magické číslo nám říká, že člověk dokáže udržet v krátkodobé paměti maximálně 7±2 prvků. Počítači je celkem jedno, kolik má program tříd, kolik má třída metod, výčtový typ členů nebo komponenta parametrů. Počítač zvládne hravě vykreslit na obrazovku desítky ikon nebo vyhodnotit desítky CLI parametrů u jednoho příkazu. Počítač často škáluje lineárně a vypořádá se i s velmi vysokým počtem prvků. U člověka se to ale na určité hranici láme a schopnost porozumět systému a pracovat s ním prudce klesá. Platí to pro programátory upravující software i pro uživatele, kteří ho mají používat. Samotnou změnou struktury tedy můžeme lidem trochu pomoci vypořádat se s komplexitou.

Jinak řečeno: příliš mnoho rozhraní, tříd, metod, souborů atd. může lidem zhoršovat schopnost orientace a pomůže strukturovat program jinak. Příčí se mi sice napsat „když máte ve třídě příliš mnoho metod, tak to rozdělte do víc tříd“ nebo „když máte v adresáři příliš mnoho rozhraní tak je rozdělte do víc adresářů nebo spojte více rozhraní do jednoho“ ale ve výsledku to tak trochu je.

Pak jsou i jiné možnosti jak to navrhnout. Třeba to rozhraní posluchače událostí může mít jednu metodu přijmout(událost), do které budou chodit instance různých tříd nebo rozhraní a uvnitř té metody si pak vybereš, na co budeš reagovat. Ale to má zase jiná úskalí – kód bude méně přehledný (než u rozhraní s více metodami a Adapteru) a s dědičností/hierarchií/granularitou se sice nepotýkáme u rozhraní, ale u těch objektů reprezentujících události, takže jsme problém jen přesunuli jinam. Pro programátora-uživatele taky může být těžší dohledat, jaké všechny události mu tam můžou chodit (zatímco v jednom rozhraní vidí ty související metody vedle sebe – a až při případném rozšiřování rozhraní se udělá další, aby se nenarušila zpětná kompatibilita).

[Jiří Havel]

Jinak ono na ten nepočítačový svět nejlépe pasuje z těch programátorských paradigmat právě to objektové (neplést nutně s dědičností), protože i objekty v tom nepočítačovém světě mají nějaký stav a nějaké chování. Fyzické objekty nikdy nejsou „immutable“ (i když by si to vyznavači funkcionální víry přáli :-). Ty objekty mají stav, který se v čase mění. Většinou mají i nějaké (pozorovatelné, zajímavé) chování, naopak bezstavových funkcí nebo procedur je v nepočítačovém světě minimum, pokud vůbec...

Je celkem jedno, jestli fyzické objekty mají nějaký stav co se v čase mění. Důležité je, jestli tu změnu stavu opravdu potřebuju reprezentovat. Jestli pak ten stav není spíš kontraproduktivní, protože třeba jenom zavazí při paralelizaci.

Například je rozdíl jestli opravdu potřebuju modelovat detailní strukturu jablka a to jak si v čase vyměňuje molekuly s okolím. Nebo jenom počítám jablka jako pasivní a neměnné věci. Drtivou většinu stavu a chování objektů okolo nás obvykle zanedbáme dávno předtím, než přijde na řadu nějaké programování.

[Jožka Niemand]

Nicméně v tom příkladu šlo o tu logiku, který objekt je aktivní a který pasivní a kde se nachází implementace. Jde třeba o různé ukládání nebo načítání – ať už do různých souborových formátů nebo třeba do databáze nebo odeslání na po síti. Ve většině případů považuji za špatný návrh to, aby ten datový objekt měl takovou metodu. Většinou patří spíš do jiného objektu, který se o de/serializaci příslušného formátu (PNG, XML atd.) nebo obsluhu příslušného úložiště a správu spojení stará. Je to pružnější návrh, který umožňuje přidávat další formáty a úložiště (i jiným autorům) a nezanáší to rozhraní toho objektu a nezvyšuje to komplexitu jeho implementace (v něm je jen metoda a kód pro vrácení nebo načtení nějaké kanonické implementace třeba RGB bitmapy, zatímco implementace jednotlivých kodeků je jinde).

To ale nejde takto kategoricky, bez kontextu říci. A to je přesně to, o čem jsem mluvil - past zkušenosti "reálného světa", "selský rozum". Jenže ten občas selhává. Tento selský rozum by nám velel, že např. v nějakém GUI je nějaký painter, který zajišťuje zobrazování jednotlivých oken (jako Screen.paint(window)) - a opravdu tak něco takového může být. Ale z praktického hlediska window rozumí nějaké zprávě typu drawOn, kterou nakonec zpětně pošle ten painter tomu oknu, protože ono nejlépe ví, jak se namalovat - tedy nakresli se - což je to "zvěrstvo" typu naskoč si na vidle. Naopak, lpění na modelu z reálného světa by představovalo komplikaci.

[Kit]

Připadá mi to jako divočina, hlavně mi vadí pleonasmy. Proč má v tom svém "správném přístupu" 2× slovo "hnuj", když stačí jedno?
Vidle.naber(hnuj)
Vidle.naber(seno)

Souhlas. Pokud jazyk umožňuje přetěžování metod/funkcí  (např. Java ano, Céčko ne) tak tam nadbytečná slova taky nedávám. Líp se to čte a kód je kratší.

Nicméně v tom příkladu šlo o tu logiku, který objekt je aktivní a který pasivní a kde se nachází implementace. Jde třeba o různé ukládání nebo načítání – ať už do různých souborových formátů nebo třeba do databáze nebo odeslání na po síti. Ve většině případů považuji za špatný návrh to, aby ten datový objekt měl takovou metodu. Většinou patří spíš do jiného objektu, který se o de/serializaci příslušného formátu (PNG, XML atd.) nebo obsluhu příslušného úložiště a správu spojení stará. Je to pružnější návrh, který umožňuje přidávat další formáty a úložiště (i jiným autorům) a nezanáší to rozhraní toho objektu a nezvyšuje to komplexitu jeho implementace (v něm je jen metoda a kód pro vrácení nebo načtení nějaké kanonické implementace třeba RGB bitmapy, zatímco implementace jednotlivých kodeků je jinde).

Vezměme tvorbu JSON z objektu v PHP: Samotný převod dělám json_encode($objekt); tedy samotnou serializaci dělá vnější funkce, ale o přípravu dat se stará samotný objekt.

Těch rozhraní bude víc - je to popsáno v SOLID. V každém z nich bude tolik metod, kolik bude třeba - klidně i jen jedna. Dělám to tak a nejsou s tím problémy. Dokonce se ta rozhraní pojmenovávají mnohem snáze, než kdyby tam těch metod bylo víc.

Ta doporučení a principy je dobré znát, ale aplikovat je až příliš „nábožensky“ je někdy na škodu. Podobné je to s novějšími konstrukty jazyka (třeba lambdy od Javy 8 ). Kolikrát si napíšu více variant kódu a porovnávám je, přemýšlím nad tím z hlediska čitelnosti, budoucího rozvoje, výkonu… někdy z toho vyjde, že to „modernější“ nebo „správnější“ řešení slouží hůře, je méně užitečné, méně praktické. Podobně člověk někdy poruší normální formy při návrhu databáze.

Naopak mi připadá výhodné, když v záhlaví třídy mám "komentář" v podobě seznamu rozhraní, která musím implementovat.

Je dobré nad tím přemýšlet i z hlediska strukturování… v tom odkazovaném článku o komplexitě taky píšu:

Je možné, že už jsme blízko hranice dané inherentní složitostí a další zjednodušení už není bez změny zadání možné. V tomto případě si můžeme ještě trochu pomoci přeskupením prvků. Člověk není stroj a jeho kognitivní schopnosti mají svoje limity. Millerovo magické číslo nám říká, že člověk dokáže udržet v krátkodobé paměti maximálně 7±2 prvků. Počítači je celkem jedno, kolik má program tříd, kolik má třída metod, výčtový typ členů nebo komponenta parametrů. Počítač zvládne hravě vykreslit na obrazovku desítky ikon nebo vyhodnotit desítky CLI parametrů u jednoho příkazu. Počítač často škáluje lineárně a vypořádá se i s velmi vysokým počtem prvků. U člověka se to ale na určité hranici láme a schopnost porozumět systému a pracovat s ním prudce klesá. Platí to pro programátory upravující software i pro uživatele, kteří ho mají používat. Samotnou změnou struktury tedy můžeme lidem trochu pomoci vypořádat se s komplexitou.

Jinak řečeno: příliš mnoho rozhraní, tříd, metod, souborů atd. může lidem zhoršovat schopnost orientace a pomůže strukturovat program jinak. Příčí se mi sice napsat „když máte ve třídě příliš mnoho metod, tak to rozdělte do víc tříd“ nebo „když máte v adresáři příliš mnoho rozhraní tak je rozdělte do víc adresářů nebo spojte více rozhraní do jednoho“ ale ve výsledku to tak trochu je.

Pak jsou i jiné možnosti jak to navrhnout. Třeba to rozhraní posluchače událostí může mít jednu metodu přijmout(událost), do které budou chodit instance různých tříd nebo rozhraní a uvnitř té metody si pak vybereš, na co budeš reagovat. Ale to má zase jiná úskalí – kód bude méně přehledný (než u rozhraní s více metodami a Adapteru) a s dědičností/hierarchií/granularitou se sice nepotýkáme u rozhraní, ale u těch objektů reprezentujících události, takže jsme problém jen přesunuli jinam. Pro programátora-uživatele taky může být těžší dohledat, jaké všechny události mu tam můžou chodit (zatímco v jednom rozhraní vidí ty související metody vedle sebe – a až při případném rozšiřování rozhraní se udělá další, aby se nenarušila zpětná kompatibilita).

S tím také mohu souhlasit. Snažím se dělat návrh tak, aby počet metod byl kolem 5. Dobrou pomůckou je, že když pro název metody potřebuji víc než jen jedno slovo (sloveso), tak je možná něco špatně.

Zajímavou inspirací je v tomto ohledu formát RDF: subjekt.predikát(objekt).

[Reklama]

[balkovic]

2/ většina jazyků lepší nástroj pro reusable kódu jak dědičnost nemá (Java), některé nemají dokonce ani rozhraní (C++) (Překvapivě takový odsuzovaný jazyk jako je PHP ano.)

Dovolím si polemizovať, java má aj lambdy a to je ďalšia možnosť prepoužitelnosti kódu. Potom sú rozhrania s default implementáciami metód, čo sú vlastne traits na javovský spôsob.

Já ti nevím. Lambdy jsou IMHO na něco jiného, a default implemetace metod tak nějak neřeší, že v jedné skupině adaptérů chci tuto implementaci a v druhé skupině jinou. Nemluvě o tom, že je to stále dědění. To je stejně blbě, jak se o tom bavíme.

Keď sa interfacy s default metódami dobre použijú, umožňujú spraviť kompozíciu miesto kitchensink dedenia. A tvrdenie, že funkcionálne programovanie neumožňuje znovupoužiteľnosť kódu, za to by ma prefackali.

[Franta Kučera]

Nicméně v tom příkladu šlo o tu logiku, který objekt je aktivní a který pasivní a kde se nachází implementace. Jde třeba o různé ukládání nebo načítání – ať už do různých souborových formátů nebo třeba do databáze nebo odeslání na po síti. Ve většině případů považuji za špatný návrh to, aby ten datový objekt měl takovou metodu. Většinou patří spíš do jiného objektu, který se o de/serializaci příslušného formátu (PNG, XML atd.) nebo obsluhu příslušného úložiště a správu spojení stará. Je to pružnější návrh, který umožňuje přidávat další formáty a úložiště (i jiným autorům) a nezanáší to rozhraní toho objektu a nezvyšuje to komplexitu jeho implementace (v něm je jen metoda a kód pro vrácení nebo načtení nějaké kanonické implementace třeba RGB bitmapy, zatímco implementace jednotlivých kodeků je jinde).

To ale nejde takto kategoricky, bez kontextu říci. A to je přesně to, o čem jsem mluvil - past zkušenosti "reálného světa", "selský rozum". Jenže ten občas selhává. Tento selský rozum by nám velel, že např. v nějakém GUI je nějaký painter, který zajišťuje zobrazování jednotlivých oken (jako Screen.paint(window)) - a opravdu tak něco takového může být. Ale z praktického hlediska window rozumí nějaké zprávě typu drawOn, kterou nakonec zpětně pošle ten painter tomu oknu, protože ono nejlépe ví, jak se namalovat - tedy nakresli se - což je to "zvěrstvo" typu naskoč si na vidle. Naopak, lpění na modelu z reálného světa by představovalo komplikaci.

Ohledně třeba toho kreslení souhlasím, ale nemyslím si, že bychom byli až tak ve sporu.

Spousta těch objektů žádný protějšek v reálném světě nemá a jde čistě o konstrukt programátora… Nicméně tady bychom mohli najít třeba paralelu mezi tlačítkem na obrazovce a fyzickým tlačítkem. Ale ani to fyzické tlačítko není úplně pasivní. Zrovna co se týče zobrazení, tak to tlačítko samo nějak ovlivňuje světlo, které na něj dopadá (některé vlnové délky pohltí, jiné odrazí, některé třeba propustí skrz), a tím vytváří ten obraz. Takže to, že se tlačítko samo o sobě kreslí (místo aby se nechalo kreslit) dává smysl.* Jde ale právě o tu kanonickou reprezentaci, která je jenom jedna – kreslí se to právě jedním způsobem, negeneruje to PNG, JPEG a X dalších formátů, neobsahuje to kód kreslení pro X11, Wayland, SDL, OpenGL atd. Kreslí to např. na nějaké abstraktní plátno definované tím GUI frameworkem.

To je dost rozdíl oproti té serializaci do různých formátů (počet těch formátů je neomezený a předem neznámý). Ve fyzickém světě: i když fyzické tlačítko nějak nějak samo ovlivňuje dopadající světlo, tak to tlačítko se samo neumí popsat v různých jazycích – musí přijít někdo zvenku a říct česky: „je to červené tlačítko, na kterém je žlutý vykřičník“ – někdo jiný to řekne anglicky, někdo jiný svahilsky atd. Těch jazyků je mnoho a během existence tlačítka mohou klidně vzniknout nové – tlačítko o nich vůbec nemůže a nemá vědět.

Píšu o problému, na který občas narážím v praxi – někdo do objektu zadrátuje nějaké konkrétní exporty nebo operace místo toho, aby to řízení buď úplně obrátil nebo tam dal jen nějaký jeden kanonický tvar / abstraktní operaci. Takový návrh je nepružný a problém je jednak v tom, že je tam zadrátovaná komplexita nějakého konkrétního formátu (a v budoucnu tam lidi budou přidávat další formáty potažmo závislosti na dalších knihovnách a budou nesmyslně navyšovat komplexitu místo toho, aby ty závislosti byly volitelné a někde jinde) a jednak v tom, že nejde přidat další formát, aniž bych měnil kód dané třídy.

*) ono to tedy bývá trochu složitější, protože ty GUI komponenty mívají nějaký model obsahující čistá data a pak pohled – ten model nic nekreslí, ten pohled ano, i když část toho kreslení deleguje ještě na jiné třídy, díky kterým celé to GUI bude mít jednotný vzhled a chování

[Franta Kučera]

P.S. Ještě k té paralele se světlem: Tlačítko nějak formuje světlo (pohlcuje, odráží, propouští). To je ta kanonická reprezentace. Ale jestli se to propuštěné nebo odražené světlo promítne na bílou stěnu, plátno s nějakou texturou, film nebo snímač fotoaparátu atd. to už to tlačítko neřeší – to je kompetence někoho jiného, stejně tak kdo a jak na to tlačítko bude svítit. Podobně v počítači: třída tlačítka sice ovlivňuje jak ten obraz bude vypadat, ale jestli se vykreslí na X11, do OpenGL nebo třeba do PDF, to už řeší někdo jiný.

[Zdenek Tomes]

Fyzické objekty nikdy nejsou „immutable“ (i když by si to vyznavači funkcionální víry přáli :-). Ty objekty mají stav, který se v čase mění.

To je nepatřičná zkratka. Fyzické objekty většinou mají identitu, ta se nemění. A jejich stav se v čase může měnit (jinak by to byla konstanta), ale ten stav samotný ("otisk objektu") bude hodnotou, která je immutable, že? Nebo naopak: modifikace nějakého atributu objektu vede ke změně jeho stavu (to asi souhlasí), ale identita je zachována.

Ale asi souhlas s tím, že čím víc se vzdalujeme od matematiky (kde se pracuje s immutable hodnotami) k fuzzy reálnému světu, tím míň je funkcionální přístup přirozený.

[Filip Jirsák (forum)]

Ze je potreba selsky rozum, abych dovedl poznat, ktery objekt je v danem kontextu aktorem, ktery je prosty objekt, se kterym aktor manipuje.
Vidle.naberHnuj(hnuj) je spravny pristup
Hnuj.naskocNaVidle(vidle) je magorina.

Tohle je ovšem čistě záležitost přirozeného jazyka, ve kterém to popisujete. A nemyslím si, že by implementace v kódu měla být až tak závislá na jazyce, ve kterém máte popsané zadání.

Ono to i česky můžete napsat Hnuj.naberSeNa(vidle), a už to taková magořina není. I když sloveso nabrat se obvykle ve zvratné formě nepoužíváme.

Ale co třeba takové:

Kód: [Vybrat]

vaha.zvazit(osoba)
osoba.zvazitSe(vaha)
Je něco z toho zjevně dobře nebo zjevně špatně?

Nicméně v tom příkladu šlo o tu logiku, který objekt je aktivní a který pasivní a kde se nachází implementace. Jde třeba o různé ukládání nebo načítání – ať už do různých souborových formátů nebo třeba do databáze nebo odeslání na po síti. Ve většině případů považuji za špatný návrh to, aby ten datový objekt měl takovou metodu. Většinou patří spíš do jiného objektu, který se o de/serializaci příslušného formátu (PNG, XML atd.) nebo obsluhu příslušného úložiště a správu spojení stará. Je to pružnější návrh, který umožňuje přidávat další formáty a úložiště (i jiným autorům) a nezanáší to rozhraní toho objektu a nezvyšuje to komplexitu jeho implementace (v něm je jen metoda a kód pro vrácení nebo načtení nějaké kanonické implementace třeba RGB bitmapy, zatímco implementace jednotlivých kodeků je jinde).

Pak ovšem musíš vnitřní stav toho objektu zpřístupnit vnějšímu světu (pro serializaci a deserializaci), což porušuje princip zapouzdření.

[Jiří Havel]

Spousta těch objektů žádný protějšek v reálném světě nemá a jde čistě o konstrukt programátora… Nicméně tady bychom mohli najít třeba paralelu mezi tlačítkem na obrazovce a fyzickým tlačítkem. Ale ani to fyzické tlačítko není úplně pasivní. Zrovna co se týče zobrazení, tak to tlačítko samo nějak ovlivňuje světlo, které na něj dopadá (některé vlnové délky pohltí, jiné odrazí, některé třeba propustí skrz), a tím vytváří ten obraz. Takže to, že se tlačítko samo o sobě kreslí (místo aby se nechalo kreslit) dává smysl.* Jde ale právě o tu kanonickou reprezentaci, která je jenom jedna – kreslí se to právě jedním způsobem, negeneruje to PNG, JPEG a X dalších formátů, neobsahuje to kód kreslení pro X11, Wayland, SDL, OpenGL atd. Kreslí to např. na nějaké abstraktní plátno definované tím GUI frameworkem.

Tohle je dost blbý přístup i když potřebuju řešit subsurface scattering v tom plastu. Ve chvíli, kdy jen potřebuju vidět tlačítko, už je to naprosto zcestné.

Začíná to znít jako racionalizace toho, že cpete mutable stavy i tam, kam se vůbec nehodí. Doufám, že se v tomhle pletu.

[Jiří Havel]

To je nepatřičná zkratka. Fyzické objekty většinou mají identitu, ta se nemění. A jejich stav se v čase může měnit (jinak by to byla konstanta), ale ten stav samotný ("otisk objektu") bude hodnotou, která je immutable, že? Nebo naopak: modifikace nějakého atributu objektu vede ke změně jeho stavu (to asi souhlasí), ale identita je zachována.

Ale asi souhlas s tím, že čím víc se vzdalujeme od matematiky (kde se pracuje s immutable hodnotami) k fuzzy reálnému světu, tím míň je funkcionální přístup přirozený.

Ta identita je jen naše abstrakce. Při bližším pohledu to drhne (např. Theseova loď nebo dědečkova sekera).

A i ten "fyzický objekt" je naše škatulka, navíc kapku neostrá.

Směřuju k tomu, že když o něčem mluvíme, tak obvykle žonglujeme s abstraktními immutable objekty, které existují leda tak v nějakém paralelním myšlenkovém nebo platonickém světě. Mapování na nějaké immutable reprezentace není nějaká matematická specialitka, děláme to úplně běžně že to ani nevnímáme.

[Kit]

Nicméně v tom příkladu šlo o tu logiku, který objekt je aktivní a který pasivní a kde se nachází implementace. Jde třeba o různé ukládání nebo načítání – ať už do různých souborových formátů nebo třeba do databáze nebo odeslání na po síti. Ve většině případů považuji za špatný návrh to, aby ten datový objekt měl takovou metodu. Většinou patří spíš do jiného objektu, který se o de/serializaci příslušného formátu (PNG, XML atd.) nebo obsluhu příslušného úložiště a správu spojení stará. Je to pružnější návrh, který umožňuje přidávat další formáty a úložiště (i jiným autorům) a nezanáší to rozhraní toho objektu a nezvyšuje to komplexitu jeho implementace (v něm je jen metoda a kód pro vrácení nebo načtení nějaké kanonické implementace třeba RGB bitmapy, zatímco implementace jednotlivých kodeků je jinde).

Pak ovšem musíš vnitřní stav toho objektu zpřístupnit vnějšímu světu (pro serializaci a deserializaci), což porušuje princip zapouzdření.

V tomto smyslu porušují zapouzdření všechny gettery a settery. Přesto je kdekdo používá.

[Jožka Niemand]

To je dost rozdíl oproti té serializaci do různých formátů (počet těch formátů je neomezený a předem neznámý).

No a v objektovém návrhu, jak ho chápu já, by naopak spíše objekt toužící po serializaci jiného objektu (exportu do jiného formátu...) poskytl takovému objektu objekt, pomocí kterého si to ten inkriminovaný objekt zařídí sám. Tím netvrdím, že opačný přístup je chybný, spíše bych řekl, že ve skutečnosti jen není objektový, protože narušuje zapouzdření. Ve skutečnosti může být (a také asi bude) jednodušší a efektivnější - znalost nějakých vnitřních detailů objektu může spoustu věcí usnadnit, naopak - blackboxing "za každou cenu" může vést k neřešitelným (nepředvídatelným) situacím při návrhu rozhraní. Ale to se dostáváme k samotné filosofické otázce, zda tedy vůbec OOP.

[Kit]

To je dost rozdíl oproti té serializaci do různých formátů (počet těch formátů je neomezený a předem neznámý).

No a v objektovém návrhu, jak ho chápu já, by naopak spíše objekt toužící po serializaci jiného objektu (exportu do jiného formátu...) poskytl takovému objektu objekt, pomocí kterého si to ten inkriminovaný objekt zařídí sám. Tím netvrdím, že opačný přístup je chybný, spíše bych řekl, že ve skutečnosti jen není objektový, protože narušuje zapouzdření. Ve skutečnosti může být (a také asi bude) jednodušší a efektivnější - znalost nějakých vnitřních detailů objektu může spoustu věcí usnadnit, naopak - blackboxing "za každou cenu" může vést k neřešitelným (nepředvídatelným) situacím při návrhu rozhraní. Ale to se dostáváme k samotné filosofické otázce, zda tedy vůbec OOP.

Tím jsme se dostali k DIP, v C# reprezentovány například delegáty.