Čada: Objektové programování

[Radek Miček]

nutnost explicitně funkcím předhazovat data

To děláte i v jiných OO jazycích, ne? Když například napíši obj.met(), tak metodě met explicitně předávám objekt obj.

Ne!!! Nemůžu si vybírat stavy (objekt) pro jednu metodu, nemůžu napsat jiný_obj.ta_samá_met(), protože metoda je součástí objektu a pracuje s jeho stavy! To je nepochopení OOP. V OOP se nemůžu kdykoli šťourat ve stavech cizími metodami.

Ve stavu se nešťouráte cizími funkcemi - jsou to funkce z toho modulu.

Zapouzdření funguje spolehlivě. Například implementace zásobníku v OCamlu...

Jde ten seznam zásobníku z venku přečíst či něčím přepsat, i když neznám jeho strukturu? Jde => nejedná se o zapouzdření, nejde => je zapouzdření.

Nejde.

Moduly v OCamlu můžete chápat jako objekty bez dědičnosti - můžete je předávat funkcím i vracet z funkcí.

To je typický imperativní přístup - obecným funkcím předhazuju nějaká specifická data/stavy. Nic takového OOP nemá.

Nerozumím. Vždyť i v OOP mohu metodám předat/poslat jiný objekt.

Nicméně na rozdíl od modulů/struktur nemohou objekty (z objektového systému) obsahovat typy.

Čistě objektový systém NESMÍ obsahovat typy, není k tomu důvod a komplikuje to celý výpočetní model.

Podobně jako máte virtuální metody, můžete mít i virtuální třídy - typy ve třídách dávají dobrý smysl. Viz třeba OO jazyky BETA nebo Scala.

Obecně typy ve třídách zvyšují vyjadřovací schopnosti jazyka

[Reklama]

[Radek Miček]

Klasický argument, že typová kontrola řeší chyby - neřeší, garantuje, že do stringu nedáte číslo, ale už negarantuje, že tam nestrčíte řetězec, který tam vůbec nemá smysl. Kdežto zapouzdření garantuje, že se vůbec nedostanete k datům, ke kterým se dostat nemáte, takže s nimi ani pracovat nemůžete.

Záleží, jaký máte typový systém. Například v jazycích se závislými typy to jde. Například můj starší kód v jazyce Idris má testy na úrovni typového systému:

Kód: [Vybrat]

test_parseLit_pos : so $ parseLit "c" == Right (MkLit Pos "c")
test_parseLit_pos = oh

Zde se jedná o test funkce parseLit - typ so $ parseLit "c" == Right (MkLit Pos "c") - obsahuje její volání - při typové kontrole se tedy funkce parseLit zavolá a zkontroluje se, že vrátila Right (MkLit Pos "c").

[PeVa]

Zrovna podobný problém se zapouzdřením řeším (setry, getry a podobně) už hodně let.
Podle mne je pro výsledek rozhodující jaký koncept ošetření chybových stavů je implementován celkově v systému.
Jestli pozdní nebo včasný. Teď nemluvím o testovaní uživatelem zadaných hodnot, ale řešení výjímek/výjmečných stavů.

Včasný koncept je založen na principu,že nekorektní stavy neumožní objekt ani vytvořit.
Pozdní koncept je založen na principu, že nekorektní stavy jsou ošetřovány až v momentě potřeby, ale objekt jde
vytvořit. A metody, které s uvedenými stavy nepracují mohou normálně fungovat.

Uvedu na příkladu:
řekněme, že máme třídu psa. A chceme vytvořit jednu instanci na základě dat s db, ale po načtení zjistíme,
že je požadováno vytvořit psa se 3 nohama....(neřeším jak tato věc v db vznikla).
A) Včasné řešení neumožní psa ani vytvořit. Vyjímku vyhodí už constructor.
B) Pozdní řešení psa vytvoří, ale vyjímky vyhodí až metoda běhej. Metoda podej pac bude normálně fungovat pro zdravé nohy.

