Funkcionální jazyky.

[gamer]

Kit nepotřebuje Getter na zjištění barvy psa. Vytvoří si singleton factory, která dostane instanci psa a z databáze si vytáhne jeho barvu. Může to být krásně polymorfní, protože stejná metoda může jednou dostat psa a podruhé kočku. Dovnitř hodí nějaké mutexy, aby to bylo thread safe. Ukol byl splněn, škaredý Getter je pryč.

[Reklama]

[Mirek Prýmek]

Problémem getterů a setterů je, že nejsou polymorfní. Pokud budu mít ve třídě Article metodu setTitle(), tak taková metoda se mi vůbec nehodí ve třídě Person či Store. Nemohu tedy použít stejné rozhraní.

Možná je to tím, že se OOP už delší dobu vyhýbám, ale tohle jsem teda vůbec nepochopil. Atricle, Person a Store by měli mít nějaké společné rozhraní? Jaké? Co mají společného? A jak ve vytvoření takového rozhraní vadí gettery/settery? Ne že bych to téma chtěl přiživovat, ale tohle konkrétně by mě zajímalo.

[BoneFlute]

Getter a setter jsou běžné metody objektu. Zakázat možnost z venku měnit členské proměnné přímo a donutit místo toho volat nějakou metodu je hlavní způsob jak udržet objekt v konzistentním stavu.
Jiná možnost je neustále při každé změně vyrábět novou instanci a řešit to v konstruktoru, to ale není vůbec praktické.

Problémem getterů a setterů je, že nejsou polymorfní. Pokud budu mít ve třídě Article metodu setTitle(), tak taková metoda se mi vůbec nehodí ve třídě Person či Store. Nemohu tedy použít stejné rozhraní.

Což je jedině žádoucí. Article není Person, natož Store. Nejen, že nemůžeš použít stejné rozhranní, ale ani by tě to nemělo napadnout.

Psa se ptáš kolik má blech a zda má obojek nebo nemá. Štěkat zvládne sám.

Hmm. A co mi ten pes odpoví na otázku, kolik má blech, když neumí mluvit?

Sorry, ale to je demagogie nejhlubšího zrna. Chápu to tedy správně, že uznáváš, že máme pravdu? :-)

[Kit]

[je dobré připomenout, že celý LISP je možné vytvořit jen ze čtyř funkcí a tří speciálních forem, to se potom polepí dohromady makry ]

To je jistě zábavné a rozumím Vám, ale v praxi se tento přístup neosvědčil, nýbrž čas od času se vezme oblíbená sada takovýchto maker a přetaví se do nového jazyka.

Osvědčil. Pouze pokud některé potřebné funkce vycházejí pomalé nebo je potřebné vytvořit ovladač pro nějaký HW, tak se přidají v C a stanou se součástí speciální verze Lispu pro nějaký konkrétní účel.

[Kid]

Problémem getterů a setterů je, že nejsou polymorfní. Pokud budu mít ve třídě Article metodu setTitle(), tak taková metoda se mi vůbec nehodí ve třídě Person či Store. Nemohu tedy použít stejné rozhraní.

Když jsou getter a setter normální metody, mohou (částečně) být virtuální/polymorfní. Minimálně můžete mít setTitle(string value) i setTitle(string value, int color) a můžete to v potomku přepsat jinak. Že je Vám setTitle v Person a Store k ničemu je v pořádku.

Hmm. A co mi ten pes odpoví na otázku, kolik má blech, když neumí mluvit? Proč bych se ho měl ptát, zda má obojek? To mi přece k ničemu není. Prostě ho připnu na vodítko. Pokud nemá obojek, vyhodí výjimku.

Nepotřebuji aby pes mluvil, potřebuji vědět jak moc akutní je shánět šampon na blechy. Na připínání vodítka bych ho napřed musel mít, půjdu tedy ke skříni a budu se ptát skříně zda k ní jde připnout obojek ? Ne nebudu, psa se zeptám zda má obojek a skříně se zeptám zda obsahuje vodítko.

[Reklama]

[Kit]

Atricle, Person a Store by měli mít nějaké společné rozhraní? Jaké? Co mají společného? A jak ve vytvoření takového rozhraní vadí gettery/settery? Ne že bych to téma chtěl přiživovat, ale tohle konkrétně by mě zajímalo.

Například mohou sdílet rozhraní Presentable, což může nahradit všechny gettery jedinou metodou. Volající pak nemusí vůbec zkoumat, jak se ta metoda u konkrétní třídy jmenuje, ale použije vždy stejný název metody presentate(). Samozřejmě tohle použiji pouze pokud mi z nějakého důvodu nevyhovuje standardní metoda toString().

Ale už toho vážně nechávám, věnujme se funkcionálním jazykům.

[gamer]

Například mohou sdílet rozhraní Presentable, což může nahradit všechny gettery jedinou metodou. Volající pak nemusí vůbec zkoumat, jak se ta metoda u konkrétní třídy jmenuje, ale použije vždy stejný název metody presentate(). Samozřejmě tohle použiji pouze pokud mi z nějakého důvodu nevyhovuje standardní metoda toString().

Tak jistě, pes, auto, kosmická loď nebo špinavé spoďáry můžou mít společné rozhraní presentable. Bohužel už nevidíš nebo nechceš vidět, že je to návrh od základů špatný a řešení s gettery mnohem čistější.

