prawidlowe OOP , struktura klasy, Jak wedlug koncepcji OOP napisac dobra klase Opcje

[rahul]

Witam
Temat pewnie wam znany i stary jak swiat. Pisze sobie swoj cms starajac sie zrobic to obiektowo. Dotychczas przejrzalem i przeczytalem wiele artykulow dotyczacych OOP i robie sie coraz glupszy bo z tego co rozumie to zastosowan jest multum, tylko ktore to najlepsze. mam taka klase

[PHP] pobierz, plaintext 
include_once('db/db.php');
class User
 { 
	private $user_id;
	private $first_name; 
	private $last_name; 
	private $login;
	private $password;  
	private $email; 
	private $ip; 
	private $user_role; 
	private $registration_date; 
	private $db;
 
	function __construct() 
	{
		$this->db = Database::getInstance(); 
	}
 
	function setLogin($login) 
	{ 
		$this->login = $login;
	}
 
	function setPassword($password) 
	{
		$this->password = $password; 
	}
 
	function setFirstName($firstName) 
	{
		$this->firstName = $firstName; 
	}
 
	function setLastName($lastName) 
	{
		$this->lastName = $lastName;
	}
 
	function setEmail($email)
	{
		$this->email = $email;
	}
 
	function setUserRole($role)
	{
		$this->role = $role;
	}
 
	function setRegistrationDate($registration_date) 
	{
		$this->registration_date = $registration_date;
	}
 
 
	function login() 
	{
		$action = $this->db->prepare("SELECT * from users WHERE login LIKE '$this->login' 
									  AND password LIKE '$this->password'"); 
		$action->execute(); 
		$result = $action->fetchAll();
		if(count($result)== 1)
		{
			if($result[0]['Role'] == 0)
			{
				$_SESSION['user_id'] = $result[0]['user_id']; 
				return true;
			}else if($result[0]['Role'] == 1)
			{
				$_SESSION['user_id'] = $result[0]['user_id'];
				$_SESSION['admin'] = 'admin';
				header('location:admin.php');
			}
		}
		return false; 
	}
 
	function register() 
	{ 
		$ip = $_SERVER['REMOTE_ADDR'];
		$action = $this->db->query( "INSERT into users(user_id , Login , Password ,  Name , LastName ,Email , Ip , Role , RegistrationDate)
							    VALUES('' , '$this->login' ,'$this->password' , '$this->firstName' , '$this->lastName' , '$this->email' , '$ip' ,
                                                             '$this->role' , NOW())"); 
		$action->execute();
		return true;
	}
 
	function EditUser() 
	{
		...
	}
 
	function ChangePassword()
	{
		...
	}
} // end of class. 
?>
[PHP] pobierz, plaintext 

Pierwsze pytanie : Czy klasa User powinna miec funkcje takie jak Loguj, Rejestruj, Edytuj, Zmien Haslo i czy te funckje powinny miec juz "hardcoded" zapytania do bazy wewnatrz, patrz funckja loguj();. Wywoluje ja tak:

[PHP] pobierz, plaintext 
 
$user_c = new User(); 
	$user_c->setLogin($_POST['login']);
	$user_c->setPassword(md5($_POST['password']));
	$login = $user_c->login(); 
[PHP] pobierz, plaintext 

Jezeli cos tego pokroju jest ok to spoko. Teraz np dopisalem sobie taka funkcje to tej samej klasy, ktora jak dla mnie moglaby byc w kazdej prawie innej klasie :

[PHP] pobierz, plaintext 
class User { 
 
private $sqlObj; 
private $SqltableRows;
 
function query($query) 
	{
		$sql = $this->db->query($query); 
		$sql->execute(); 
		$this->sqlObj= $sql->fetchAll(PDO::FETCH_OBJ);
		$this->SqltableRows= $sql->fetch(PDO::FETCH_ASSOC);
	}
}
[PHP] pobierz, plaintext 

Dzieki tej funkcji lapie sobie wszystko z bazy i w prosty sposob moge wywolywac wszystkie kolumny :

[PHP] pobierz, plaintext 
$user_c = new User(); 
$user_c->query("SELECT * FROM users");
$users = $user_c->getObj(); 
foreach ($users as $user)
{
echo $user->Name;
echo $user->Password;
}
[PHP] pobierz, plaintext 

Bardzo podoba mi sie mozliwosc poboru rekordow i nazw wierszy tabeli w tak prosty sposob. Teraz do rzeczy :
Funckja ta jest w Users ale generalnie moglaby byc w prawie kazdej innej klasie, np Products, Articles itp. Czy mam utworzyc osobna klase z ta funckja z ktorej jakos beda kozystac wszyskie inne klasy ? Czy ma byc to w klasie bazy danych, czy moze w jakies jeszcze innej ?

Prosze o odpowiedzi i wyrozumialosc


Ten post edytował rahul 20.08.2011, 20:50:56

[Noidea]

Pierwsze pytanie : Czy klasa User powinna miec funkcje takie jak Loguj, Rejestruj, Edytuj, Zmien Haslo

Nie. Rozbij to sobie na dwie klasy:
User - zwykły kontener na login, hasło, email itd.
UserManager - zarządza użytkownikami (wczytuje, zapisuje, kasuje, itd.)

czy te funckje powinny miec juz "hardcoded" zapytania do bazy wewnatrz, patrz funckja loguj();. Wywoluje ja tak:

Zależy. Jak chcesz mieć rozwiązanie, w którym łatwo jest zmienić sposób komunikacji z bazą danych, np. zamiast PDO użyć jakiejś klasy z PEAR, to powinieneś dodać w tym miejscu jeszcze jedną warstwę abstrakcji. Tyle że na 99% nigdy ci się to nie przyda, a tylko skomplikuje kod. Najlepiej wybierz sobie jedną metodę komunikacji z bazą i jej się trzymaj. PDO jest ok.
Z tego rozwiązania które masz wyrzuciłbym tylko pobieranie obiektu PDO z singletona, a zamiast tego przekazywał ten obiekt w parametrze konstruktora

[PHP] pobierz, plaintext 
$user_c = new User();
$user_c->query("SELECT * FROM users");
[PHP] pobierz, plaintext 

To jest źle. User nie powinien nic wiedzieć o wykonywaniu zapytań SQL. Od tego jest PDO


[EDIT]Aha, jeszcze jedno. Operacje takie jak zmiana hasła czy adresu email robisz tak:

[PHP] pobierz, plaintext 
<?php
 
class User { /* (...) */ }
 
class UserManager { /* (...) */ }
 
$user = $userManager->getUserByID( $userID );
$user->setPassword( $newUserPassword );
$userManager->updateUser( $user );
?>
[PHP] pobierz, plaintext 

Czyli wystarczy ci jedno duże zapytanie UPDATE aktualizujące wszystkie pola w tabeli z użytkownikami, nawet jeśli zmieniło się tylko hasło, czy tylko email

Ten post edytował Noidea 21.08.2011, 08:18:38

[rahul]

Dzieki za odpowiedz.
Mam szereg nastepnych pytan.
Po co tak w zasadzie mi podzial na 2 klasy, User, UserManager .. wtedy bede musial wszystkie inne pozostale klasy tez w ten sposob rozbijac. Co mi daje taki zwykly kontener ? Jakos nie bardzo to do mnie przemawia ..

[PHP] pobierz, plaintext 
$user_c = new User();
$user_c->query("SELECT * FROM users");
[PHP] pobierz, plaintext 

To jest źle. User nie powinien nic wiedzieć o wykonywaniu zapytań SQL. Od tego jest PDO

Ok, ale wszystkie funckje typu Loguj, zmien, edytuj i tak wiedza o zapytaniach SQL. Tylko sa one wewnatrz.
Czy funkja query np moglaby byc w klasie z Baza danych?

Z tego rozwiązania które masz wyrzuciłbym tylko pobieranie obiektu PDO z singletona, a zamiast tego przekazywał ten obiekt w parametrze konstruktora

Jaka jest wtedy roznica ? Nie do konca widze...

Ten post edytował rahul 21.08.2011, 10:44:28

[Crozin]

To z czym masz tutaj do czynienia to mapowanie obiektów do / z zapytań relacyjnej bazy. Innymi słowy, jest to ORM. Napisanie ORM-a, który miałby być zdatny do czegokolwiek jest daleko poza Twoimi obecnymi możliwościami, tak więc nawet nie próbuj brać się za to - skorzystaj z gotowego, solidnego rozwiązania. Osobiście proponuję Doctrine2 bo jest to jedyny duży, PHP-owski ORM o sensownej architekturze.

Po co tak w zasadzie mi podzial na 2 klasy, User, UserManager .. wtedy bede musial wszystkie inne pozostale klasy tez w ten sposob rozbijac. Co mi daje taki zwykly kontener ? Jakos nie bardzo to do mnie przemawia

Obiekty różnych typów zajmują się różnymi rzeczami. Zawsze powinieneś starać się doprowadzić do tego by jeden obiekt zajmował się tylko jedną rzeczą. Reprezentowanie danych z bazy danych (obiekt User) i zarządzanie takimi "reprezentantami" (obiekt UserManager) to dwie zupełnie inne sprawy. Oba te obiekty wykonują zadania kompletnie nie związane ze sobą. Dlatego też muszą to być osobne obiekty.

Jaka jest wtedy roznica ? Nie do konca widze...

Pobierając obiekt z singletona, tworzysz "z dupy zależność" (jak to sobie zawsze określam). Poczytaj wątki o Dependency Injection [Container] (DI[C]) bo wałkowanie tej dyskujsji po raz n-ty jest męczące. W skrócie: może sam jeszcze nie dostrzegasz tego, ale to same problemy.

[rahul]

Obiekty różnych typów zajmują się różnymi rzeczami. Zawsze powinieneś starać się doprowadzić do tego by jeden obiekt zajmował się tylko jedną rzeczą. Reprezentowanie danych z bazy danych (obiekt User) i zarządzanie takimi "reprezentantami" (obiekt UserManager) to dwie zupełnie inne sprawy. Oba te obiekty wykonują zadania kompletnie nie związane ze sobą. Dlatego też muszą to być osobne obiekty.

Ok,staram sie to poukladac w glowie. Powiedz mi wtedy czy dobrze to rozumie :
1)klasa User bedzie zawierac funkcje do wyswielania danych uzytkownika takie jak np: pokaz imie, pokaz nazwisko, poka mail. I generalnie tylko takie.
2)Z tego co tak sobie mysle to wszystkie podstawowe informacje o uzytkowniku mozna przeciez wywolas z jednej funckji ("select * form user WHERE id = $id") zwroci mi tablice badz obiekt i sobie bede juz nim operowal zaleznie od tego co chce pokazac, tak ? Czy niby mam do imienia, nazwiska, maila pisac po osobnej funckji ? Chyba nieee... , co ? W momencie jak zapytanie zwroci mi obiekt mam mam z niego kozystac tak :

