Metody magiczne, Czy jest sens stosowania? Opcje

[cojack]

Nudni jesteście, ilu programistów tyle pomysłów jak wykorzystać metody magiczne. Zamknijcie ten temat.

[Eby]

@Eby: Jak można porównywać return do echo? Poza tym ten przykład to też wiele z tematem wspólnego nie ma. Jak już to powinieneś porównać takie zapisy:

[PHP] pobierz, plaintext 
echo $helper->tag('a', 'more', array('href'=>'controller::action','class'=>'link'));
echo $helper->helper('tag', 'a', 'more', array('href'=>'controller::action','class'=>'link'));
echo $helper->helper('tag', array('a', 'more', array('href'=>'controller::action','class'=>'link')));
[PHP] pobierz, plaintext 

Chociaż osobiście wszystkie uważam za niezbyt trafne.

Wybacz, nie dokładnie opisałem o co mi chodzi przedstawiając jedynie pewien efekt końcowy.
Pisząc o wrapperze "helper" w temacie o metodach magicznych miałem na myśli raczej coś takiego :

[PHP] pobierz, plaintext 
<?php
class helper {
	protected $_obj = array();
	...
	public function __call($name, $arg) {
		if ( !isset($this->_obj[ $name]) ) {
			$filename = 'View_Helper_' . $name;
			require_once( $filename );
			$this->_obj[ $name ] = new $filename();
		}
		return $this->_obj[ $name ];
	}
}
 
class View_Helper_Tag {
	...
	public function __toString() {
		return $this->render();
	}
	public function render() {
		$str = "<".$tag;
		...
		if ( in_array($tag, $this->_autoclose) )
			$str .= '/>';
		else
			$str .= '>';
		...
		return $str;
	}
}
[PHP] pobierz, plaintext 

Owszem Twój zapis zrobi to samo, ale ja na końcu mam pewien obiekt z którym mogę coś jeszcze zrobić (idziemy w kierunku aspx i kontrolek) - i wyrzucenie tego na standardowe wyjście jest tylko jedna z możliwości. Twój zapis tego nie umożliwia niestety.

[Zyx]

wookieb -> i ja bym ten Twój przykład z życia zapisał tak:

[PHP] pobierz, plaintext 
class Resource
{
    public function set($name, $value)
    {
        // ... 
    }
    public function get($name)
    {
        // ... 
    }
} // end Resource;
[PHP] pobierz, plaintext 

Wszystko, co da się zrobić za pomocą metod magicznych, da się równie elegancko zrobić zwykłymi wywołaniami metod. I taki kod będzie w dodatku dużo czytelniejszy. Ostatnio musiałem wrócić do Symfony 1.x i Doctrine 1.x i tracę tam naprawdę sporo czasu na radzenie sobie z różnymi dziwnymi i niepożądanymi dla mnie skutkami tego, że połowa tego, co się dzieje w tym frameworku to czysta magia. Pisze sobie człowiek metodę i nagle mu się rozpierdziela odwołanie do... pola, albo jeszcze śmieszniej: odwołanie tablicowe w zupełnie innej części kodu. Nie będę wspomniał już o wynalazkach w stylu tych, co zaproponował Eby, które też dokładają swoje idiotyzmy.

Kod

$helperCollection->getHelper('tag')->render();

Ponadto thek ma rację. Jeśli pole jest zadeklarowane np. jako chronione, a my próbujemy dostać się do niego spoza klasy, wywoła się metoda magiczna. Jeśli ją źle napiszemy, będziemy mogli się do niej dostać. A tak w ogóle to podział private, protected i public ma sens tylko jako zachęta do stosowania pól zgodnie z przeznaczeniem. Jak komuś będzie zależeć, zawsze da się w ten czy inny sposób wartość pola prywatnego odczytać spoza obiektu bez względu na to, jak się zabezpieczymy. Najprostsze wyjście (od PHP 5.3) to refleksja.

