Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Lucas 16. 10. 2014, 18:05:13
-
Zdravím. Nemůžu se dopátrat jednoslovného anglického termínu označujícího gettery i settery zároveň. Napadá vás něco? Stačí, když to bude odpovídat aspoň vzdáleně.
-
Zdravím. Nemůžu se dopátrat jednoslovného anglického termínu označujícího gettery i settery zároveň. Napadá vás něco? Stačí, když to bude odpovídat aspoň vzdáleně.
Accessor. Viz: "Getter and setter methods (also known as accessors)" z článku http://www.javaworld.com/article/2073723/core-java/why-getter-and-setter-methods-are-evil.html (http://www.javaworld.com/article/2073723/core-java/why-getter-and-setter-methods-are-evil.html)
-
Tohle chápu tak, že getter je accessor setter je mutator. Já potřebuju nějaký zastřešující termín pro oba druhy.
-
Ještě je třetí typ: predikát.
Se všemi třemi typy přístupových metod je nutné náležitě šetřit. Nepoužívám je prakticky vůbec, zpravidla jsou nežádoucí.
-
Díky za sdělení, ale na můj dotaz to absolutně neodpovídá :-) I tak díky za snahu. Zatím asi skončím u označení modifiers, což není úplně ideální(může se to plést s access modifiers), ale aspoň něco. Pokud má někdo lepší nápad, tak sem s ním.
-
Opravdu se používá výraz accessor pro oba. Jak getter, tak setter.
-
Na většině míst se uvádí, že accessor slouží pro čtení, mutator pro změnu hodnoty. I podle těch názvů to zní celkem logicky. Navíc to chápu tak, že getter je accessor a setter je mutator, ale obráceně už to platit nemusí - záleží na tom, jestli se v nich pracuje s vlastnostmi objektu.
-
Jmenuje se to anglicky "accessor" oboje.
http://www.javaworld.com/article/2073723/core-java/why-getter-and-setter-methods-are-evil.html[/url]
Hlupák, nutno ignorovat, property/getter/setter jsou jedním ze základů OOP.
-
Hlupák, nutno ignorovat, property/getter/setter jsou jedním ze základů OOP.
Citation needed.
Veřejné property/getter/setter narušují zapouzdření objektů, proto do OOP nepatří.
-
Gettery/settery jsou tady právě kvůli zapouzdření, abys k vlastnostem mohl přistupovat nepřímo. Každopádně OOP mám momentálně na háku, jedná se totiž o settery/gettery datových atributů v DOM ;-)
-
Babica jede 8)
-
Veřejné property/getter/setter narušují zapouzdření objektů.
Nic takového se neděje, property/getter/setter jsou převlečené metody a podobně jako v jakékoliv jiné metodě se stane jen a pouze to co programátor dovolí. Když si hlupák ze zmíněného odkazu nedokáže představit jiný setter než pouhé přiřazení do členské proměnné, tak to je čistě jeho soukromý problém.
-
vzhledem k tomu, ze neni konsenzualni definice, tak mas volnou ruku. misto toho, aby si ji natahoval jak nuzak a cekal, az ti do ni nekdo vlozi hotovou definici, tak ji muzes pouzit k vytvoreni nove definice. pokud ji dostatecne zpropagujes a zprofanujes jako dalsi buzz(erant) word, tak se najde urcite dostatek ovci, co ji pro tebe vybeci napric oborem.
-
jinak prave s tim mutatorem si narazil na absurditu oboru. protoze mutator je prehistoricky termin a pouzit ho ve spojeni s javou znamena neprojit pohovorem jako jester co zna oop z doby predjavove (visual basic, object pascal, ...), tedy nepouzitelne se vsemi skodlivymi zlozvyky z ostatnich jazyku.
-
Díky za přátelské varování. Problém je ale jednak v tom, že neprogramuju v Javě a druhak v tom, že pohovor bych vedl já. Jinak začíná to tady být silně nekonstruktivní, já se loučím.
-
To je mi zase demagogie.
property/getter/setter jsou jedním ze základů OOP.
Nejsou. OOP nijak nesouvisí od get/setterů.
Veřejné property/getter/setter narušují zapouzdření objektů...
Zevšeobecňující tvrzení.
Pokud bychom přihlédli k praxy, kdy mnoho programátorů bez přemýšlení vytvoří třídu a na každou property nafrká setter, tak máš pravdu.
Pokud bychom ale uvažovali teoreticky, tak getter a setter je zcela regulérní metodika, která z principu žádné OOP nenarušuje.
-
To je mi zase demagogie.
Nejsou. OOP nijak nesouvisí od get/setterů.
Tedy princip zapouzdření a s tím související potřeba get/setterů taktéž nesouvisí s OOP ?
-
Tedy princip zapouzdření a s tím související potřeba get/setterů taktéž nesouvisí s OOP ?
Potřeba getterů/setterů nijak nesouvisí s principem zapouzdření. Gettery/settery zapouzdření totiž neřeší, ale pouze maskují.
-
To je mi zase demagogie.
Nejsou. OOP nijak nesouvisí od get/setterů.
Tedy princip zapouzdření a s tím související potřeba get/setterů taktéž nesouvisí s OOP ?
Princip zapouzdření souvisí s OOP. O tom, zda s tím souvisí či nesouvisí potřeba čehokoliv, můžete vést diskuse.
-
Potřeba getterů/setterů nijak nesouvisí s principem zapouzdření. Gettery/settery zapouzdření totiž neřeší, ale pouze maskují.
@Kite, když jsme tu tak krásně rozjeli offtopic, mohl by jsi mi někde na něčem demonstrovat tvou ideální představu koexistence objektů s dle tebe patřičným zapouzdřením? Nejlépe ne database, ale nějaký java-like, klidně pseudo kód. Ideálně nějakou transformaci vstupních dat na výstupní (bez implementačních detajlů). Opravdu by mě to zajímalo.
-
A když nemáte cibuli, tak ji tam vůbec nedávejte.
-
A když nemáte cibuli, tak ji tam vůbec nedávejte.
Kdo nemá cibuli, dá vocet. A kdo nemá vocet, dá kyselinu sírovou. ;D
-
Veřejné property/getter/setter narušují zapouzdření objektů, proto do OOP nepatří.
Pouzi privatne gettery a settery :P.
Vazne: gettery su uplne v pohode napriklad u objektov, ktore su len strukturami drziacimi data. Ze objekt Clovek ma mat meno a priezvisko, na to netreba velke znalosti. Cpat do neho nejake zobrazenie mena a priezviska uzivatelovi, to si koleduje o problem.
-
Jak už tady padlo, pokud si někdo nedokáže představit jiný, než holý setter bez jakýchkoliv kontrol a nejlíp úplně všude, tak to zapouzdření opravdu moc nepomůže. Od toho je to ale metoda, aby si v ní programátor mohl nebezpečná přiřazení náležitě ošetřit. Ostatně bych to s tou ideologickou čistotou nepřeháněl, bývá to často kontraproduktivní. Jsou tady i jazyky, které se s nějakým zapouzdřením neserou vůbec a překvapivě to funguje taky.
-
Vazne: gettery su uplne v pohode napriklad u objektov, ktore su len strukturami drziacimi data. Ze objekt Clovek ma mat meno a priezvisko, na to netreba velke znalosti. Cpat do neho nejake zobrazenie mena a priezviska uzivatelovi, to si koleduje o problem.
U takových objektů nemá cenu ty data dávat jako private. To zapouzdřejí je k ničemu, protože se vnitřek stejně moc překopat nedá. Leda tak pokud potřebuju držet nějaké invarianty a v setteru je kontroluju.
-
Hlupák, nutno ignorovat, property/getter/setter jsou jedním ze základů OOP.
Citation needed.
Veřejné property/getter/setter narušují zapouzdření objektů, proto do OOP nepatří.
Prepac, ale to je nezmysel. Ako chces za behu upravovat vlastnosti objektu, ked k nim nedas pristup? Urobis to v ramci metody, ktora vykonava aj nieco ine? Nie, lebo porusis pravidlo o atomickosti metod.
Nechapem na co ti je objekt, ktory zapuzdris natolko, ze s jeho vlastnostami nebudes schopny pracovat.
-
Veřejné property/getter/setter narušují zapouzdření objektů, proto do OOP nepatří.
Prepac, ale to je nezmysel. Ako chces za behu upravovat vlastnosti objektu, ked k nim nedas pristup? Urobis to v ramci metody, ktora vykonava aj nieco ine? Nie, lebo porusis pravidlo o atomickosti metod.
Nechapem na co ti je objekt, ktory zapuzdris natolko, ze s jeho vlastnostami nebudes schopny pracovat.
Nepracuji přece s vlastnostmi objektu, ale objektu posílám zprávy. Je na rozhodnutí metody objektu, co s tou zprávou udělá. Vně objektu nemá být vidět informace o jeho vnitřní struktuře. Má být vidět pouze rozhraní. Pokud dva objekty mají uvnitř různé atributy, ale mají stejné rozhraní, mohu použít polymorfismus. Pokud by měly pouze gettery a settery na různé atributy, polymorfismus použít nemohu.
-
Já bych jako možný termín pro gettery/settery použil property. Takže to jsou vlastně property objektu, buď jsou měnitelné a nebo ne. Třeba v Qt v C++ je možné definovat Q_PROPERTY která má typ a jméno jako proměnná a je možné je navázat buď přímo na proměnnou a nebo taky na getter a setter a ještě přidat notify event při změně. Stejně tak v C# se property implementují s get a set, takže to má tomu nejblíže.
Jinak, gettery/settery/property mají hlavně ten význam, že oddělují implementaci od rozhraní, takže klient objektu neví jestli je ta properta jen členskou proměnnou, je nějak počítána, jestli je permanentně v paměti a nebo je při get načtena z disku a podobně. Setter má potom taky tu výhodu, že pokud na té propertě závisí hodnota jiných propert a z nějakého důvodu je nechceme v getteru pokaždé počítat znova, tak při setu je můžeme přepočítat. Třeba poloměr kruhu a jeho obvod, jsou na sobě závislé a pokud máme čtvercové pole takových objektů nad kterým se třeba provádí nějaká simulace, tak nechceme pokaždé počítat jedno z druhého, jenom když se něco změní tak přepočítáme to druhé. Takže settery jsou právě od toho, aby se daly přepočítat závislé proměnné. Samozřejmě, že property jsou normální rozhraní a jejich vystvením riskujeme konsekvence, ale efekty lze minimalizovat vytvořením lokálních propert, právě proto aby když něco změníme ať máme jistotu že se všechno ostatní na tom závislé přepočítá. Další výhodou je že pokud v předkovi jsou jenom property k členské proměnné která je private, tak potomek nemůže k ní přistupovat jinak než přes ně, čímž lze zajistit že pokud se přidá nová členská proměnná která na ní závisí tak není třeba měnit kód zděděné třídy, obvykle. Jinak pozor, kromě design rizika tu hrozí, ehm, i zacyklení v kruhu. Na to třeba dávat bacha...!
Jak moc je to proti OO bych neřešil, on i takový active record design pattern obalující tabulku v databázi je z velké míry proti OOP, mezitím co řádky tabulky mohou mít různý typ a měly by z nich být různé typy objektů, tak v reálu se načte kolekce active recordů a ty mají property pro každý sloupek tabulky. A přitom je active record jeden z nejpoužívanejších patternů pro ORM...
-
Veřejné property/getter/setter narušují zapouzdření objektů, proto do OOP nepatří.
Prepac, ale to je nezmysel. Ako chces za behu upravovat vlastnosti objektu, ked k nim nedas pristup? Urobis to v ramci metody, ktora vykonava aj nieco ine? Nie, lebo porusis pravidlo o atomickosti metod.
Nechapem na co ti je objekt, ktory zapuzdris natolko, ze s jeho vlastnostami nebudes schopny pracovat.
Nepracuji přece s vlastnostmi objektu, ale objektu posílám zprávy. Je na rozhodnutí metody objektu, co s tou zprávou udělá. Vně objektu nemá být vidět informace o jeho vnitřní struktuře. Má být vidět pouze rozhraní. Pokud dva objekty mají uvnitř různé atributy, ale mají stejné rozhraní, mohu použít polymorfismus. Pokud by měly pouze gettery a settery na různé atributy, polymorfismus použít nemohu.
A ta metoda, ktora prijme spravu a podla nej zmeni vlastnost objektu nie je nahodou setter? ;) Setter nemusi IBA menit hodnotu a dokonca sa jeho nazov ani nemusi zacinat slovom set.
-
Nepracuji přece s vlastnostmi objektu, ale objektu posílám zprávy. Je na rozhodnutí metody objektu, co s tou zprávou udělá. Vně objektu nemá být vidět informace o jeho vnitřní struktuře. Má být vidět pouze rozhraní. Pokud dva objekty mají uvnitř různé atributy, ale mají stejné rozhraní, mohu použít polymorfismus. Pokud by měly pouze gettery a settery na různé atributy, polymorfismus použít nemohu.
A ta metoda, ktora prijme spravu a podla nej zmeni vlastnost objektu nie je nahodou setter? ;) Setter nemusi IBA menit hodnotu a dokonca sa jeho nazov ani nemusi zacinat slovom set.
Zkus nějakému programátorovi říct, že tam má dát setter. Automaticky napíše setProperty() a k tomu primitivní řádek this.property = property. Vím, že to není jediný typ setteru, ale vidím ho v cizích programech až příliš často. A nelíbí se mi.
Pokud název metody nezačíná slůvkem "set", tak se jí většinou setter neříká. Když něco přidáváš do kolekce metodou add() nebo insert(), říkáš jim settery?
-
C# tomu rika property, Common Lisp tomu rika accessor. Tak si vyberte.
Nekdy me ale Javisti vazne bavi.. Takze mame dva objekty, A a B, a mezi nimi je vazba, a to se nam nelibi, protoze je to obtizne spravovatelne; kdyz se nejak zmeni A, bude se muset zmenit i B. Jak to vyresit? No, v OOP mame objekty, takze vytvorime dalsi objekt C, ktery ma vazbu na A i B. Tim padem, pokud se zmeni A, nebo se zmeni B, bude stacit zmenit jen objekt C. Problem ovsem ted je, ze nam zde stale zustala vazba mezi A a C, a vazba mezi B a C. To lze samozrejme dale vyresit, jak jinak nez pridanim objektu D a E..
-
Nepracuji přece s vlastnostmi objektu, ale objektu posílám zprávy. Je na rozhodnutí metody objektu, co s tou zprávou udělá.
Objektům ve smyslu OOP se nikdy žádné zprávy neposílaly, neposílají a nikdy posílat nebudou. Nevím jak dlouho bude trvat než se tento nesmysl vymýtí. Použití metody objektu funguje naprosto stejně jako volání volání funkce.
Vně objektu nemá být vidět informace o jeho vnitřní struktuře. Má být vidět pouze rozhraní. Pokud dva objekty mají uvnitř různé atributy, ale mají stejné rozhraní, mohu použít polymorfismus. Pokud by měly pouze gettery a settery na různé atributy, polymorfismus použít nemohu.
getter/setter může a nemusí mít souvislost s vnitřní strukturou, právě proto gettery/settery existují.
Solidní jazyk umí getter/setter jako virtuální metodu a můžeš si to v potomkovi přepsat libovolně.
Zkus nějakému programátorovi říct, že tam má dát setter. Automaticky napíše setProperty() a k tomu primitivní řádek this.property = property.
Takový setter je k ničemu, to se shodneme, to se klidně může členská proměnná vystrčit do sekce public a vyjde to skoro nastejno.
-
Nepracuji přece s vlastnostmi objektu, ale objektu posílám zprávy. Je na rozhodnutí metody objektu, co s tou zprávou udělá. Vně objektu nemá být vidět informace o jeho vnitřní struktuře. Má být vidět pouze rozhraní. Pokud dva objekty mají uvnitř různé atributy, ale mají stejné rozhraní, mohu použít polymorfismus. Pokud by měly pouze gettery a settery na různé atributy, polymorfismus použít nemohu.
A ta metoda, ktora prijme spravu a podla nej zmeni vlastnost objektu nie je nahodou setter? ;) Setter nemusi IBA menit hodnotu a dokonca sa jeho nazov ani nemusi zacinat slovom set.
Zkus nějakému programátorovi říct, že tam má dát setter. Automaticky napíše setProperty() a k tomu primitivní řádek this.property = property. Vím, že to není jediný typ setteru, ale vidím ho v cizích programech až příliš často. A nelíbí se mi.
Pokud název metody nezačíná slůvkem "set", tak se jí většinou setter neříká. Když něco přidáváš do kolekce metodou add() nebo insert(), říkáš jim settery?
Ja som sa ti snazil tym povedat, ze aj ked to nenazves set*, tak je to setter pokial to priradzuje vlastnosti hodnotu. Teda aj ta tvoja metoda, ktora prijima spravu a podla nej nastavuje hodnotu, je setter.
Metodu neurobi setterom slovo "set" v jej nazve, ale to co vykonava jej telo.
-
Metodu neurobi setterom slovo "set" v jej nazve, ale to co vykonava jej telo.
Zalezi na implemantacii v konkrétnom jazyku, nemozete to zhrnut na jeden konkretny jazyk.
-
Já bych jako možný termín pro gettery/settery použil property.
C# tomu rika property, Common Lisp tomu rika accessor. Tak si vyberte.
Property se mi nelíbí, je to až moc obecné. Nakonec jsem se rozhodl použít accessors. To taky není ideální, ale je to asi nejsrozumitelnější. V tomhle ohledu se stejně na terminologii většina neshodne, záleží mi ale na tom, aby byla na první pohled srozumitelná pro co nejširší okruh lidí. Lidem vyjadřujícím se k věci díky, za mě to je definitivně všechno. Můžete nerušeně pokračovat ve flame.
-
Jinak, gettery/settery/property mají hlavně ten význam, že oddělují implementaci od rozhraní, takže klient objektu neví jestli je ta properta jen členskou proměnnou, je nějak počítána, jestli je permanentně v paměti a nebo je při get načtena z disku a podobně.
To je asi jedine legitimni pouziti. Bohuzel to cele stoji a pada s tim, ze se pristup k promennym (atributum) zapisuje syntakticky stejne jako volani funkci, coz ma jen malo jazyku (treba Common Lisp nebo Haskell). V Jave a C# to tak uplne neni (C# je v tomhle ale trochu lepsi), takze proto mnoho lidi ze zoufalstvi trva na tom, aby se z toho vzdy delaly funkce, aby vubec tu vyhodu bylo mozne potencialne vyuzit. Uzitecnost takove praktiky je ovsem sporna, uz proto, ze porusuje princip YAGNI.
-
Objektům ve smyslu OOP se nikdy žádné zprávy neposílaly, neposílají a nikdy posílat nebudou. Nevím jak dlouho bude trvat než se tento nesmysl vymýtí. Použití metody objektu funguje naprosto stejně jako volání volání funkce.
Právě naopak. OOP je o tom, že se objektům zasílají zprávy a objekty na ně nějak reagují (převážně voláním metody, ale volající netuší které). Smalltalk snad není objektový jazyk? A to zasílání zpráv je dobrá představa i u mainstream jazyků. Co takový COM nebo CORBA?
Chápu, že většina programátorů ani netuší, že volání metod v C++/Javě/C#/... je jen osekaná verze obecnějšího principu. Vlastně je to taková konkrétní implementace místo obecnějšího popisu chování. :D
-
Objektům ve smyslu OOP se nikdy žádné zprávy neposílaly, neposílají a nikdy posílat nebudou. Nevím jak dlouho bude trvat než se tento nesmysl vymýtí. Použití metody objektu funguje naprosto stejně jako volání volání funkce.
Nekdy mam problem rozhodnout se, zda verit anonymnimu Kolemjdoucimu nebo Alanu Kayovi. Ne.
-
Metodu neurobi setterom slovo "set" v jej nazve, ale to co vykonava jej telo.
Zalezi na implemantacii v konkrétnom jazyku, nemozete to zhrnut na jeden konkretny jazyk.
Preco? Ako sa napriklad tento princip uplatneny v PHP lisi od tohto principu uplatneneho v Jave? V oboch jazykoch predsa plati, ze setter je metoda, ktora nastavuje hodnotu a nie metoda, ktorej nazov sa zacina na set*.
-
Objektům ve smyslu OOP se nikdy žádné zprávy neposílaly, neposílají a nikdy posílat nebudou. Nevím jak dlouho bude trvat než se tento nesmysl vymýtí. Použití metody objektu funguje naprosto stejně jako volání volání funkce.
Nekdy mam problem rozhodnout se, zda verit anonymnimu Kolemjdoucimu nebo Alanu Kayovi. Ne.
Kludne nech sa objektom posielaju spravy. Ale urcite je nezmysel, ze s objektom sa komunikuje LEN prostrednictvom sprav.
-
C# tomu rika property, Common Lisp tomu rika accessor. Tak si vyberte.
Nekdy me ale Javisti vazne bavi.. Takze mame dva objekty, A a B, a mezi nimi je vazba, a to se nam nelibi, protoze je to obtizne spravovatelne; kdyz se nejak zmeni A, bude se muset zmenit i B. Jak to vyresit? No, v OOP mame objekty, takze vytvorime dalsi objekt C, ktery ma vazbu na A i B. Tim padem, pokud se zmeni A, nebo se zmeni B, bude stacit zmenit jen objekt C. Problem ovsem ted je, ze nam zde stale zustala vazba mezi A a C, a vazba mezi B a C. To lze samozrejme dale vyresit, jak jinak nez pridanim objektu D a E..
Hodne zalezi na okolnostech (vlastnictvi kodu, pozadavky na kompatibility, buildsystem...). Ale casto je dobre resni mit interface IA, B nechat pouzivat jen IA misto A a na jich propojeni pouzit IOC. Pak te nejake rozumne zmeny v A nerozhazi.
-
Kludne nech sa objektom posielaju spravy. Ale urcite je nezmysel, ze s objektom sa komunikuje LEN prostrednictvom sprav.
Hmmm, proč? Takový smalltalk přesně tímhle způsobem funguje (a jeho problémy jsou úplně jinde, než v tomhle). Posílání "zprávy" o které objekt sám rozhoduje, co s ní udělá (např. pohledem do VFT) je obecnější popis toho, co se děje i při volání metody. Takový interface v javě, nebo abstraktní třída v C++ je jen popis zpráv, kterým objekt rozumí.
Ano, veřejné proměnné do tohohle pohledu moc nezapadají, ale na ty se dost OOP puristů kouká skoro jako na goto.
A zásadní zádrhel zpráv/metod není v ničem menším než že jen jeden objekt rozhoduje o tom, co se stane. S nadsázkou bych řekl, že tak polovina návrhových vzorů obchází tohle omezení pro různé specifické případy. Z toho taky plyne, že OOP se dobře hodí jen na určitou třídu úloh.
-
Právě naopak. OOP je o tom, že se objektům zasílají zprávy a objekty na ně nějak reagují (převážně voláním metody, ale volající netuší které). Smalltalk snad není objektový jazyk? A to zasílání zpráv je dobrá představa i u mainstream jazyků. Co takový COM nebo CORBA?
Objektům ve smyslu OOP prostě zpráva poslat nejde a to ani ve Smalltalku ani v COM, vždy je to volání metody která není nic jiného než převlečené volání funkce.
Nazývat si to ve svém soukromí můžete jak chcete, ale s reálným stavem světa to nemá nic společného. Jestliže chcete vaši vlastní metodu ZpracujZprávu(int message, ...) nazývat posílání zpráv pak samozřejmě můžete, nikdo vám v tom nebrání.
Takový interface v javě, nebo abstraktní třída v C++ je jen popis zpráv, kterým objekt rozumí.
Nesmysly.
-
Kludne nech sa objektom posielaju spravy. Ale urcite je nezmysel, ze s objektom sa komunikuje LEN prostrednictvom sprav.
Hmmm, proč? Takový smalltalk přesně tímhle způsobem funguje (a jeho problémy jsou úplně jinde, než v tomhle). Posílání "zprávy" o které objekt sám rozhoduje, co s ní udělá (např. pohledem do VFT) je obecnější popis toho, co se děje i při volání metody. Takový interface v javě, nebo abstraktní třída v C++ je jen popis zpráv, kterým objekt rozumí.
Ano, veřejné proměnné do tohohle pohledu moc nezapadají, ale na ty se dost OOP puristů kouká skoro jako na goto.
A zásadní zádrhel zpráv/metod není v ničem menším než že jen jeden objekt rozhoduje o tom, co se stane. S nadsázkou bych řekl, že tak polovina návrhových vzorů obchází tohle omezení pro různé specifické případy. Z toho taky plyne, že OOP se dobře hodí jen na určitou třídu úloh.
Co? Interface? Ake verejne premenne? Ale o tom vobec nie je rec.
Rec je o tom, ze s objektami sa nekomunikuje (=nevyberaju a nenastavuju sa vlastnosti objektu, v tomto kontexte) len vymienanim sprav, ale aj pomocou setterov a getterov a je nezmysel tvrdit, ze jediny spravny sposob je vymena sprav.
-
Objektům ve smyslu OOP prostě zpráva poslat nejde a to ani ve Smalltalku ...
http://www.inf.ufsc.br/poo/smalltalk/ibm/tutorial/chap2.html
Nazývat si to ve svém soukromí můžete jak chcete, ale s reálným stavem světa to nemá nic společného. Jestliže chcete vaši vlastní metodu ZpracujZprávu(int message, ...) nazývat posílání zpráv pak samozřejmě můžete, nikdo vám v tom nebrání.
Já to tak nenazývám ve svém soukromí. Minimálně u toho smalltalku jsou to běžně používané termíny.
Já samozřejmě vím, že to skončí voláním procedury, protože jinak se moc kód ani vykonávat nedá. To posílání zprávy ale považuju za velmi dobrou abstrakci, protože volající o té vlastní proceduře moc neví. Volající posílá požadavek a o tom, jak se ten požadavek obslouží, co za kód se vlastně zavolá je závislé na volaném objektu.
-
Ještě je třetí typ: predikát.
Se všemi třemi typy přístupových metod je nutné náležitě šetřit. Nepoužívám je prakticky vůbec, zpravidla jsou nežádoucí.
Prosím, vysvětlete mi, co tím básník myslel.
Mě naopak přijde jejich použití víc než žádoucí.
-
http://www.inf.ufsc.br/poo/smalltalk/ibm/tutorial/chap2.html
A Keyword message is equalvalent to a procedure call with two or more parameters :-)
Já samozřejmě vím, že to skončí voláním procedury, protože jinak se moc kód ani vykonávat nedá.
No výborně :-)
To posílání zprávy ale považuju za velmi dobrou abstrakci, protože volající o té vlastní proceduře moc neví.
A právě to zpracování zprávy je vždy nadstavba a není součástí OOP, ke zpracování zpráv není OOP potřeba.
-
Rec je o tom, ze s objektami sa nekomunikuje (=nevyberaju a nenastavuju sa vlastnosti objektu, v tomto kontexte) len vymienanim sprav, ale aj pomocou setterov a getterov a je nezmysel tvrdit, ze jediny spravny sposob je vymena sprav.
Ty zprávy jsou abstraktní pohled na to, co se vlastně děje. To, že nejsou implementované nějakou frontou zpráv ale přímým zavoláním metody je druhá věc.
objekt.setName("Pepa") může znamenat, že posílám zprávu "setName" s parametrem. Ta zpráva vlastně jen zdůrazňuje :
1) Jako volající netuším, jaký kód se bude volat a jestli vůbec. Pokud volající ví, jaký kód se vykoná, tak je zapouzdření pryč.
2) Po objektu požaduju nějakou rozumně zabalenou činnost, po které by měl zůstat v konzistentním stavu.
Pokud si nějaké volání nedokážu představit jako poslání zprávy s požadavkem, pak to beru jako náznak, že jsem něco navrhl blbě.
Prosím, vysvětlete mi, co tím básník myslel.
Mě naopak přijde jejich použití víc než žádoucí.
Pokud má objekt moc přístupových metod, pak to může znamenat, že nemá zodpovědnost za stav jeho dat on, ale volající kód. Pokud může volající nechat objekt v nekonzistentním stavu, pak není pořádně zapouzdřený.
-
A právě to zpracování zprávy je vždy nadstavba a není součástí OOP, ke zpracování zpráv není OOP potřeba.
Už tuším, kde si asi nerozumíme. To posílání zpráv je jen abstraktní pohled na to, že po objektu něco chci a kvůli zapouzdření je to ten objekt, kdo rozhoduje co se stane. Že se to dá implementovat bez nějakého opravdového posílání zpráv je druhá věc.
-
Objektům ve smyslu OOP prostě zpráva poslat nejde a to ani ve Smalltalku ani v COM, vždy je to volání metody která není nic jiného než převlečené volání funkce.
Ach jo. Nedovedu vyloucit, ze umis programovat, ale teorii OOP jsi proste nepolibeny (to by nebyla ostuda, nedelat tu ze sebe mistra sveta. Proste si sedni a zacni cist, trebaz zde zminovany Cada je pres jistou flemetvornost celkem obstojny zacatek).
Koncepcne je to tak, ze se posle zprava (at uz ta ma nebo nema fyzickou reprezentaci, coz je otazka okolnosti a optimalizaci) a pak se na zaklade pozdni vazby (mozna) zavola nejaka metoda. Nebo taky ne.
-
Abstraktní pohledy a koncepce mě nechávají tak nějak klidnými a žádné zprávy objektům se nikde neposílají a dosud jste neprokázali opak. Začíná mě to mírně nudit.
-
Ještě je třetí typ: predikát.
Se všemi třemi typy přístupových metod je nutné náležitě šetřit. Nepoužívám je prakticky vůbec, zpravidla jsou nežádoucí.
Prosím, vysvětlete mi, co tím básník myslel.
Mě naopak přijde jejich použití víc než žádoucí.
Ne, jsou _spise_ (zalezi na dalsim) nezadouci. Teda od urcite urovne dal, pokud je chces srovnat s tim, ze udelas par public fieldu bez jakekoli ochrany, tak jsou i acessory cesta vpred. Navic je rozdil mezi get a set, to druhe je daleko horsi (protoze implikuje mutabilitu).
Velmi jednoduchy priklad:
Chces udelat counter. Trebas pises takove to "mackatko", kterym se pocitaji lide jdouci na koncert nebo prujezd aut.
Kdyz mas private int count a k tomu getter a setter, tak ti klient zvysuje po pruchodu cloveka count nejakym counter.setCount(getCount() + 1). To neusychronizujes, nezabranis rozjebani stavu z venci... Pritom tam muzes mit metody getCount() a inc() a mas polovinu problemu.
(Jeste jednou zduraznuju - neni to 100% pravidlo, casto jsou acessory naprosto OK. Ale pouzivat opatrne. A set je urcite daleko nebezpecnejsi nez get. Opatrne i s getem, pokud ven pousti nejakou mutovatelnou vnitrni strukturu.)
-
Abstraktní pohledy a koncepce mě nechávají tak nějak klidnými a žádné zprávy objektům se nikde neposílají a dosud jste neprokázali opak. Začíná mě to mírně nudit.
To je ovsem ciste tvuj problem. Je tu nejaka teorie, vcelku bezne prijimana (a z docela dobrych duvodu) zbytekm sveta. Pokud ji ke sve praxi nepotrebujes, delej si svou praxi. Ale nevyjadruj se k tomu, co poradne neznas.
-
Takže důkaz že objektu jde poslat zpráva podat neumíte, jen kupíte slova. Nemám k tomu co dodat.
-
Takže důkaz že objektu jde poslat zpráva podat neumíte, jen kupíte slova. Nemám k tomu co dodat.
Ze ja vul se necham vzdycky zatahnout do diskuse s trolikem, misto abych si precetl neco od nekoho, kdo tematu rozumi (napriklad ten koncept vymyslel). Co trebas performSelector v ObjC? Nebo prakticky doslova v http://www.inf.ufsc.br/poo/smalltalk/ibm/tutorial/chap2.html#2.00
-
No já nevím, nic jako smalltalk se v reálu moc nepoužívá, všechny pracovní místa jsou o C# nebo Java, občas C++.
Obecně volání metody je jasnější než poslání správy, pod tím rozumím že by každý objekt měl svoji frontu zpráv kterou by spracovával v pořadí v jakém mu přišly a nejlépe by běžel ve vlastním vlákně (není ale nutné). Když pošlu objektu zprávu, nemám jistotu že zareaguje hned (je to vlastně asynchronní volání), kdežto když na něm zavolám metodu, tak vím že ani neopustím vlákno dokud ta nebude dokončena. V jistém smyslu lze na volání metod nahlížet jako na posílání zpráv, to ano, ale mnoho lidí to chápe jinak. Smalltalk je třeba "opravdové" OOP, ale to se v praxi neuchytilo, takže všechno jako C++/Java/C# si nese jisté břemeno procedurálnosti. Třída není objekt, primitivní datové typy nejsou objekty, šablony/generiky taky nejsou objekty a jde to dál. Pokud jsem napsal nějakou blbost, tak mě opravte :D
-
A mrdat češtin ;D
-
Rec je o tom, ze s objektami sa nekomunikuje (=nevyberaju a nenastavuju sa vlastnosti objektu, v tomto kontexte) len vymienanim sprav, ale aj pomocou setterov a getterov a je nezmysel tvrdit, ze jediny spravny sposob je vymena sprav.
Ty zprávy jsou abstraktní pohled na to, co se vlastně děje. To, že nejsou implementované nějakou frontou zpráv ale přímým zavoláním metody je druhá věc.
objekt.setName("Pepa") může znamenat, že posílám zprávu "setName" s parametrem. Ta zpráva vlastně jen zdůrazňuje :
1) Jako volající netuším, jaký kód se bude volat a jestli vůbec. Pokud volající ví, jaký kód se vykoná, tak je zapouzdření pryč.
2) Po objektu požaduju nějakou rozumně zabalenou činnost, po které by měl zůstat v konzistentním stavu.
Pokud si nějaké volání nedokážu představit jako poslání zprávy s požadavkem, pak to beru jako náznak, že jsem něco navrhl blbě.
Prosím, vysvětlete mi, co tím básník myslel.
Mě naopak přijde jejich použití víc než žádoucí.
Pokud má objekt moc přístupových metod, pak to může znamenat, že nemá zodpovědnost za stav jeho dat on, ale volající kód. Pokud může volající nechat objekt v nekonzistentním stavu, pak není pořádně zapouzdřený.
Takze je to normalny setter, len ho nazyvame spravou.
Lebo ked pouzijem setter, tak nemusim vediet co tento setter urobi. Neviem to, nepotrebujem to vediet. Jedine co ma zaujima je to, ze objektu nastavi meno na "Pepa". Toto jedine viem a toto nemoze ohrozit zapuzdrenie, pretoze ten setter volam s tymto ucelom.
A taktiez plati aj bod 2, pretoze je to uplne logicke.
Takze sprava = setter/getter.
-
Takže důkaz že objektu jde poslat zpráva podat neumíte, jen kupíte slova. Nemám k tomu co dodat.
A aby to bylo jeste o neco zrejmejsi [foo bar: baz] vazne neznamena, ze se nakonci na foo nejaka metoda bar zavola.
-
Obecně volání metody je jasnější než poslání správy, pod tím rozumím že by každý objekt měl svoji frontu zpráv kterou by spracovával v pořadí v jakém mu přišly a nejlépe by běžel ve vlastním vlákně (není ale nutné). Když pošlu objektu zprávu, nemám jistotu že zareaguje hned (je to vlastně asynchronní volání), kdežto když na něm zavolám metodu, tak vím že ani neopustím vlákno dokud ta nebude dokončena.
A u volání procedury je jistota, že zareaguje hned? Může si ten požadavek uložit do vnitřní fronty. Může to spustit v odděleném vlákně. Možností je spousta. U observerů se volání callbacků přenáší tímhle způsobem mezi vlákny celkem běžně. Tím, že o tom přemýšlím jako o poslání požadavku se mi daleko líp předvídají podobné divočiny.
V jistém smyslu lze na volání metod nahlížet jako na posílání zpráv, to ano, ale mnoho lidí to chápe jinak. Smalltalk je třeba "opravdové" OOP, ale to se v praxi neuchytilo, takže všechno jako C++/Java/C# si nese jisté břemeno procedurálnosti. Třída není objekt, primitivní datové typy nejsou objekty, šablony/generiky taky nejsou objekty a jde to dál. Pokud jsem napsal nějakou blbost, tak mě opravte :D
Objektové programování není o jazyce. Je to způsob přemýšlení a návrhu. Jazyk jen může pomoct s jednodušším zápisem některých obratů. Je to vidět na hybridních jazycích jako C++. Tam se dá programovat procedurálně, objektově nebo i funkcionálně.
-
Preco? Ako sa napriklad tento princip uplatneny v PHP lisi od tohto principu uplatneneho v Jave? V oboch jazykoch predsa plati, ze setter je metoda, ktora nastavuje hodnotu a nie metoda, ktorej nazov sa zacina na set*.
Pozri si napr. c#, tam je jasne co je getter a co setter.
-
Abstraktní pohledy a koncepce mě nechávají tak nějak klidnými a žádné zprávy objektům se nikde neposílají a dosud jste neprokázali opak. Začíná mě to mírně nudit.
Moje řeč! Nikdy jsem žádnou proceduru a už vůbec metodu neviděl. Všechno je to nakonec stejně nějaký CALL nějaké adresy v paměti a to je ve skutečnosti jen nějaký JUMP na nějakou adresu se zapamatováním návratové adresy. Podobně neexistují žádné datové typy, žádné proměnné, žádné smyčky - všechno to jsou jen čísla na nějakých adresách a přeskoky mezi různými částmi paměti.
OMG! Tohle mě vážně dostává. Malý, bezvýznamný čecháček zase vymýšlí p.čoviny a ještě si myslí, že je mistr světa a všichni kolem jsou úplní debilové, včetně těch, co dané koncepty vymysleli.
-
Abstraktní pohledy a koncepce mě nechávají tak nějak klidnými a žádné zprávy objektům se nikde neposílají a dosud jste neprokázali opak. Začíná mě to mírně nudit.
A co třeba Objective-C? Dokonce existuje i Objective-C++ :).
-
Abstraktní pohledy a koncepce mě nechávají tak nějak klidnými a žádné zprávy objektům se nikde neposílají a dosud jste neprokázali opak. Začíná mě to mírně nudit.
Moje řeč! Nikdy jsem žádnou proceduru a už vůbec metodu neviděl. Všechno je to nakonec stejně nějaký CALL nějaké adresy v paměti a to je ve skutečnosti jen nějaký JUMP na nějakou adresu se zapamatováním návratové adresy. Podobně neexistují žádné datové typy, žádné proměnné, žádné smyčky - všechno to jsou jen čísla na nějakých adresách a přeskoky mezi různými částmi paměti.
OMG! Tohle mě vážně dostává. Malý, bezvýznamný čecháček zase vymýšlí p.čoviny a ještě si myslí, že je mistr světa a všichni kolem jsou úplní debilové, včetně těch, co dané koncepty vymysleli.
Prej čísla, adresy! Tydlecty abstraktní konstrukce mi kór nechávaj klidným: sou to všechno stejně jenom ňáký fluktuace vákua, to mi nikdo nevymluví.
-
Turtles *) all way down.
*) communicating by messages
-
Abstraktní pohledy a koncepce mě nechávají tak nějak klidnými a žádné zprávy objektům se nikde neposílají a dosud jste neprokázali opak. Začíná mě to mírně nudit.
Moje řeč! Nikdy jsem žádnou proceduru a už vůbec metodu neviděl. Všechno je to nakonec stejně nějaký CALL nějaké adresy v paměti a to je ve skutečnosti jen nějaký JUMP na nějakou adresu se zapamatováním návratové adresy. Podobně neexistují žádné datové typy, žádné proměnné, žádné smyčky - všechno to jsou jen čísla na nějakých adresách a přeskoky mezi různými částmi paměti.
OMG! Tohle mě vážně dostává. Malý, bezvýznamný čecháček zase vymýšlí p.čoviny a ještě si myslí, že je mistr světa a všichni kolem jsou úplní debilové, včetně těch, co dané koncepty vymysleli.
Prej čísla, adresy! Tydlecty abstraktní konstrukce mi kór nechávaj klidným: sou to všechno stejně jenom ňáký fluktuace vákua, to mi nikdo nevymluví.
nejftipnejsi na tom je, ze si tady ty fluktuace vakua pomeruji svoje fluktuanty.
-
A jsme opět u demagogie.
Abstraktní pohledy a koncepce mě nechávají tak nějak klidnými a žádné zprávy objektům se nikde neposílají a dosud jste neprokázali opak. Začíná mě to mírně nudit.
Rozhodl jsi se, že volání metod není zasílání zpráv objektu. Kde v tom chceš prokazovat jaký opak?
-
A jsme opět u demagogie.
Abstraktní pohledy a koncepce mě nechávají tak nějak klidnými a žádné zprávy objektům se nikde neposílají a dosud jste neprokázali opak. Začíná mě to mírně nudit.
Rozhodl jsi se, že volání metod není zasílání zpráv objektu. Kde v tom chceš prokazovat jaký opak?
Ako sa to vezme. Cele sa to zacalo tvrdenim, ze sa gettery a settery nesmu pouzivat, pretoze na to sa pouziva zasielanie sprav.
A nakoniec sa pride na to, ze cela ta komunikacia spravami nie je nic ine, nez gettery a settery, ktore sa vraj nesmu pouzivat...
-
Ako sa to vezme. Cele sa to zacalo tvrdenim, ze sa gettery a settery nesmu pouzivat, pretoze na to sa pouziva zasielanie sprav.
A nakoniec sa pride na to, ze cela ta komunikacia spravami nie je nic ine, nez gettery a settery, ktore sa vraj nesmu pouzivat...
Kde to kdo píše?
-
C# tomu rika property, Common Lisp tomu rika accessor. Tak si vyberte.
Nekdy me ale Javisti vazne bavi.. Takze mame dva objekty, A a B, a mezi nimi je vazba, a to se nam nelibi, protoze je to obtizne spravovatelne; kdyz se nejak zmeni A, bude se muset zmenit i B. Jak to vyresit? No, v OOP mame objekty, takze vytvorime dalsi objekt C, ktery ma vazbu na A i B. Tim padem, pokud se zmeni A, nebo se zmeni B, bude stacit zmenit jen objekt C. Problem ovsem ted je, ze nam zde stale zustala vazba mezi A a C, a vazba mezi B a C. To lze samozrejme dale vyresit, jak jinak nez pridanim objektu D a E..
nevybral bych si ani jedno. poslal autory nazvoslovi k sipku. dobry programator vyuziva jazyk na doraz a k tomu potrebuje po nejake dobe znat co skutecne leze z prekladace za interni struktury a volani a ne zbozna prani teoretiku, dokumentatoru nebo dokonce autora co jazyk neumi naprogramovat spravne nebo jeste lip autoru standardu, co nedokazi vyprodukovat 100% jednoznacny standard ani na 5ty pokus.
pravdepodobne neexistuje jazyk, ktery by splnoval konzistentni standard, implementaci, dokumentaci a odbornou literaturu tretich stran po celou dobu sve existence.
-
Objektům ve smyslu OOP se nikdy žádné zprávy neposílaly, neposílají a nikdy posílat nebudou. Nevím jak dlouho bude trvat než se tento nesmysl vymýtí. Použití metody objektu funguje naprosto stejně jako volání volání funkce.
Právě naopak. OOP je o tom, že se objektům zasílají zprávy a objekty na ně nějak reagují (převážně voláním metody, ale volající netuší které). Smalltalk snad není objektový jazyk? A to zasílání zpráv je dobrá představa i u mainstream jazyků. Co takový COM nebo CORBA?
Chápu, že většina programátorů ani netuší, že volání metod v C++/Javě/C#/... je jen osekaná verze obecnějšího principu. Vlastně je to taková konkrétní implementace místo obecnějšího popisu chování. :D
ja jsem teda ve fnioru zadnou zpravu nevidel, zato jsem tam videl udaje co vypadaly hodne podobne jako RPC zaznam o tom jakou funkci s jakymi parametry zavolat. holt asi jinej oddil ty uzasny produkty ibm /endsarcasm co jsem debugoval. nebo co si predstavujete pod objektovou referenci v podobe zpravy? kdyz uz tu teda padla ta corba.
-
A mrdat češtin ;D
Summer day see wheats! (http://www.youtube.com/watch?v=IN9uCEMHNQI) ;D