OOP teorie říkají, že A) je správně..objekt lze založit jen pokud jsou stavy vnitřně konzistentní.

Bohužel praxe ukazuje, že B) je významně lepší, neboť nám dává možnost na nekorektní stavy reagovat a
chybný stav opravit (psa zoperovat, aby měl 4 nohy a mohl pak běhat).

Pro A) musím explicitně řešit jak se vypořádat s nekonzistencí, ale to je někdy problém, nekonzistnce je vně systému.

Pro B mám tedy volnější podmínky na konzistenci vnitřních stavů a getry a setry, zde často postrádají úplně smysl.
neboť konzistenci hodnot nekontrolují....

PeVa

[SB]

Čistě objektový systém NESMÍ obsahovat typy, není k tomu důvod a komplikuje to celý výpočetní model.

jaká je definice objektového systému? resp. jak je definován "objektový výpočetní model"?

Model, jehož hodnoty a výpočty jsou realizovány objekty. Kupodivu. Hybridní model je něco jiného.

[JSH]

PeVa :
Tady bych nesouhlasil. Možnost A podstatně zmenšuje množství stavů, které musím jako programátor řešit. Pokud mám konzistentního Psa, tak nemusím řešit jestli umí běhat na každém místě, kde ho chci použít. Přišití nohy můžu řešit na jediném místě a to tam, kde ten objekt vytvářím.
Takhle veškeré nekonzistence zvenku řeším právě na hranici systému a uvnitř je všechno konzistentní.

Samozřejmě pokud modeluju veterinu, tak budou požadavky na konzistentního psa trochu jiné, než když modeluju K9.

[Reklama]

[v]

Čistě objektový systém NESMÍ obsahovat typy, není k tomu důvod a komplikuje to celý výpočetní model.

jaká je definice objektového systému? resp. jak je definován "objektový výpočetní model"?

Model, jehož hodnoty a výpočty jsou realizovány objekty. Kupodivu. Hybridní model je něco jiného.

vy sem tu definici napsat nechcete nebo neumíte? nebo si myslíte, že si dělám srandu? nebo jak je to s váma?

[Kit]

Uvedu na příkladu:
řekněme, že máme třídu psa. A chceme vytvořit jednu instanci na základě dat s db, ale po načtení zjistíme,
že je požadováno vytvořit psa se 3 nohama....(neřeším jak tato věc v db vznikla).
A) Včasné řešení neumožní psa ani vytvořit. Vyjímku vyhodí už constructor.
B) Pozdní řešení psa vytvoří, ale vyjímky vyhodí až metoda běhej. Metoda podej pac bude normálně fungovat pro zdravé nohy.

OOP teorie říkají, že A) je správně..objekt lze založit jen pokud jsou stavy vnitřně konzistentní.

Bohužel praxe ukazuje, že B) je významně lepší, neboť nám dává možnost na nekorektní stavy reagovat a
chybný stav opravit (psa zoperovat, aby měl 4 nohy a mohl pak běhat).

Pro A) musím explicitně řešit jak se vypořádat s nekonzistencí, ale to je někdy problém, nekonzistnce je vně systému.

Pro B mám tedy volnější podmínky na konzistenci vnitřních stavů a getry a setry, zde často postrádají úplně smysl.
neboť konzistenci hodnot nekontrolují....

PeVa

A) také nepotřebuje getry/setry. Pokud potřebuji mít možnost třínohého psa, ošetřím to v konstruktoru, resp. tuto kontrolu mohu vypustit. Pokud však čtyřnohému psu budu chtít nohu amputovat, místo setteru provedu chirurgický zákrok. Tedy pokud urizniNohu() nepovažuješ za setter.

[SB]

Na grafové věci je OOP to nejstrašnější, co jsem kdy viděl. Obzvlášť jak se objeví visitor pattern.

Na grafové věci je imperativní paradigma to nejstrašnější, co jsem kdy viděl. Obzvlášť jak se objeví for( ).