Ten post edytował Zyx 25.02.2011, 14:15:32

[Eby]

Nie będę wspomniał już o wynalazkach w stylu tych, co zaproponował Eby, które też dokładają swoje idiotyzmy.

Kod

$helperCollection->getHelper('tag')->render();

I tutaj niestety Twoje rozwiązanie jest moim zdaniem mniej czytelne (jeśli jeszcze dodasz do tego dodatkowe parametry które były w poprzednim poście) - wiec (znów moim zdaniem) nie zyskałeś nic - ani czytelności kodu ani w zasadzie szybkości wykonywania... Mniejszą możliwość popełnienia błędu - co jest tylko teorią, gdyż patrząc na kod w jednym i drugim przypadku jesteś w stanie stwierdzić jak działa. Oczywiście twój zapis jest dłuższy jedynie o kilkanaście znaków co sprowadza się do wydłużenia kodu szablonu o 25% nie zyskując w praktyce nic.

[Zyx]

Jakie "dodatkowe parametry", kiedy nic z tymi parametrami w __call() nie robisz?

1. Czytelność kodu - doprawdy? To spróbuj sobie znaleźć w dokumentacji później opis do takiego wywołania.

2. Szybkość wykonania - OMG, a skąd Ci się coś takiego wzięło? Kto tu o jakiejś szybkości wykonania mówi? Zresztą, patrząc jakie ludzie wymyślne parsery nazw funkcji i pól potrafią wsadzić do metod magicznych, mam wątpliwości co do wydajności. Co więcej, jeśli mamy mnóstwo metod magicznych, w zasadzie żeby cokolwiek zoptymalizować, najlepiej wszystko wczytać do własnych zmiennych i prostych tablic. Jak można mówić o optymalizacji, kiedy nie masz pojęcia o tym, z czym masz do czynienia? Piszesz: $helper->tag. To dobrze czy źle? Zapisywać do zmiennej tymczasowej czy nie zapisywać? Szybko to działa czy wolno? Co się wtedy dzieje? Nawet jest problem ze sprawdzeniem tego, bo: patrz punkt 1.

3. Długość kodu... no cóż, jak się nie wpadnie na to, że wynik długiego i skomplikowanego wywołania można sobie zapisać do zmiennej i używać wielokrotnie...

[wookieb]

Wookieb... Dobrze napisałem. Używając __set i __get, tworzymy metodę, która udostępnia wszystkim na zewnątrz atrybuty klasy. Jeśli byśmy tego nie chcieli w pełni, to musimy to ograniczać już wewnątrz definicji tej metody. Przykładowo mamy wspomnianą przez Ciebie klasę z 200 atrybutami, w tym 5 private i 5 protected, z których nie wszystkie chcemy udostępniać na zewnątrz. Co robimy? Sięgamy po refleksję by sprawdzić, czy dany atrybut jest na "black-liście"? Fajnie... Kosztem naszej wygody (linie kodu) zarżynamy wydajnościowo aplikację, która oprócz magii jeszcze po refleksję sięga.

Thek błagam Cie. Myśl czasem. To, że __get i __set działają przy PRÓBIE dostania się do właściwości prywatny WCALE nie oznacza, że chcemy ich do tego używać. To, że widziałeśtylko takie zastosowanie tej metody wcale nie znaczy, że jest jedyne. Opcji jest całe mnóstwo.

O to mi chodziło w przykładzie. __set i __get oraz inna magia daje dostęp nie zawsze w sposób jaki byśmy chcieli ostatecznie uzyskać i musimy nad tym panować. Poza tym powiedz mi jedno wookieb: "Czy __set i __get ruszają do działania jeśli atrybut jest public?", bo jak dla mnie nie. Sam kwantyfikator zezwala na grzebanie mi w zmiennych public, więc o czym my mówimy tutaj? O pisaniu settera i gettera magicznego dla czegoś, co i tak nie będzie użyte? Bo klasa mając składową publiczną odda nam ją od razu i odwołanie się do magii nie nastąpi nigdy?