[PHP] pobierz, plaintext 
 
$user_o = $User->getUser($id); 
echo $user_o->Name; 
[PHP] pobierz, plaintext 

badz tak :

[PHP] pobierz, plaintext 
 
$user_o = $User->getUser($id); 
echo $user_o['Name']  
[PHP] pobierz, plaintext 

czy jakos inaczej ?
bo chyba nie tak :

[PHP] pobierz, plaintext 
 
$user_o = $User->getUser($id); 
echo $user->getName(); 
[PHP] pobierz, plaintext 

Strasznie duzo seterow geterow bym wtedy musial pisac. Czy moze tak trzeba? Wydaje mi sie ze funckja UserManager powinna je raczj miec.

3)Teraz druga klasa User Manager ona bedzie miala funckje typu Loguj, Edytuj, Rejestruj i bede z niej kozystal tak jak napisal Noidea w jednej z odpowiedzi, tak?

A co do seterow i geterow czy tylko klasa UserManager bedzie je posiadala (setPass, setName) takowe w klasie User nie sa mi chyba potrzebne, prawda ?
no i niektore funckje beda sie chyba powtarzac jak np getUserById($id).

Ten post edytował rahul 22.08.2011, 16:08:53

[Crozin]

1. Coś w ten deseń. Mając przykładowo obiekt User z właściwościami id, email, firstName, lastName możesz mieć metody get/setId(), get/setEmail(), get/setFirstName(), get/setLastName(), getFullName() - w miarę możliwości bardzo proste, podstawowe operacje.
2. Właśnie raczej powinno to być $user->getEmail() itp. Tego pisania wcale nie ma jakoś specjalnie dużo, zresztą pierwsze lepsze IDE, RMB -> Source -> Generate Getters and Setters -> Select All -> OK, i po sprawie.
3. Nie, taki obiekt UserManager powinien mieć co najwyżej metody w stylu save($u), update($u), delete($u), jakieś najbardziej podstawowe pobieranie danych findOne($id), findAll(). Jedynie rzeczy związane z bezpośrednim zarządzaniem "reprezentantami".
Takie rzeczy jak rejestracja czy logowanie to już skomplikowane, wielostopniowe procesy. Przecież takie zalogowanie użytkownika to pobranie danych, sprawdzenie ich poprawności, obsługa błędów, pobranie danych w przypadku podania prawidłowych danych, wykonanie jakiś operacji w bazie danych (typu zapisanie informacji o logowaniu w logach) i przekierowanie użytkownika. Tak mniej-więcej ten proces wygląda w najprostszym wydaniu. Przy jego obsłudze udział bierze wiele różnych obiektów.

