Jakiś czas temu, zainspirowany artykułem Giorgio Sironiego - „How to remove getters and setters” rozpocząłem dyskusję na forum goldenline na temat przydatności getterów i setterów. Dyskusja była dość burzliwa, jak to zawsze ma miejsce, gdy próbuje się naruszać dogmaty. Jednak wszystko przebiegło w na tyle przyjaznej atmosferze, że nie skończyło się na „flejmłorze” i padło kilka interesujących argumentów. Teraz nadszedł czas by z perspektywy czasu podsumować tą dyskusje i przedstawić wnioski, do jakich doszedłem po jej zakończeniu.
Dla tych, którym się nie chce czytać artykułu, szybki szkic problematyki – Giorgio wysunął śmiałą tezę, że stosowanie „getterów i setterów” psuje enkapsulację, która jest jedną z podstaw programowania zorientowanego obiektowo. W swoim artykule opisuje on sposoby na całkowite pozbycie się tych często używanych artefaktów.
Jako, że zgadzam się z główną tezą artykułu Giorgia, w dalszej części artykułu zamierzam zaprezentować przypadki w których użycie getterów bądź setterów jest szkodliwe, wraz z uzasadnieniem i przykładowym rozwiązaniem problemu. Pokaże również, przypadki w których zastosowanie tych konstrukcji ma sens. Abyśmy się jednak dobrze zrozumieli, najpierw moja definicja – czym są gettery i settery.
Jako getter i setter, rozumiem metody klasy, zwykle nazwane wg wzoru „getFoo()”, „setFoo()”, które ”mapują się 1:1″ z odpowiadającymi im polami klasy. Przykład:
class Bar {
private $_foo;
public getFoo(){
return $this->_foo;
}
public setFoo($foo){
$this->_foo = $foo;
}
}
Przypadki problematyczne:
1.Setter, który wpływa na obiekty kolaborujące klasy.
Wyobraźmy sobie, że mamy sobie taką oto klasę do obsługi tabeli w bazie danych:
class Foo_Table {
private $_db;
public function setDb($db){
$this->_db = $db;
}
public function getDb(){
return $this->_db;
}
public function fetchAll(){
//kod
}
}
Przypomina ona z grubsza klase Zend_Db_Table_Abstract i jest to właściwe skojarzenie (różnica polega na obecności statycznego settera). . Zobaczmy teraz jakie problemy generuje zastosowanie settera:
//gdzies w kodzie tworzymy obiekt $fooTable
$db1 = new PDO($dsn, $username, $passwd, $options);
$fooTable = new Foo_Table;
$fooTable->setDb($db1);
//inne miejsce w kodzie
$fooTable->fetchAll(); //zwraca array(1,2,3);
//inne miejsce w kodzie
$db2 = new PDO($dsn2, $username, $password,$options);
$fooTable->setDb($db2);
//inne miejsce w kodzie
$fooTable->fetchAll(); //zwraca array(4,5,6) - inna baza danych
Jak widać na wyżej załączonym kodzie, z powodu zastosowania settera, można w międzyczasie zmienić obiekt adaptera bazy danych, z którego korzysta klasa tabeli. Konsekwencją tego jest mniejsza przewidywalność klasy – w drugim przypadku dostajemy inny wynik. W przypadku Zend_Db_Table_Abstract sytuację pogarsza fakt, zastosowania statycznego settera, co wielokrotnie zwiększa możliwości zmiany adaptera i nieprzewidywalność takiego kodu. Łatwo usunąć ten problem poprzez likwidację settera i zastosowanie wstrzykiwania obiektu połączenia z bazą danych poprzez konstruktor.
2. Rozpełzanie się kodu
Dziwna nazwa, ale już tłumacze o co chodzi. Zostawmy na chwilę poprzedni przykład z tabelą, żeby nie było, że przyczepiłem się do Zend_Db. Kolejnym przykładem będzie klasa reprezentująca użytkownika, oczywiście dla potrzeb przykładu została skrócona do minimum:
Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...
Zwiń
Czytaj na blogu autora...
Kanał ATOM
Całość została przeze mnie mocno zmodyfikowana. Dodałem np. rzucanie wyjątkami jeżeli wymagana wartość nie została ustawiona plus obsługę domknięć w przypadku gdy ustawiona wartość jest funkcją anonimową.