@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:
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')));
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:
function setCache(CacheInterface $cache) {
$this->cache = $cache;
$this->useCache = true;
}
public function set($key, $value) {
//...
}
I używać kodu normalnie, tj:
$r = new Resource();
$r->setCache($myCacheImpl);
$r->set('xyz', 'aaa');
// zamiast
$r->cache = $myCacheImpl;
$r->xyz = 'aaa';
Raczej nie przekonasz mnie, że interfejs drugiego rozwiązania jest lepszy... bo jak dla mnie to jest on okropny i podatny na błędy.
Cytat
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ę?
Cytat
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ę:
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;
}
}
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ń:
$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ć
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.