[Kid]

Například mohou sdílet rozhraní Presentable

gettery a settery nějak zabraňují těmto třídám sdílet rozhraní Presentable a mít metodu presentate() ?

[Mirek Prýmek]

gettery a settery nějak zabraňují těmto třídám sdílet rozhraní Presentable a mít metodu presentate() ?

Přesně tohle právě nechápu. Stejně jako mám společný toString, tak můžu mít společný toHTML a gettery s tím nemají vůbec nic společného (ledaže by Kit chtěl říct, že používat getter je zlo a že se musí vždycky pokud to jde použít toString,toHTML,presentate - s čím snad ale nikdo nepolemizuje).

[BoneFlute]

(ledaže by Kit chtěl říct, že používat getter je zlo a že se musí vždycky pokud to jde použít toString,toHTML,presentate - s čím snad ale nikdo nepolemizuje).

Jak zlo?

[Mirek Prýmek]

Jak zlo?

V tom smyslu, že když chci objekt odprezentovat v html, tak bych se ho neměl ptát na jeho properties a sám skládat prezentaci, ale měl bych ho nechat sama sebe odprezentovat. (Samozřejmě to neber doslovně, když mám třeba MVC, tak to tam bude třeba probíhat jinak, to je jasný. Každopádně nerozumím tomu, jak s tím gettery můžou souviset)

[Kid]

Přesně tohle právě nechápu. Stejně jako mám společný toString, tak můžu mít společný toHTML a gettery s tím nemají vůbec nic společného (ledaže by Kit chtěl říct, že používat getter je zlo a že se musí vždycky pokud to jde použít toString,toHTML,presentate - s čím snad ale nikdo nepolemizuje).

Asi tím chtěl vyjádřit, že getter a setter chce mít deklarován v nějakém společném předku, takže presentate je OK, setTitle ee protože je jenom na Article.

[BoneFlute]

Jak zlo?

V tom smyslu, že když chci objekt odprezentovat v html, tak bych se ho neměl ptát na jeho properties a sám skládat prezentaci, ale měl bych ho nechat sama sebe odprezentovat. (Samozřejmě to neber doslovně, když mám třeba MVC, tak to tam bude třeba probíhat jinak, to je jasný. Každopádně nerozumím tomu, jak s tím gettery můžou souviset)

A když budu chtít, aby se mi ten objekt prezentoval v json, xml, pdf, ...?
Imho mi to s těmi gettery souvisí dost těsně, protože na to presentování budu používat nějaký jiný nástroj, kterému ten objekt předhodím. A ten bude reflexi toho objektu dělat pomocí getterů.

[Mirek Prýmek]

Říkám, nejsem žádný odborník na OOP, ber to tak pls.

A když budu chtít, aby se mi ten objekt prezentoval v json, xml, pdf, ...?

No tak budeš muset mít další protokoly (interfaces) s metodami  toJSON, toXML, toPDF.

Imho mi to s těmi gettery souvisí dost těsně, protože na to presentování budu používat nějaký jiný nástroj, kterému ten objekt předhodím. A ten bude reflexi toho objektu dělat pomocí getterů.

To nejde napsat obecně. Nevím, jak bys mohl zobrazovat libovolný neznámý objekt. Leda přes nějaké rozhraní typu Person, kde budeš mít jistotu, že daný objekt umí odevzdat jméno, příjmení, adresu apod. a ty nějak zobrazíš. Ale to už není klasický getter, to je datové rozhraní.

Ale nehledej v tom žádnou vědu, prostě jsem chtěl říct, že otázka, jestli mám nebo nemá gettery nijak neovlivňuje otázku, jestli objekt splňuje nebo nesplňuje nějaký interface typu IsHTMLPresentable.

[BoneFlute]

Říkám, nejsem žádný odborník na OOP, ber to tak pls.

Beru neboj.

A když budu chtít, aby se mi ten objekt prezentoval v json, xml, pdf, ...?

No tak budeš muset mít další protokoly (interfaces) s metodami  toJSON, toXML, toPDF.

Upravování existujícího kódu. To není dobře.

Imho mi to s těmi gettery souvisí dost těsně, protože na to presentování budu používat nějaký jiný nástroj, kterému ten objekt předhodím. A ten bude reflexi toho objektu dělat pomocí getterů.

To nejde napsat obecně. Nevím, jak bys mohl zobrazovat libovolný neznámý objekt. Leda přes nějaké rozhraní typu Person, kde budeš mít jistotu, že daný objekt umí odevzdat jméno, příjmení, adresu apod. a ty nějak zobrazíš. Ale to už není klasický getter, to je datové rozhraní.

Ale nehledej v tom žádnou vědu, prostě jsem chtěl říct, že otázka, jestli mám nebo nemá gettery nijak neovlivňuje otázku, jestli objekt splňuje nebo nesplňuje nějaký interface typu IsHTMLPresentable.

Já bych to udělal pomocí tří rozhraní:
1. Entry -  obsahuje vlastní objekt.
2. Formater - objekt získávající Entry a výsledek bude stream/string
3. Dump - objekt zastřešující vytisknutí libovolného objektu.

Takže třeba: objekt DumpJSON nakrmím formatery, a pak když budu chtít vytisknout Psa, tak se použije PesFormaterJSON.