Dotaz: Volání setter a getter v php

[Marián]

Ahoj, neexistuje jiný zápis pro volání setterů a getterů v php než tento hrozně vypadající? Děkuji

$this->__set('foo');
$this->__get('foo');

Odpovědi

[Tarmaq]

co se ti na tomto nelibi? Nazvy metod? Vsak ty gettery i settery muzes mit pojmenovane jak chces..

[Tarmaq]

jinak u toho setteru bys mel mit dva parametry..

PS: neresim uzitecnost pouzivani getteru/setteru - idealne by ses bez nich mel obejit

[Kit]

ad PS: To se některým lidem těžko vysvětluje, protože dosud nepochopili, že gettery/settery narušují zapouzdření objektu. Zřejmě proto, že ve špatných učebnicích je napsán opak.

[FrostyX]

Můžeš prosím rozvést tu myšlenku o narušování zapouzdření?

[Kit]

Když k atributu přidáš getter/setter, rozšíříš rozhraní objektu o přístup k jeho implementaci. Nevhodnými vstupními daty v setteru můžeš způsobit nekonzistenci dat, pokud atributy na sobě nějak závisí.

Je lepší gettery/settery vůbec nedělat a atributy objektu ponechat jako privátní. Tím nám objekt zůstane hezky zapouzdřený a nikdo nemůže narušit jeho konzistenci.

[Šangala]

Getterem/setter nezpřístupníš žádnou imlementaci (naopak), je doplníš (obvykle) veřejné rozhraní. A setter právě potencionální inkonzistenci brání, protože provede ty patřičné operace aby k tomu nedošlo.

Je lepší gettery/settery vůbec nedělat a atributy objektu ponechat jako privátní…

Pominu-li, že mohou existovat různé typy tříd, mezi nimi třeba datové, zajištující právě tu konzistenci dat, kde se to minimálně gettery může hemžit, tak se jedná jen o jeden z možných způsobů jak pracovat.

Tím nám objekt zůstane hezky zapouzdřený a nikdo nemůže narušit jeho konzistenci.

Vidím tam hříčku, s tím co je zapouzdřené. Ale jinak počítač odpojený od sítě, taky nebude napaden, jeho využití, nechť každý zváží sám…

[Kit]

A setter právě potencionální inkonzistenci brání, protože provede ty patřičné operace aby k tomu nedošlo.

Pro většinu drtivou setterů, které vidím v různých aplikacích, toto tvrzení neplatí. Sofistikovaným setterům se omlouvám, ty jsem na mysli neměl. Měl jsem na mysli ty primitivní šmejdy, kterými se to v aplikacích jen hemží.

[Šangala]

No, ono se to logicky těmi primitivními hemží (tam kde se používá předávání dat), protože když tam ten primitivní setter/getter je, tak lze třídu případně upravit a udělat z něj pak sofistikovaný setter/getter), a tedy nerozbije se rozhraní třídy.

Furt někde něco nastavovat setterem a vybírat getterem je často jen blbost, nezkušenost či lenost, ale obecně bych to neodsuzoval.

[Kit]

Zkusím napsat, které settery považuji za špatné:

$obj = new Predmet();
$obj->setTvar('kostka');
$obj->setBarva('bílá');

Metoda setTvar() možná kontroluje, zda parametr je některým z podporovaných objektů a setTvar() kontroluje barvu, ale ten objekt není konzistentní. Po provedení prvního řádku vím, že mám nějaký objekt, ale nevím o něm nic. Použití takového objektu zpravidla způsobí chybu. Po provedení druhého řádku vím, že je to kostka, ale barva je stále v nedefinovaném stavu. Objekt stále není konzistentní.

[FrostyX]

Ale nic ti nebrání udělat konstruktor takový, aby se ten objekt v konzistentním stavu vytvořil.

[Kit]

