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í
Poslední příspěvky