Vlákno názorů k článku Základy programování ve Squeaku od hyperion - Ten příklad v Javě uvedený v článku mě zaujal, ještě...
-
hyperion (neregistrovaný)
Ten příklad v Javě uvedený v článku mě zaujal, ještě včera (skoro předevčírem) jsem netušil, že se takto jedna instance třídy může hrabat v atributech instance jiné. Není to porušení zapouzdření a proč to vlastně je takto navržené (možná nějaká optimalizace pro jednodušší kompilaci?)
-
ondra.novacisko.cz (neregistrovaný)
Práva přístupu v OOP nemá až takový význam. Lze je dodržovat i bez nutnosti mít na to jazyk připravený. Je jedno, jestli Vám tu blokaci udělá překladač, poznámka u proměnné, nebo Váš mozek (v duchu předchozích postů, to je o té OOP filozofii).
Nevím, jak se chová Java, ale v C++ se lze hrabat v atributech objektů téže třídy přímo. Vysvětlení je takové, že metody, které třída implementuje nejsou vlastnictvím instancí, ale zůstávají vlastnictvím třídy. Instance je pouze „dědí“. A protože metody vědí, jaký význam má každá instance toho atributu v každé instanci třídy, mohou tyto atributy měnit. V ideálním OOP tohle nejde, protože objekt po svém vzniku se může vyznamně změnit, může například ten atribut odstranit, nebo změnit jeho význam (tedy nejde jen o změnu hodnot, ale i struktury). Protože, ony vlastně v ideálním OOP třídy neexistují, všechno jsou to jen objekty.
Tohle ale není zábrana, proč by se v Javě, nebo v C++ nemělo dát OOP programovat. Jsou to jen určitě OOP modely, které mají některé speciality. -
SB (neregistrovaný)
Největší hodnota zapouzdření je v tom, že garantuje hranici objektu, za kterou je vše v bezpečí. V okamžiku, kdy zmizí zapouzdření, stav vnitřku není možno zaručit. Spoléhat na disciplínu uživatelů objektu je nesmysl. Je to jako spoléhat na řidiče, že budou dodržovat rychlost (=hranici).
Z toho je taky vidět, jak to myslí Java a C++ s objekty vážně, když je možno vlastnosti objektu udělat public. V Ckanál je to syntakticky komplikovaně opraseno pomocí get a set… -
ondra.novacisko.cz (neregistrovaný)
Neuvažujete dvě věci:
1) Programovací jazyky nemají o uživatele vychovávat. To je ta pomyslná svoboda vs vedení za ručičku, jak se tu někdo ptal, co se tím myslí.
2) V Javě i v C++ to MÁ opodstatnění, protože každý objekt má vlastně jen atributy, ale instance sdílí metody. Proto nemůže přístup do atributů jednoho objektu z metod jiného objektu způsobit nepředvídatelné potíže. Pokud by někdo do systému „vrhnul“ objekt jiného „typu“, pak už tam přístup mít nebude. Jedná se o modifikátory private ale i protected, pokud jde o zásah do atributů předka potomkem, v případě, že jde o jinou instanci. Prostě vyžadovat „superprivate“ atributy tady jaksi postrádá smysl. OOP v Javě a v C++ je stále stavěno na systémem, že objekty jsou spíš data a kód vykonává JEDNA třída. A je blbost, aby si ta JEDNA třída dělala getry a setry. Asi jako kdyby v jiných OOP jazycích, kde to mají blíže ideálu si k atributům objekt přistupoval přes svoje getry a setry.
Mimochodem co říkáte na property? I to patří do OOP, kdy atribut se tváří jako proměnná, ale ve skutečnosti je to properta, která si sama zavolá getr a setr. Co jsem kdysi dávno četl na www.objects.cz, tak to ničemu nevadí. Potom i atributy nemusí nutně být vždy privatní, protože pokud se ten objekt má někdy v budoucnu změnit, udělá se z něho properta a rozdíl se nepozná. -
SB (neregistrovaný)
K 1) A o výchovu uživatele jazykem se zde jedná, když mu v něčem jazyk brání (nedostupnost vnitřku objektu), nebo když spoléhá na jeho sebekázeň (nepoužívání přímého přístupu k vlastnostem)???
S výchovou nebo uživatelem to nemá co dělat, účelem je pouze zajištění nedotknutelnosti. Zapouzdření nevzniklo, aby vychovávalo, ale aby garantovalo. Jeho nepřítomnost pro mě neznamená nesvobodu, ale nejistotu. Svoboda (lépe volnost) pro mě ve Smalltalku znamenají např. reflexe, dynamické typování (možno pro Vás přeložit jako nepřítomnost vedení za ručičku typovou kontrolou) a lambda-výrazy, což dává dohromady obrovské možnosti s minimální námahou.
K 2) Tomuto odstavci popravdě vůbec nerozumím.
K termínům: Dochází tu k spojování termínů objekt a instance. Buďto jen objekt (třeba u prototypování) nebo třída+instance (u třídně-instančního modelu). Pod OOP se dnes myslí jazyky hybridní (kombinují imperativní paradigma), čistě objektové se označují jako object languages, pure object languages nebo object based languages.
Property (tak, jak jsem to viděl v Ckanálu) považuju za další zbytečný syntaktický balast. -
ondra.novacisko.cz (neregistrovaný)
To se tezko diskutuje, kdyz se hadame nad obecne známými terminy
Třída – v OOP neexistuje, v typovaných jazycích speciálním typem objektu zpravidla singletonem (ale nemusí být úplně pravda, viz šablony), který je vzorem pro tvorbu instance, obsahuje metody, které objekty instancí následně „dědí“, a mimojiné slouží k definici interface (rozhraní), jakým bude výsledný objekt komunikovat, což je nástroj typové kontroly. V každém případě je Třída zvláštním druhem objektu. V generice pak chápu třídu jako instancí šablony. Šablona je pak objekt, který je vzorem pro tvorbu tříd.
Instance – v OOP opět neexistuje, v typovaných jazycích speciálním typem objektu, který vznikl konstrukcí zkrze konstruktor třídy, kterou také „svým způsobem“ dědí. Instance obsahuje atributy, které jsou její vlastní, ale i metody, které sdílí s ostatními instancemi.
Objekt je prostě jen mnohem obecnější pojetí, než jen Instance a Třída. V C++ a v Javě a v ostatních podobných jazycích známe jen Třídy a Instance a říkáme si, že to je svět OOP. Ale oba nástroje, tedy Třída a Instance jsou jen speciálním typem objektů, byď dost obecnými na to, aby se daly používat ke spoustě věcí. V C++ lze demonstrovat, že existují i další typy objektů, například právě šablony. Programátor pracující se šablonami kolikrát právě třídy považuje za instance, a šablony přebírají původní význam tříd. Program který píší v šablonách pak spouští v překladači a výsledkem jeho běhu je přeložený program. I i tady se dá OOP uplatnit, dokonce mnohem obecněji, než v runtime mezi třídami a instancemi.¨
A zrovna property například boří mýtus o nutností privátních atributů. Proč musí být privátní? Někdy to nemá úplně smysl. Například je přirozené, aby objekt Bod měl public atributy X,Y,Z spíš, než definovat hromadu zbytečných getrů a setrů, jejichž jediným významem je obejít onanii objektových maniaků. Původním důvodem bylo, aby objekt měl plnou kontrolu nad zmenou těch atributů. Ale kdo říká, že vystavením atributů by tu kontrolu měl ztratit? -
SB (neregistrovaný)
Třída není podmínka OOP, ale třídně-instanční model je způsob implementace objektového prostředí. Píšu to proto, že když se mluví o tomto modelu, tak termín objekt neříká, zda máte na mysli třídu nebo instanci.
Jediný jazyk, o kterém vím, že implementuje třídy jako instance metatříd (nejsou to ty Vaše šablony???), je Smalltalk. U C++ jsem předpokládal pouze deklarativní model tříd bez toho, aby existovala jako instance, ale péro do ohně za to nedám.
Rozhraní objektu se nazývá protokol a v původním pojetí OOP určitě neslouží k typové kontrole.
Generiku jsem nepochopil, připadá mi jako způsob, jak obejít typovou kontrolu, když už tam je, ale k tomu by mohli něco říct jiní.
Instance – obdobně jako třída – způsob implementace OOP.
Vizte výše: Pokud vím, třídy nejsou v jazycích (až na pár výjimek) implementovány pomocí objektů, ale jsou pouze deklarativní.
„Programátor pracující se šablonami kolikrát právě třídy považuje za instance, a šablony přebírají původní význam tříd.“ V metatřídním modelu (Smalltalk) jsou samozřejmě třídy instance metatříd, ale to programátora nemusí zajímat. Platí to ale u C++? Je možno třídě poslat zprávu class, která vrací třídu dané třídy? A další zprávy?
Privátní musejí být proto, že dle původní myšlenky OOP do vnitřku objektu nikomu nic není a když něco chce, tak se zeptá. Gettery a settery jsou v podstatě to samé, jako přístupové metody, proti kterým samozřejmě nic nemám, ale proč na to vyrábět další syntaktickou konstrukci, kterých je v Ckanálu už tak mraky, to nechápu. -
SB (neregistrovaný)
Ještě jednou k property: Samotné vystavení vlastností je samozřejmě ztráta zapouzdření, ale jako property se o vystavení nejedná, jsou to jen jinak pojmenované přístupové metody. Ale znovu: Je třeba kvůli tomu rozšiřovat syntax??? Síla Smalltalku je (nejen) v jednoduchosti syntaxe. Už nevím, kde jsem to četl: „Jazyk je dokonalý ne tehdy, když už do něj není co přidat, ale když už není co ubrat.“