Takové konstruktory samozřejmě dělám. Tohle je jen zjednodušená ukázka, jaké zmetky vídám v cizích zdrojových kódech. Bohužel až moc často. A k takovým zdrojákům svádí gettery a settery. Přitom zpravidla stačí jeden konstruktor, settery jsou v uvedeném příkladě zbytečné. Podobně bývají zbytečné i gettery.

[Logik]

Promiň, ale to že je ten kód blbě nijak nesouvisí se setterama a getterama.

To je jako bys tvrdil, že objekt nemá mít veřejné metody, protože se daj napsat veřejné metody, které poruší zapouzdření objektu. Teda spíš je Tvoje argumentace ještě nesmyslnější, protože chyba v Tvém příkladě není v tom, že pomocí setteru něco nastavuju, ale jen v tom, že tam prostě někdo neuměl napsat konstruktor, takže za to setter opravdu nemůže. Úplně stejně špatně by to šlo napsat i bez setteru s veřejnejma vlastnostma.

[Kit]

Asi jsem ten kód moc zjednodušil. Co třeba takhle?

$obj = new Predmet('kulička', 'modrá');
$obj->setTvar('kostka');
$obj->setBarva('bílá');

Už to mám i s konstruktorem. Předmětem je původně modrá kulička, která se pomocí setterů změní na bílou kostku. Samozřejmě je to také špatně.

Proč o tom píši? Protože je to i v různých návodech a spousta tupců to opisuje do svých aplikací. Ukaž mi příklad nějaké své třídy, ve které to bez setteru/getteru nejde. Samozřejmě s privátními vlastnostmi.

[FrostyX]

Předmětem je původně modrá kulička, která se pomocí setterů změní na bílou kostku.

No dobře, tak třeba změna tvaru nemusí být úplně v pořádku, ale nevidím důvod, proč by tu kuličku nemohl někdo přebarvit. Nebo proč by si člověk nemohl změnit telefonní číslo, student opravit známku, okno změnit stav ze zavřeného na otevřené, ...

Jak to chceš bez (nějaké obdoby) setteru řešit? Podle mě, máš prostě tři možnosti. Veřejnou metodu, klasický setter jako takový a nebo metodu typu setFoo($foo). Pokud tě chápu, tak jsi proti všem těmto možnostem, ...

[FrostyX]

Okno beru zpět, tam se to dá řešit například přes metody open(), close(), isOpened().

[logik]

A ono snad metody open, close a isOpened není nic jiného než zakuklenej setter a getter pro vlastnost opened? Jen protože je to dvoustavová vlastnost, tak místo setOpened(to) má objekt dvojici metod setOpened() a setClosed().... oni stejně jestli řešej nějakou logiku, tak pravděpodobně budou nějakout tu společnou metodu volat, by to člověk neřešil dvakrát...

[FrostyX]

Já bych to za setter neoznačil. Rozdíl vidím v tom, že tomu open() na rozdíl od setOpened(true) nepředávám argument, tedy dle Kitovi logiky, nemůže narušit konzistenci objektu.

[Logik]

Je to jen jinak napsaný setter. Dvojice open/close slouží přesně ke stejné věci, jako metoda setOpened().

[FrostyX]

Auto a letadlo taky slouží ke stejné věci - přepravě lidí. Přitom bych teda zrovna neřekl, že auto je jenom jinak vypadající letadlo.

Jako bez přesné definice setteru se tu můžeme jen dohadovat, co setter je a co setter není. Imho na základě toho co píšu v minulém příspěvku, se dvojice open(), close() za setter označit nedá.

[Kit]

Šel bych ještě dál. Auto, letadlo, kufr i trezor mohou mít společné rozhraní Otevíratelné s metodami open() a close(). Každý z nich to může implementovat jinak. Ty implementace se rozhodně nedají označit za settery, protože se netýkají atributu, ale objektu.

[FrostyX]

+1 Dobrá myšlenka.

Mimochodem, ty jsi pak nereagoval na moje příspěvky, mám to brát jako souhlas, nebo ses tím jen nechtěl zabývat?

[Kit]