Ale co to ma do rzeczy? Wszystko zależy od projektu klasy. Jeżeli ktoś miesza magię z publicznymi właściwościami to jego problem. To tak jakby mówić, że żelazko jest BE bo można się nim poparzyć... Wszystko z rozwagą. Proszę Cię THEK, wiem że lubisz się wygadać ale ty już nie rozmawiasz. LEJESZ WODĘ mówiąc o rzeczach oczywistych.

PS... Tak wiem... Pozwala utworzyć i odczytywać w locie obiektowi nieistniejące składowe choćby, ale IMHO takie posługiwanie się wynika ze zrypanego procesu projektowego. Źle zaprojektowana aplikacja po to sięgnie. Dobrze przemyślana nie potrzebuje takich łat.

A widział ty kiedyś coś takiego jak settery i gettery w innych językasz? Wiem, że chyba w JS gdzieś to dało się zrobić, w AS na pewno. Co to dawało? Znacznie łatwiejsze w użyciu reagowanie na zmiany pewnych wartości. I sry ale nie przekonasz mnie, że jest to brzydkie. Jest piękne w swojej prostocie i wykorzystaniu.

Wszystko, co da się zrobić za pomocą metod magicznych, da się równie elegancko zrobić zwykłymi wywołaniami metod. I taki kod będzie w dodatku dużo czytelniejszy. Ostatnio musiałem wrócić do Symfony 1.x i Doctrine 1.x i tracę tam naprawdę sporo czasu na radzenie sobie z różnymi dziwnymi i niepożądanymi dla mnie skutkami tego, że połowa tego, co się dzieje w tym frameworku to czysta magia. Pisze sobie człowiek metodę i nagle mu się rozpierdziela odwołanie do... pola, albo jeszcze śmieszniej: odwołanie tablicowe w zupełnie innej części kodu. Nie będę wspomniał już o wynalazkach w stylu tych, co zaproponował Eby, które też dokładają swoje idiotyzmy.

Powiedz to fanom CAKEPHP.

Chwila stopu. O co my się kłócimy?
Co jest ładniejsze?

$klasa->set('pole', 'wartosc');

// czy
$klasa->pole = 'wartosc';

Przecież to zależy od preferencji i swoje upodobania.
1 przyda się do wywoływania łańcuchowego a drugie do pracowania na obiekcie klasy jak na STDClass. I tak 2 rozwiązania jest zarąbiście wygodne.

Ja mam cały czas wrażenie, że jesteście zamknięci w schemacie MAGIA = dostęp do włąściwości private i protected. Skończcie z tym bo zastosowań __get i __set jest dużo dużo więcej.

[Crozin]

Przecież napisałem, że w przypadku metod __get() i __set() rozchodzi się wyłącznie o sposób w jaki można wywołać te metody. Cały wątek właściwie rozchodzi się o konsekwencje udzielenia takiego zapisu i faktu, że metody te są wywoływane nawet wtedy gdy być nie powinny. Również nie rozumiem o co chodzi z tym dostępem do prywatnych właściwości.

[thek]

Wookieb. Ja nie jestem anty-magic zatwardziały. Nie jestem przeciwko magii, ale przeciwko nadużywaniu jej, zwłaszcza w sytuacjach gdzie nie musi być uzywana. Przykład jaki podałem miał na celu jedynie pokazanie jak magia bywa zwodnicza i dlaczego trzeba z nią uważać, gdyż nieumiejętne zabieranie się za nią może przynieść więcej szkody niż pożytku. To, że ułatwia dużo rzeczy, nie oznacza, że trzeba po nią sięgać gdzie popadnie. To tak jak z samochodem. To, że ma na liczniku 220, nie oznacza, że przy każdym wyjeździe trzeba go "zamknąć".