Metody magiczne, Czy jest sens stosowania? Opcje

[JoShiMa]

dla mnie to chore wywoływac metodę magiczną wewnątrz klasy.

[Crozin]

@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.

@wookieb: Co do pierwszego listingu... jest on chyba niekompletny bo kompletnie nie trzyma się kupy - albo ja nie potrafię sobie wyobrazić co ten kod miałby robić (konkretniej metoda __set w przypadku gdy podajemy klucz inny niż "cache"). Poza tym już uwidacznia się tu pierwszy "wtf". Na metodę __set() spada obowiązek wykonywania wielu zadań - czy nie lepiej by było:

[PHP] pobierz, plaintext 
function setCache(CacheInterface $cache) {
  $this->cache = $cache;
  $this->useCache = true;
}
 
public function set($key, $value) {
  //...
}
[PHP] pobierz, plaintext 

I używać kodu normalnie, tj:

[PHP] pobierz, plaintext 
$r = new Resource();
$r->setCache($myCacheImpl);
$r->set('xyz', 'aaa'); 
 
// zamiast 
$r->cache = $myCacheImpl;
$r->xyz = 'aaa';
[PHP] pobierz, plaintext 

Raczej nie przekonasz mnie, że interfejs drugiego rozwiązania jest lepszy... bo jak dla mnie to jest on okropny i podatny na błędy.

A co gdybym dopisał opcję ustawiania flagi $useCache na false w przypadku usunięcia obiektu Cache?

Dodać metodę odpowiedzialną za usuwanie cache, która po usunięciu zmieni flagę?

Klasa to nie tablica, której przypisujemy po prostu wartości do właściwości. Służy do wykonywania konkretnych zadań w których mieści się kontrola nad wartościami w jej wnętrzu.

Gdy pisałem o tablicach/kolekcjach miałem na myśli taką sytuację:

[PHP] pobierz, plaintext 
class AbcMyClass {
  protected $storage = array();
 
  public function get($key, $default = null) {
    return array_key_exists($key, $this->storage) ? $this->storage[$key] : $default;
  }
 
  public function set($key, $value) {
    $this->storage[$key] = $value;
  }
}
 
class AbcMyClass {
  public function __get($key) {
    return isset($this->{$key}) ? $this->{$key} : null;
  }
 
  public function set($key, $value) {
    $this->$key = $value;
  }
}
[PHP] pobierz, plaintext 

Pomijając fakt o ile bardziej podatne na błędy i mniej elastyczne jest drugie rozwiązanie (ograniczone możliwości dla nazwania kluczy, problem gdy nazwa klucza jest w zmiennej) spójrzmy na całą różnicę pomiędzy użyciem obu rozwiązań:

[PHP] pobierz, plaintext 
$obj->get('parameterA');
$obj->parameterA;
 
$obj->set('parameterA', 123);
$obj->parameterA = 123;
 
$obj->get($abc->getKey());
$key = $abc->getKey(); $obj->$key; // nie jestem pewien czy $obj->{$abc->getKey()}; zadziała. Zrezstą za używanie zmiennych zmiennych powinno się coś obcinać
[PHP] pobierz, plaintext 

Co do drugiego przypadku (z klasą Session). Znowu ten sam problem - dziesiątki IFów. Na pewno żaden z nas nie byłby szczęśliwy mając wykorzystywać tą klasę. Takie rozwiązanie dla mnie byłoby do zaakceptowania wyłącznie w przypadku konieczności zachowania wstecznej kompatybilności. Tj. zakładając, że mamy już kod, klasy, która ma publiczną właściwość "id" musimy dodać jeszcze opcję usuwania użytkownika gdy jest ona fałszem. Paskudne rozwiązanie ale jedno z niewielu jakie pozwala na zachowanie tej nieszczęsnej kompatybilności.

[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.