Názor jsem napsal jinde a nechtěl jsem ho zbytečně kopírovat mezi vlákny. A tím svým dodatkem open() a close() jsi mě stejně odzbrojil. Tyto metody už nemanipulují s atributem, ale s objektem.

Možná to vypadá jen jako obyčejná změna názvu metod, ale i prosté přejmenování proměnné může změnit smysl třídy a čitelnost programu.

[Logik]

Frosty: ale auto i letadlo jsou dopravní prostředek...

Kit: ale přeci úplně stejně mohu definovat rozhraní setOpened. Máš pravdu, že objekt letadlo, kufr i trezor sdílejí společné rozhraní. To abstraktně popisuje něco, co je buďto zavřené nebo otevřené. Tedy něco, co jde zachytit jednorozměrnou veličinou. Tedy něco, co se dá popsat setterem.

IMHO chyba je totiž tvrdit, že setter je něco, co nastavuje fyzický atribut. Setter je IMHO něco, co mění stav objektu zachytitelný (zpravidla jednorozměrnou) veličinou. Ta je obvykle zachycená atributem, ale nikoli nutně. Právě proto je tam setter a ne přímý přístup k metodě. Protože ten setter může být implementován jakkoli a uvnitř klidně může nastavovat atributů pět, anebo třeba žádný.

Pokud se díváš na setter jako na "přímý přístup k atributu", ke kterýmu nemůžu protože je protected - tak máš pravdu - ale takový setter do OOP nepatří. Protože objekty nemají vystavovat své vnitřní proměnné. Setter/getter je IMHO dvojice metod zpřístupňující nějakou "abstraktní vlastnost" objektu, popsatelnou jednou proměnnou. Tedy něco, co umožňuje se zeptat na stav objektu (co se týče té vlastnosti) a tuto vlastnost změnit. Není teda naprosto problém, aby bylo rozhraní, které má setter a getter. A toto rozhraní budou sdílet letadlo, kufr i trezor.

HMMM - ale stejně to asi myslíme stejně a jen každej používáme jiný termity...

[Kit]

Pokud to bereš takhle, tak souhlasím. Jen booleovské parametry metod rád nemám, protože obvykle naznačují patlání dvou metod do jedné. Znepřehledňuje to (a mírně zpomaluje) aplikaci. Zkus porovnat:

$objekt->setVisible(false);
$objekt->setVisible(true);

a

$objekt->hide();
$objekt->show();

Uvnitř mohou dělat naprosto totéž, ale sémanticky se liší. Které řešení je pro tebe čitelnější?

[Logik]

Jak kdy - někde je vhodnej přístup s jednou metodou, někdy se dvěma.

Dvě metody maj výhodu v lepší čitelnosti, jedna metoda zas někdy umožňuje jednodušší práci s objektem (bez ifů). Zpravidla čím je ta vlastnost "symetričtější", tím spíše je výhodou jedna metoda a naopak: open/close, show/hide jsou zpravidla dost nesymetrické a proto tam jsou lepší metody dvě.

[Kit]

Právě že dvě metody jsou bez ifů. Jedna metoda se bez ifu obejde jen pokud ten parametr pouze někam ukládá. Jakmile použiješ konstanty true nebo false, je to špatně nebo přinejmenším nevhodně.

[Logik]

Já myslím ify v užití metod. Metody člověk implementuje jednou, používá furt.

Asimetrický metody typu open/close člověk málokdy na jednom místě volá s "proměnným" parametrem. Proto jsou vhodné metody dvě, protože je kód ve výsledku čitelnější. Symetrický metody se naopak volají často na místě, kde není jisté, jestli chci točit "vlevo nebo vpravo". V tu chvíli existence pouze jedné metody znamená, že místo if(chciVlevo) a.vlevo() else a.vpravo() volam a.jdi(vlevo)...

Reálnej příklad mi teď nějak do hlavy neskáče...

[Kit]

Myslím si, že symetrické metody se téměř neexistují. Resp. existují pouze v systémových knihovnách, které bývají napsány postaru a není vhodné měnit jejich rozhraní.