A co do seterow i geterow czy tylko klasa UserManager bedzie je posiadala (setPass, setName) takowe w klasie User nie sa mi chyba potrzebne, prawda ?

Gettery i settery spotkasz w całej masie obiektów, bo jest to nic innego jak tylko nazwa dla pewnych konstrukcji w kodzie, bardzo popularnych zresztą. (http://en.wikipedia.org/wiki/Accessor_method)

no i niektore funckje beda sie chyba powtarzac jak np getUserById($id).

Tzn?

PS. OOP ma to do siebie, że jego zalety wychodzą na jaw dopiero w nieco większych projektach. Co więcej by OOP jako takie miało sens konieczne jest by cała architektura była obiektowa. Pięć klas na krzyż nie wystarczy.

Ten post edytował Crozin 22.08.2011, 17:02:24

[rahul]

Dzieki Crozin, szczegolnie za cierpliowac , tak sobie patrze na forum i widze ze juz udzielales po wiele razy tego typu odpoweidzi a jakos nam to do glow tak latwo nie wchodzi.
Mam takie wrazenie ze wlasnie ta moja obiektowka to w zasadzie programowanie proceduralne tylko opakowane w klasy z niektorymi bajerami OOP. Ciezko jest natomiast zrobic kolejny krok do przodu.
Zdaje sobie sprawe ze w wiekszych projektach pewnie ma to sens. Czy zatem myslisz ze i tak warto OOP probowac uzywac w swoich malych stronkach , nawet jak to ma byc 5-10 klas na krzyz ?
A co do Loginu to gdzie zatem taka funkcje, badz rejestracje umiescic jezeli nie w klasie UserManager.
Co do Dependency Injection to zaczalem cos czytac ale bede pewnie niedlugo znow sie odzywal bo znajac sie zrozumie tam cos na opak
elo.

[melkorm]

OOP - sam miałem z tym wiele problemów na początku, ciągłe pytania:

- po co?
- dlaczego ?
- przecież można w jednym miejscu i z głowy
- ale tak mniej kodu
itd. itp.

Na szczęście miałem ten plus że miałem swego typu `mentora` do którego mogłem się zwrócić o każdą duperelę, lecz wciąż pozostawał pewien niedosyt, aspekt nie zrozumienia / nieogarnięcia całości - oświecenie przyszło gdy zacząłem pisać w pierwszym FW autorstwa mojego brata (mentora ;p), na początku wydawał mi się fajny, zacząłem go poznawać, przeglądać kod itp i zacząłem zauważać braki, błędy i problemy aż w końcu zrozumiałem cały organizm, lecz wciąż pozostawał mały niedosyt na temat OOP bo ja tu się uczyć na niedoskonałym dziecku? Więc zacząłem szukać FW który najlepiej implementuje wszelkie wzorce projektowe, a do tego mnie nie ogranicza lecz jest bardziej biblioteką niż samym FW - co dawało mi większość możliwość jego poznania przez odpalenie, konfigurację i badanie zachowań - mowa tutaj o Zend Framework, tak na prawdę dopiero używając tego narzędzia i po przeczytaniu ton materiałów w necie (tutaj duży plus dla Zyx'a za jego blog) i wielu innych forumowiczów których blogi czytam namiętnie szczególnie gdy pojawia się temat z okolic OOP/wzorców projektowych.

Trzeba tutaj także wspomnieć o praktyce, moim zdaniem najlepiej postawić sobie cel by coś napisać i spojrzeć na to z perspektywy osoby która by miała tego używać i ile trudności by to jej sprawiło - ponieważ w większości wypadków im trudniej coś zaimplementować u siebie tym gorszej jakości to jest. Ja osobiście wielokrotnie coś pisałem i przepisywałem to po 3 - 5 razy by osiągnęło swój ostateczny kształt ponieważ w momencie używania zacząłem zauważać braki w implementacji i używalności.

W skrócie: czytać, pisać, pisać, czytać i jeszcze raz pisać.

[rahul]

Taaaa...
wlasnie pisze swojego cms'a po raz 2 i kurde juz widze ze musze cos zmieniac przepisywac i tylko mnie trafia wtedy bo chce to jak najbardziej uproscic.
Fajnie ze miales mentora. Ja niesteyt jeszcze z tych dokumentacji o frame workach nie duzo kumam
Mam zamiar zaczac od Kohany bo chyba z nia bede mial najmniej problemow , potem tylko zend i symphony :]
A co do OOP to gdzie ten Login w ktorej kurde klasie w koncu i rejestracja jezeli nie u uzytkownika anie jego managera. Najgorsze jest to ze moj nauczyciel tlumaczyl to OOP i teraz wszystko jest sprzeczne. Uzywal tego singletona zamiast DI ktorego jeszcze nie do konca ogarnalem i wszystkei funkcje zwiazane z uzytkownikiem walal do uzytkownika bo mowil ze po co sobie komplikowac.

[by_ikar]

Zamiast tworzyć ileś tam tych seterów i geterów, możesz napisać jeden get i jeden set a dane z nich pobierać tak:

Kod

$user = new User();
$user->get('id');
$user->get(array('id', 'first_name', 'last_name'));
$user->set('first_name', 'Janek');
$user->update(array('first_name' => 'Janek', 'password' => 'secret'));
$user->clear('last_name');
$user->clear('last_name', 'hobby');

Moim zdaniem takie podejście mniej więcej, jest lepsze. Powiedzmy że masz z poziomu jakiegoś panelu admina, dodania dodatkowego pola w profilu użytkownika (społecznościówki itp) i w przypadku takim musiałbyś chyba ręcznie dodawać seter/geter do klasy, a tak pobierasz sobie jedną metodą to co ci potrzeba. Ostatnio ktoś się nawet pytał o to na forum. Polecam czytać częściej forum, albo zadawać trafniejsze pytania do wyszukiwarki.

[Crozin]

@by_ikar: Zerowe wsparcie ze strony IDE czy narzędzi dokumentujących. "Wymagająca" implementacja takich metod. Utrudnienia przy nadpisywaniu. Niezbyt to wygodne. Co do przykładu z panelem... nienajlepszy, zakłada istnienie błędnej struktury danych.

[by_ikar]

Nie wiem z jakiego ID korzystasz, ale mój podpowiada mi składnie jeżeli tak tworzę metody. Jest to jedno z rozwiązań. Co w przypadku kiedy ma się powiedzmy 50-70 pól w takim użytkowniku, to wtedy ma mieć 70 takich metod? Nie wiem, może mamy różne podejście, ale dla mnie jest to śmieszne i raczej nie przyjdzie dzień w którym takie coś popełnię.

To albo mu pozostaje magia, co raczej nie daje w żadnym IDE wsparcia, albo klepanie nowych metod jak tylko doda nowe pole. Tak się zastanawiam nad tym co piszesz, i w sumie jednak będę obstawiał przy swoim. W symfony 2 masz container który trzyma masę obiektów, i właśnie w taki sposób się je pobiera/dodaje. Można pobrać dane obiekty w setXXXService/getXXXService tyle że jest to magia i raczej w większości tego co widziałem w symfony, obiekty pobiera się get('xxx') i jak narazie jesteś pierwszą osobą która piszę że jest to złe rozwiązanie. Może i jest. Nie mniej, moje zdanie jest takie, że jest to lepsze, niż magia, czy klepanie za każdym razem nowych geterów/seterów, zwłaszcza w takim obiekcie jak DI.

[starach]

Metody magiczne i po problemie.

[PHP] pobierz, plaintext 
 
/**
 * @property string $sPHPJestKiepskie guzik prawda ale type hinting jest ;)
 */
class Klasa
{
   private $_mojeZajefajneZmienne = array();
   public function __get($var) {
     return $this->_mojeZajefajneZmienne[$var];
   }
   public function __set($var, $val)
   {
      $this->_mojeZajefajneZmienne[$var] = $val;
   }
}
$k = new Klasa();
$k->sPHPJestKiepskie = 'terefere';
[PHP] pobierz, plaintext 

Oczywiście jeszcze powinieneś dodać do tych metod jakąś walidację, ale w sumie to zależy od sytuacji. A metody tworzysz tylko w przypadku wykonania jakiejś operacji na zmiennej.

Edit:

(...) i jak narazie jesteś pierwszą osobą która piszę że jest to złe rozwiązanie. (...)

To ja będę drugą.

Ten post edytował starach 22.08.2011, 23:19:40

[Crozin]

Mając 70 publicznych właściwości w obiekcie get*() vs get('*') jest najmniejszym problemem.
Co do DIC-a z Symfony2... co on ma tutaj w ogóle do tematu? To jest kontener, a Container::get() zwraca element w nim przechowywany. Temat dotyczy operowania na właściwościach obiektu.
Jeszcze co do "dodawania pola"... to tworzy się kontener, do którego możesz sobie wrzucić dowolną ilość nowych pól, a nie modyfikuje kod.

@starach: Jeszcze gorsza i bardziej bezsensowna metoda.

Ten post edytował Crozin 22.08.2011, 23:26:34

[melkorm]

To jeżeli już tym torem idziemy to zrobić to jak ma Zend, czyli dla ActiveRecordu pobiera z metadanych listę pól dla tabelki i jak chcemy coś ustawić co się nie znajduje w tabelce to dostaniemy exceptionem


Ale sam także jestem przeciwnikiem __set i __get lub jakichś ich kopii typu set, get, clear, za miesiąc usiądziesz i będzie "eeee jakie ta tabela miała pola ...", raz wpisać i po problemie moim zdaniem, lub napisać generator co nie jest na prawdę trudne, sam tak robię i po problemie.

[starach]

Hmm, a możecie napisać co wy macie przeciwko tej metodzie? :|

[Crozin]

A po co korzystać z metod magicznych skoro:

[PHP] pobierz, plaintext 
class Abc {
    public $phpJestKiepskie;
}
 
$abc->phpJestKiepskie = 'terefere';
 
class Abc {
    public $params = array();
}
 
$abc->params['phpJestKiepskie'] = 'terefere';
 
class Abc {
    private $params = array();
 
    public set($param, $value) {
        $this->params[$param] = $value;
    }
}
 
$abc->set('phpJestKiepskie', 'terefere');
[PHP] pobierz, plaintext 

Działają równie dobrze, a nie wprowadzają bezsensownych mechanizmów. To, że PHP wspiera metody magiczne* nie oznacza, że trzeba z nich korzystać. Na dobrą sprawę bardzo ciężko jest dla nich znaleźć sensowne zastosowanie poza ratowaniem się przed utratą wstecznej kompatybilności w pewnych przypadkach.

* te prawdziwie magiczne, bo przykładowo konstruktory z magią niewiele mają wspólnego.

[starach]

Jest jeden argument za tym żeby je właśnie stosować. Jest nim podpowiadanie składni, którego próżno szukać w pozostałych dwóch przykładach, które podałeś. Co na dobrą sprawę już zarzuciłeś w poprzednim poście kierowanym do ~by_ikar.

Natomiast różnica między metodą magiczną, a sposobem stosowanym zarówno przez ciebie jak i powszechnym w świecie programistów, czyli pisanie setterów i getterów jako oddzielnych metod jest chyba widoczna na pierwszy rzut oka. Mniej kodu! Zarówno do napisania przez ciebie jak i do sparsowania. Do tego przejrzystość, bo pisząc metodę która zwraca np. Nazwisko, wiesz że musi ona mieć jakiś głębszy sens i służyć do czegoś więcej niż tylko do zwrócenia lub ustawienia zmiennej.

Nie mam nic na dobrą sprawę przeciwko setterom i getterom na zasadach metod, bo w NetBeans wystarczy zrobić listę zmiennych a potem można sobie wygenerować settery i gettery. Niemniej jednak wolę metodę magiczną z wymienionych wyżej względów.

[Crozin]

@starach:
Pierwszy przykład to przykład poprawnie zdefiniowanej właściwości obiektu, bez niepotrzebnych hacków pokroju @param przy deklaracji klasy. Dwa ostatnie to już natomiast (bez)pośrednie odniesienia do kontenera będącego właściwością obiektu.
Swoją drogą nie wydaje Ci się śmieszne jawne zadeklarowanie w dokumentacji, że obiekt ma jakąś właściwość, po czym celowo jej nie zdefiniować tylko po to, żeby zaraz po tym napisać obejście w postaci metod magicznych __get() i __set() rozwiązujących problem niezdefiniowanej właściwości. Dlaczego po prostu chcąc mieć właściwość dla obiektu nie zdefiniujesz jej?

Natomiast różnica między metodą magiczną, a sposobem stosowanym zarówno przez ciebie jak i powszechnym w świecie programistów, czyli pisanie setterów i getterów jako oddzielnych metod jest chyba widoczna na pierwszy rzut oka. Mniej kodu! Zarówno do napisania przez ciebie jak i do sparsowania.

Co z tego, że mniej kodu, skoro mniej znacznie gorszego pod względem wydajności czy łatwości modyfikacji kodu? Ten durny kod natomiast możesz sobie w łatwy sposób automatycznie wygenerować, zresztą jego napisanie zajmuje co najwyżej minuty co przy kilkuset godzinach spędzonych nad projektem nie jest zbyt przytłaczające. A o parser się nie martw... kilka dodatkowych bajtów mu nie zaszkodzi.

Do tego przejrzystość, bo pisząc metodę która zwraca np. Nazwisko, wiesz że musi ona mieć jakiś głębszy sens i służyć do czegoś więcej niż tylko do zwrócenia lub ustawienia zmiennej.

A korzystając z obiektu interesuje mnie wyłącznie jego interfejs. Implementacja metody (w ogóle całego obiektu) jest nieistotna.

[melkorm]

Jestem absolutnie za Crozin'em, wchodząc w źródło klasy wolę zobaczyć masę setterów i getterów niż dwie magiczne metody które nic mi nie mówią, w dodatku załóżmy że będziesz musiał coś dodać przy ustawianiu jakiegoś pola np. $foo->bar, tak to korzystałeś z __set i się automatycznie ustawiało i teraz cały kod musisz przelecieć tam dgzie to ustawisz by to poprawić, a tak dopisujesz w metodzie setBar i tyle, to sam otyczy się getBar vs $foo->bar.

Ogólnie nie lubię metod magicznych i ogólnie widać trend odchodzenia od nich przez głównych graczy np Zend'a (wersja 2.0) .