Vaše neznalosti věcí mimo OOP už opravovat nebudu. Taky mě to nebaví.

Úplně stačilo odpovědět na některé dotazy. Taky vás neprcám za vaše znalosti OOP.

[PeVa]

PeVa :
Tady bych nesouhlasil. Možnost A podstatně zmenšuje množství stavů, které musím jako programátor řešit. Pokud mám konzistentního Psa, tak nemusím řešit jestli umí běhat na každém místě, kde ho chci použít. Přišití nohy můžu řešit na jediném místě a to tam, kde ten objekt vytvářím.
Takhle veškeré nekonzistence zvenku řeším právě na hranici systému a uvnitř je všechno konzistentní.

Samozřejmě pokud modeluju veterinu, tak budou požadavky na konzistentního psa trochu jiné, než když modeluju K9.

Není to úplně přesné, jak to popisuješ...při B) test na nohy musíš implementovat ve všech metodách, kde pes nohy bude používat, při štěkání pochopitelně ne. Není to ani tak, že každé běhání psa má vlastni implementaci, ta je pochopitelně jen jedna.
B) je sice pracnější, ale za to názorné a dokumentuje nutné předpoklady pro úspěšné zvládnutí funkcionality-činnosti. Když se nějakej mimozemšťan zeptá, k čemu ten pes vlastně nohy potřebuje, a jaké musí být, tak je to hned jasné. Podobně je to s ocasem a ušima.

Ano v tvém kontextu při A) se situace zjednodušší, nicméně jsi jen přenesl zodpovědnost za řešení nekonzistence vně.
Nekonzistenci tak jako tak někdo musí nakonec vyřešit. Jak ji chceš ale vyřešit, když nemužes vytvořit ani psa, že?

[v]

PeVa :
Tady bych nesouhlasil. Možnost A podstatně zmenšuje množství stavů, které musím jako programátor řešit. Pokud mám konzistentního Psa, tak nemusím řešit jestli umí běhat na každém místě, kde ho chci použít. Přišití nohy můžu řešit na jediném místě a to tam, kde ten objekt vytvářím.
Takhle veškeré nekonzistence zvenku řeším právě na hranici systému a uvnitř je všechno konzistentní.

Samozřejmě pokud modeluju veterinu, tak budou požadavky na konzistentního psa trochu jiné, než když modeluju K9.

Není to úplně přesné, jak to popisuješ...při B) test na nohy musíš implementovat ve všech metodách, kde pes nohy bude používat, při štěkání pochopitelně ne. Není to ani tak, že každé běhání psa má vlastni implementaci, ta je pochopitelně jen jedna.
B) je sice pracnější, ale za to názorné a dokumentuje nutné předpoklady pro úspěšné zvládnutí funkcionality-činnosti. Když se nějakej mimozemšťan zeptá, k čemu ten pes vlastně nohy potřebuje, a jaké musí být, tak je to hned jasné. Podobně je to s ocasem a ušima.

Ano v tvém kontextu při A) se situace zjednodušší, nicméně jsi jen přenesl zodpovědnost za řešení nekonzistence vně.
Nekonzistenci tak jako tak někdo musí nakonec vyřešit. Jak ji chceš ale vyřešit, když nemužes vytvořit ani psa, že?

a není to jenom falešné dilema? co vytvořit z dat z venku objekt snadno manipulovatelný, ale bez kontrol, druhému objektu s kontrolou tento předat a pokud kontrola selže využít první objekt k opravě dat
připomíná mi to situaci kdy z textu vytvořím AST (=první objekt) a pak ho proženu typovou kontrolou (vznikne druhý objekt)

[SB]

to není pravda, např. v Haskellu je možné definovat pro typ (např.) String "newtype" a následně "type class" určující jak je s ním možno pracovat, to že jej nikdo jiným neprohlédne se pak zajisté neexportováním konstruktoru z modulu
(ale pokud kriticky záleží na formátu řetězce, tak by ta hodnota neměla být vyjádřena řetězcem )