[Logik]

Co např. nastavení orientace písma? (Normální nebo arab ) Zapnutí/vypnutí průhlednosti objektu? Nastavení příznaku, zdali je daná osoba student nebo ne (nezpůsobí to nic, akorát se podle toho následně bude počítat daňový přiznání)? Nastavení, zdali se dané osobě má nebo nemá posílat pravidelný newsletter. Atd....

Obecně: symetrické jsou zpravidla ty metody, které nezávisle na argumentu provedou stejné akce (viz např. první dva příklady, oba nezávisle na vypnutí/zaptnutí způsobí překreslení), speciálně pak ty vlastnosti, jejichž změna nezpůsobí žádnou okamžitou reakci (druhé dvě vlastnosti).

[Kit]

• Orientace písma? To není boolean, ale enum. O tom svědčí i fakt, že jsi musel použít vysvětlivku.
• Průhlednost okna? Proč jsou špatně metody hide() a show()? Však jsi napsal zapnutí/vypnutí. Opět zbytečné vysvětlivky. Jiná situace by nastala, pokud by se nastavoval alfa kanál.
• Příznak studenta? Ano, to je boolean, i když to není symetrické. Také by to mohl být výčet či množina (student, nezaměstnaný, pracující, důchodce). Pokud ho dám do konstruktoru, nemusí na to být setter.
• Mohl by to být boolean. Také by to mohl být výčet (nezasílat, jenVýroční, zasílat)

Kdesi jsem viděl jako boolean i pohlaví (má ho (ji)/nemá). Dost odstrašující příklad.

[logik]

- každou bool proměnnou vždy můžeš zakódovat do enumu. Někdy je to srozumitelnější, někdy ne. Pokud píšu sw např. pro užití v rámci evropské kultury, tak ale může být přirozenější bool volba "opačná orientace písma" - z který jasně plyne co je stadard a co výjimka, než enum "zleva_do_prava" a "zprava_do_leva", kde bude člověk půl minuty přemšlet, odkud kam to vlastně píše Pokud píšu plně internacionální program, je samozřejmě lepší výčet. Na jednu věc může být dle kontextu více "nejlepších" řešení.

- průhlednost okna - hodí se mít nastavený alfakanál na konstantní hodnotu, ale kromě toho mít možnost tu průhlednost zapnout/vypnout, aniž by člověk hýbal s nastaveným alfakanálem. Dvě metody jsou tady míň ergonomické, protože tudle vlastnost budu vázat s nějakým zapínacím tlačítkem, jehož vypnutí/zapnutí opět jednoduše a bezproblémově vyřeším setterem a getterem. Další výhoda bool setteru je tu symetrie s getterem - který zde zcela jistě potřebuji.

- výčet student/důchodce atd... použít nejde, protože to nemusí být disjunktní množiny (a pokud v současné právní úpravě některé dijunktní jsou, neznamená to, že za rok budou furt: proto je správné tu disjunktnost zajistit nikoli na úrovni uložení dat, ale na úrovni přístupových metod). A pokud to dáš do konstruktoru, tak se nutnosti setteru nezbavíš, protože samozřejmě člověk během svého života tyto své statusy mění. To už mi přijde, že hledáš jakoukoli cestu, hlavně abys nemusel použít bool setter.

- výčet (nezasílat, jenVýroční, zasílat) užít jde, ale je to imho blbé řešení. Totiž ono je použitelné jen pro dvě kategorie newsletterů (a to ještě těžko, jak je vidět, žes ze čtyř možností jsi dal jen tři, protože čtyři už by byl trochu zmatek - a s dalšími kategoriemi roste počet možností exponenciálně). Přitom běžné je, že buď stačí jen hrubé rozdělení (zasílat/nezasílat - např. většina eshopů na webu nic jemnějšího nepotřebuje), nebo je třeba rozdělení dle kategorií newsletterů - kde bude u každé volba ne/zasílat danou kategorii - pak ale zas je většinou hodně nepraktické mít ty kategorie natvrdo v kódu. Za povšimnutí také stojí, že mé řešení jde na více kategorií jakžtakž rozšířit (původní setter může zůstat jako "all-in-one" nastavování), zatímco řešení s výčtem bude třeba přepsat.

[logik]

Ano, jsou vlastnosti, které smysl měnit nemá - a k nim nemá být setter (ale proč ne getter)? Kolik takových vlastností v reálu je?

Ono to je spíš tak, že když mám objekt Predmet, kterýmu na začátku nastavím, jestli je kostka nebo kulicka, a už se to nikdy nemá měnit, tak to dost často bývá chyba návrhu - mám mít podtřídu pro kostku a podtřídu pro kuličku. Protože to, že stav objektu nemůže přejít svým stavem z kuličky na krychly většinou zároveň znamená, že se (z programovacího hlediska) ty objekty nějak podstatně liší - a tedy bych měl mít pro každý svoji třídu.

Samozřejmě, máš pravdu, že často je třeba složitější logika spojená se změnama stavu a pak už setter (nikoli ovšem getter) přestává mít smysl. Ale to se zdaleka netýká všech vlastnosti a všech objektů...

[Kit]

Nechtěl jsem zabíhat do dědičnosti, aby ten příklad nebyl příliš složitý. Místo tvaru předmětu si můžeš představit méně zásadní atribut.

Ani getter nemusí být potřebný, zpravidla můžeš použít celý objekt:

$obj = new Predmet('kulička', 'modrá');
$obj = new Predmet('kostka', 'bílá');
echo $obj;

Původní objekt byl nahrazen novým, atributy vloženy konstruktorem a getter nahrazen metodou __toString(), která udělá i potřebné výstupní formátování. Takový objekt se dá bez problémů místo echa přímo strčit do výstupní šablony.

Jednou definované objekty už zpravidla neměním. Je to jen příklad, jak se dá udělat elegantní viewer.

[logik]

Pokud je na místě jiná kulička, je správné ji znovu vytvořit.

Pokud kulička změnila barvu, např. že ji někdo přebarvil, je správné ji změnit barvu setterem.

Vytvářet nový objekt jen proto, že se mu nějaký méně podstatný atribut změnil je s prominutím zhovadilost. Je to sémanticky špatně (žádný nový objekt ve skutečnosti nevznikl) a také to proto s sebou nese rizika chyby (např. co když někdo počítá počet vytvořených kuliček)?

PS: Objekty nejsou jen "obalené databázové řádky" a programování není jen MVC. To, že __toString() nahradí getter už je úplně ulítlý - s objekty se běžně pracuje (např. chci vědět, kolik je v sáčku kuliček kterých barev), a ne jen se plivou na výstup.... nehledě k tomu, že i pro plivání objektů na výstup stačí jedna univerzální výstupní metoda jen u těch nejtriviálnějších objektů.

[Kit]

Asi nejsem zvyklý měnit barvu kuliček, musel bych k tomu mít hodně pádný důvod. Proto nepotřebuji setter. Pokud se však kulička chce z nějakého důvodu přebarvit, tak se přebarvit může. Možná bych kvůli tomu napsal i setter.

Viewer jsem zvolil jen jako příklad. Pokud chci vědět, kolik je v sáčku kuliček které barvy, využiji s výhodou schopností databáze a netahám to do objektů.

V PHP jsou skoro všechny objekty triviální. U většiny objektů si vystačím s jedním konstruktorem a jednou univerzální výstupní metodou.

[Lucius]

ty metody se volaji preci automaticky - kdyz chces nastavovat nebo vracet vlastnost ktera neni deklarovana

a jestli s nepletu tak spravne je

__set( $name , $value )

[Sten]

$this->foo = value; // zavolá __set('foo', value)
echo $this->foo; // zavolá __get('foo')

[Marián]

Všem díky moc! Alw co když to value bude pole? Jde to?

value = array('bla', 'bla2');
$this->foo = value; // zavolá __set('foo', value)