V pořádku, v Haskellu i jinde to funguje, je to jen otázkou deklarace, já jsem narážel na argumenty takových, kteří považují omezení na String za dostatečnou kontrolu správnosti dat.

[PeVa]

A) také nepotřebuje getry/setry. Pokud potřebuji mít možnost třínohého psa, ošetřím to v konstruktoru, resp. tuto kontrolu mohu vypustit. Pokud však čtyřnohému psu budu chtít nohu amputovat, místo setteru provedu chirurgický zákrok. Tedy pokud urizniNohu() nepovažuješ za setter.

Nohu neamputuješ, ty máš už nažačátku psa, kterej má 3 nohy.

Podobý pohled můžeš mít samozřejmě na většinu vlastností, takže vlastně kladeš jen minimální podmínky na konzistenci vntiřních stavů.

Je pes bez osacu, nohou i bez srdce ještě pes....? Z genetického i programátorského poledu ano...Neboť i takového psa mohu jako programátor oživit. A pokud to neumím dnes....mohu to umět za 2 roky.....v dalším releasu.

[PeVa]

Já se tu jinak nechci přít jestli A) ne B je správně...Jen jsem chtěl uvést, že jsou zde 2 koncepty jak k problémům přistupovat.
Při A) kladu podmínky na konzistenci stavů...a getry a setry mají velkou důležistost. Při B) je to na opak....I v aplikaci mám 2 typy různých objektů. Tam kde je pod kontrolou celý životní cyklus, je A) určitě správně tam, kde nemám toto pod kontrolou, pak je lepší asi B.

[Kit]

B) je sice pracnější, ale za to názorné a dokumentuje nutné předpoklady pro úspěšné zvládnutí funkcionality-činnosti. Když se nějakej mimozemšťan zeptá, k čemu ten pes vlastně nohy potřebuje, a jaké musí být, tak je to hned jasné. Podobně je to s ocasem a ušima.

Ano v tvém kontextu při A) se situace zjednodušší, nicméně jsi jen přenesl zodpovědnost za řešení nekonzistence vně.
Nekonzistenci tak jako tak někdo musí nakonec vyřešit. Jak ji chceš ale vyřešit, když nemužes vytvořit ani psa, že?

Otázkou je, co je to konzistence. Řekněme, že u psa máme atributy jméno a počet nohou. Konzistenci můžeme definovat jako objekt bez atributů, s povinným atributem jméno nebo s povinnými oběma atributy. Pokud jsou povinné oba atributy a jeden z nich není zadán, konstruktor může problém vyřešit za mne (pes má obvykle 4 nohy, dosadí default) nebo odmítne takový objekt vytvořit a výjimkou přesunu řešení nekonzistence vně (odmítne zaevidovat psa, který nemá jméno).

[SB]

Ve stavu se nešťouráte cizími funkcemi - jsou to funkce z toho modulu.

O pár přízpěvků zpět někdo psal, že to může být jakákoliv funkce, nejenom z modulu. Možná jsem to jen nepochopil.

Nejde.

V pořádku, to jsem chtěl ale vědět hned.

Nerozumím. Vždyť i v OOP mohu metodám předat/poslat jiný objekt.

Objekt ano, ale k jeho datům se nedostanete (když to nebude explicitně chtít).

Podobně jako máte virtuální metody, můžete mít i virtuální třídy...

Popravdě už si nepamatuju, co je virtuální třída. Virtuální metoda je omrdávka vymyšlená v hybridních jazycích, aby nemuseli za běhu řešit method dispatch.

...typy ve třídách dávají dobrý smysl. Viz třeba OO jazyky BETA nebo Scala.

K čemu jsou dobré?

Obecně typy ve třídách zvyšují vyjadřovací schopnosti jazyka

...a komplikují jeho sémantiku (vyžadují rozdílné, imperativní zpracování).