Witam!

Chcialbym poznac Wasza opinie na temat zwyczaju holdowanego przez czesc programistow, a mianowicie tworzenia metod typu

[PHP] pobierz, plaintext 
<?php
class testClass{
 
	public $property;
 
	getProperty(){
		return $this->property;
	}
 
	setProperty($property){
		$this->property = $property; 
	}
}
?>
[PHP] pobierz, plaintext 

Czy czesto to stosujecie i jakie macie z tego korzysci?
Oczywiscie to dosc eleganckie, zawsze mozna dopisac jakies warunki sprawdzajace poprawnosc danych itp.
Ale z drugiej strony pewnie rzadko te metody zostaja rozbudowane ponad schemat, ktory podalem wyzej (brak czasu i/lub checi), a czy bez dodatkowego kodu to ma sens? Napisanie tych funkcji to zmudna praca, mozna ja sobie czasem ulatwic za pomoca jakiegos generatora, ale tez nie dla kazdej wlasciwosci taka metoda jest sensowna. Poza tym, obecnosc wielu metod tego typu w klasie pogarsza troche czytelnosc jej kodu i odwraca uwage od metod naprawde istotnych.

Jesli mamy do czynienia z wazna klasa , ktora jest podstawa dla polowy aplikacji (albo bardzo uniwersalna, ktora bedziemy wielokrotnie uzywac w innych projektach), albo z jakimis kluczowymi wlasciwosciami, to mozna sie pokusic o metody ktore elegancko pobiora lub ustawia te wlasciowosci.
Ale czy zawsze jest sens sie w to bawic?

Ciekaw jestem Waszych opinii...

U mnie ilośc własciwosći publicznych jest znikoma. Tak wiec problem "nieczytelnosci" kodu tym spowodowany odpada. Natomiast własciwosci prywatne zmieniam bez tch wszystkich setterow.
IMHO zbyt dużo zmiennych w klasie świadczy o złym zaprojektowaniu klasy

PHP5 dostarcza __get i __set i jak przetestował Bastion są szybsze od settów i gettów Więc też ich używam ;] Z resztą menic: dużo zmiennych wcale nie świadczy o złym zaprojektowaniu, ale pewne klasy muszą je niestety mieć

Settery tego typu są brzydkie jak dla mnie. Zdecydowanie wolę wymienione przez Turgona magiczne właściwości __set i __get. Są znacznie czytelniejsze. Przykład kodu, jaki lubię stosować:

[PHP] pobierz, plaintext 
<?php
class Test {
  private $_data = array();
  public function  __set($key, $value) {
	if (method_exists($this, '__check_' . $key)) {
		if (call_user_func_array(array($this, '__check_'.$key), $value)) {
			$this->_data[$key] = $value;
		} else {
			throw new Exception('nieprawidłowa wartość');
		}
	} else {
		$this->_data[$key] = $value;
	}
  }
  public  function __get($key) {
	if (isset($this->_data[$key])) {
	  return $this->_data[$key];
	} else {
	  throw new Exception('brak właściwości');
	}
  }
  public function __tostring() {
	  return sprintf('%s: %s', get_class($this), print_r($this->_data, 1));
  }
  public function __check_c($data) {
	  return is_numeric($data);
  }
}
?>
[PHP] pobierz, plaintext 

Użycie:

[PHP] pobierz, plaintext 
<?php
$test = new Test();
$test->a = 'a';
echo $test->a;
echo '<br />';
$test->b = 'b';
echo $test->b;
echo '<br />';
$test->c = '123';
echo $test->c;
echo '<br />';
try {
	$test->c = 'ass';
	echo $test->c;
} catch (Exception $m) {
	print 'Jakiś problem: ' . $m->getMessage();
}
echo '<br />';
echo $test;
?>
[PHP] pobierz, plaintext 

Oczywiśćie to powyżej to tylko bardzo prosty przykład, który wymaga dopracowania i rozbudowania, ale pokazuje jakie fajne możliwości tkwią w magicznych właściwościach :) Oraz, że zwykłe settery, w postaci znanej z Javy (setVar, getVar) są do tyłka... ;)

Hah no świetnie, OOP polega na pisaniu jak najbardziej rozszezalnego kodu wiec lepiej sobie zrobic setZmienna() i getZmienna(), bo za miesiac okaze sie ze do class :: $zmienna ludziska wrzucaja wam śmiecie i potrzeba zrobić walidowanie danych przed zapisaem do zmienniej. Wlasnie przy samym zapisywaniu w klasie. Przyklad wyuskany, ale jak najbardziej pasuje do tego posta.

Settery w Javie (jak i cała koncepcja JavaBeans) powstały na długo przed pojawieniem się PHP5 zatem krytykowanie Javy, za to, że nie ma metod "magicznych" mija się z celem.
Jest to przede wszystkim język statyczny, gdzie w chwili kompilacji powinna być znana już nazwa wykonywanej metody. Wywołania dynamiczne można zrealizować tylko przy pomocy Reflection API.
To nie jest PHP, gdzie możesz sobie bez jakichkolwiek konsekwencji skleić nazwę funkcji i zrobić $bar($foo) i $bar->$foo = $baz. Nie zapominaj o tym w swych ocenach. Na getterach możesz zbudować bardzo złożone mechanizmy - a klasy zaprojektowane w ten sposób bez problemu użyć do wyklikania interfejsu użytkownika w NetBeans (wskazane dodanie PropertyDescriptora). Nie musisz również bawić się z obserwatorami - wystarczy użyć PropertyChangeSupport i zaimplementować interfejs PropertyChangeListener w zależnym obiekcie.
W get/set z czasem coraz częściej pojawia się dodatkowy kod, od chociażby w celu poinformowania listenerów o zmianie w obiekcie ..
Pisząc w JSP możesz bez problemu korzystać z ${obj.property}, co w wyniku, po skompilowaniu do servletu da Ci obj.getProperty().

Jako ciekawostkę dodam, że w Javie 7 pojawią się prawdopodobnie bloki, w których będzie się deklarować property dostępne via get/set.

@splatch: pojęcie kontekstu wypowiedzi jest Ci obce? mało mnie interesuje Java, napomknąłem o niej tylko w kontekście tego, że to właśnie ten język upowszechnił taki zapis setterów i getterów. PHP5 daje znacznie wygodniejsze możliwości, których prosty i nierozbudowany przykład podałem. Nie mówiąc o tym jak wygodnie jest to rozwiązane w Pythonie czy C#, ale to już drobny szczegół...

Setery i getery pozwalają ba na bardzo szczegółową kontrolę dostępu do pół oraz metod obiektu. Są też najlepszym sposobem na walidację danych.

Dostęp za pomocą metod magicznych to głupota, nic nie daje a ogranicza w kilu rzeczach. Nie zrobisz kontroli dostępu walidacji i innych takich rzeczy.
A najgłupszą rzeczą jest to że takie rozwiązanie wymusza trzymanie wszystkich danych w tablicy. Chore, po to są pola, żeby każde trzymało coś innego a nie jedna wielka tablica, która jest rozwiązaniem wolnym i niewygodnym oraz nie możliwym d udokumentowania.

mike_mech, a kto tak powiedział ?

[PHP] pobierz, plaintext 
<?php
class example{
	protected $var = '';
 
	public function __set($name,$value){
		if(!isset($this->{$name})){
			throw new Exception('Wartość '.$name.' nie istnieje, więc nie może być edytowalna!');
		}
		$this->{$name} = $value;
	}
 
	public function __get($name){
		if(!isset($this->{$name})){
			throw new Exception('Wartość '.$name.' nie istnieje, więc nie może być pobierana!');
		}
		return $this->{$name};
	}
}
try{
 
$o = new example();
 
$o->var = 'Jakieś tam bzdury!';
 
echo $o->var;
 
$o->inna = 'Dupa'; 
}
catch(Exception $e){
	echo $e->getMessage();
}
?>
[PHP] pobierz, plaintext 

Otrzymuje to co chciałem. Banalną kontrolą dostępu jest nie dodawanie setterów do zmiennych nie publicznych, które mają być nie edytowalne, a zmienne edytowalne jako publiczne. Też kto Ci zabronił używania obiektów kolekcji? Wolna amerykanka... Za to uwielbiam PHP.

EDIT:
Poprawiłem przykład. I dałem jeszcze prostszą kontrolę choć wymaga pewnych nawyków =] Np. dawania na początek zmiennym edytowalnym pustej wartości =]

@mike_mech: a mówiłem że przykład jest prosty i potrzeba go rozbudować...
Turgon podał jeden z przykładów jak można zrobić rozdzielenie pól, żeby nie trzymać wszystiego w tablicy. A tablicę taż można w prosty sposób udkokumentować, wystarczy chcieć. Już lepiej by było gdybyś napisał że wg Ciebie fajniejsze jest używanie metod set() i get(). Chyba że napiszesz coś konkretnego w kontekście anty.

Co do walidacji: przecież w moim przykładzie było pokazana i zaimplementowana walidacja, patrzyłeś w ten kod? (hint: spróbuj w moim przykładzie podstawić do zmiennej 'c' wartość nie numeryczną).

Plusem korzystania z metod magicznych jest czytelność w używaniu kodu. Nie interesują Cię żadne metody, korzystasz z naturalnego przypisywania i pobierania wartości zmiennych. Nie znam przypadku w którym magiczne __set() i __get() nie zastąpiłyby z powodzeniem starych set() i get(). Za to właśnie pojawia się wspomniana już przeze mnie naturalność używania kodu.

Nie musisz tego lubić, nie musisz używać, ale proszę użyj jakiegoś argumentu który ma rzeczywiste podstawy, a nie takiego który można obalić w ciągu kiliku minut po jakimś zastanowieniu się.

I apropos walidacji. Można to jeszcze prościej. Klasa dziedziczy po Validatorze . W ten sposób otrzymuje jego metody do walidacji i po robocie
Banalny przykład:

[PHP] pobierz, plaintext 
<?php
interface iValidate{
	public function valid($var);
}
 
class Validator implements iValidate{
	public function valid($var){
		if(ctype_alpha($var)){
			return true;
		}
		return false;
	}
}
 
class Example extends Validator{
	protected $var = '';
 
	public function __set($name,$value){
		if(!$this->valid($name)){
			throw new Exception('Nazwa "'.$name.'" nie przechodzi walidacji, więc zmienna nie może być edytowana!');
		}
		if(!isset($this->{$name})){
			throw new Exception('Wartość "'.$name.'" nie istnieje, więc nie może być edytowalna!');
		}
		$this->{$name} = $value;
	}
 
	public function __get($name){
		if(!$this->valid($name)){
			throw new Exception('Nazwa "'.$name.'" nie przechodzi walidacji, więc zmienna nie może być pobierana!');
		}
		if(!isset($this->{$name})){
			throw new Exception('Wartość "'.$name.'" nie istnieje, więc nie może być pobierana!');
		}
		return $this->{$name};
	}
}
try{
 
$o = new example();
 
$o->var = 'Jakieś tam bzdury!';
 
echo $o->var;
 
$o->inna1 = 'Dupa'; 
}
catch(Exception $e){
	echo $e->getMessage();
}
?>
[PHP] pobierz, plaintext 

No bez jaj. Toż to głupota.
A jeśli moja klasa to Samochód dziedzicząca po Pojazd ?
Dorzucanie takich mechanizmów za pomocą dziedziczenia to efekt niezrozumienia idei obiektowości i dziedziczenia.

mike_mech: Nie obchodzą mnie idee. To ma działać szybko i jak należy. Jak chcesz być tak bardzo obiektowy. Dodaj mechanizm dodawania walidatorów

@Turgon: tutaj się przyłączam do mike_mech: średnie rozwiązanie. chcesz w ten sposób robić osobne klasy do sprawdzania każdej właściwości? Czy też różne interfejsy? Bez sensu. To akurat lepiej jest zrealizować w poszczególnych metodach.

Ja osobiście uważam, że metody __get i __set są raczej kiepskim wyborem. Jak dla mnie są bardzo nieczytelne - zawsze uważałem, że klasa jednoznacznie musi definiować swoje API - jeśli mam dość skomplikowaną klasę z kilkoma polami różnego typu to wkrada się tam zbyt duża komplikacja - zbyt dużo if'ów itp. W zasadzie tylko kilka razy udało mi się znaleźć rozsądne zastosowanie do metod magicznych - w większości przypadków preferuje zwykłe setZmienna() i getZmienna() gdyż od razu widze, które pola były przewidziane do publicznego dostępu. Choć w początkowej fazie narzuca to więcej bezsensownego klepania to potem jest znacznie wygodniejsze w użytkowaniu i łatwiejsze w dokumentacji.

Mysz: Rozwiązanie najprostsze =] Pisane z palca Bez konkretnego zastosowania. Ja inaczej to rozwiązuje u mnie w klasach Z resztą __set i __get są niesamowicie przydatne przy interfejsie obiektowym np. dla danych usera

@athabus: właśnie w tym rzecz: Ty stawiasz na czyelność kodu, ja stawiam na elegancję i naturalność używania. No i kwestia tego, że dla mnie taki szkielet jak zaprezentowałem na początku jest czytelny i nie narzekam, ale to już indywidualna kwestia :)

@Turgon: Ja nie neguję używania metod magicznych, wręcz czasem je nadużywam, ale są dla mnie niezmiernie wygodne. Chodziło mi tylko o metodę walidacji przedtsawiona przez Ciebie powyżej :)

WOW. Dobra to powiedz mi ile tych cennych 0,0001 sek. tracisz i ile takich wielkich projektów napisałeś żebyś musiał aż tak oszczędzać na czasie, co bardziej jest niewygodną niż oszczędnością ?

Ja preferuje metody getXXX setXXX. Bardzo zwieksza czytelnośc kodu. Ale nie jestem też przeciwnikiem metod magicznych. Co jedne bedzie dobre w konkretnym przypadku, to drugie niekoniecznie. Trzymanie sie na siłe jednego, jest ble

Strzałek: No-comment Dla mnie to jest prostsze. Jak chce pisać coś czytelniejszego niż kodzik na kilka godzin, to piszę w innym stylu.

Nie wiem czy wiecie ale w pewnym języku jest to rozwiązane IMO dużo lepiej niż w PHP

Moim zdaniem genialne rozwiązanie i bardzo mi tego brakuje w pehapie, natomiast w owym języku brakuje mi magicznych __get i __set do wyłapywania odwołań do nieistniejących zmiennych.
Było by idealnie połączyć obie metody.

@DjKermit: w jeszcze innych językach jest to też zupełnie inaczej rozwiązane, i też dobrze działa. Ale to bodajże forum PHP?

To napisz do Zend'a żeby wykorzystali tą metodę, wtedy będzie na temat.
A ja myślałem że rozmawiamy o setter/getter.
Jak Cię nie interesuje mój post, to go pomiń i nie czytaj, nie pisałem tylko do Ciebie.

No to widze, ze zdania sa bardzo podzielone
Osobiscie mam wrazenie, ze wszystko zalezy od konkretnej sytuacji i od tego, jakie jeszcze dodatkowe zadania chcielibysmy wykonywac przy okazji pobierania/ustawiania wlasciwosci.
Jestem jednak raczej przeciwnikiem klepania setterow i getterow wszedzie gdzie popadnie. Czesto chyba lepiej ich nie tworzyc, a jesli zajdzie potrzeba to dopisac __set() i __get().

Mysz napisal:

Tak z ciekawosci, mozesz rzucic przykladem? Sam napisales ze to forum PHP, ale dobrze czasem porownac jak robi sie rozne rzeczy gdzie indziej.

Rozwiązanie rodem wyciągnięte z pięknej Javy. Popieram przedmówcę, jednak sposobów programowania jest tyle co samych programistów..

E, nie chciałem żebyś tak to odebrał, chciałem nakierować dyskusję na bardziej pehapowe tory :/



Python na to pozwala :) Ale to też offtopicznie... ;)



Python ma funkcję property() (przykład pod linkiem), a w C# mniej więcej (podobnie jak w przykładzie podanym przez DjKermita):


Pozwala to na rozdzielenie walidacji na różne funkcje bez cyrkowania i sprawdzania czy jest jakaś metoda w klasie. Oczywiście jest też możliwość (przynajmniej w pythonie, nie mam pewności czy też w C#) na wyłapywanie nieistniejących właściwości, i robienie z nimi tego samego co przedstawiłem wcześniej w przykładzie dla PHP.

Jeżeli chodzi o "wyłapywanie" nieistniejacych metod wystarczy __call() i bedzie to samo

Ja jeszcze czasami używam czegoś takiego

[PHP] pobierz, plaintext 
<?php
class Foo {
 
	private $foo;
 
	public function foo($value = null) {
		if (! is_null($value)) {
			// filtry
			$this->foo = $value;
		}
		return $this->foo;
	}
}
?>
[PHP] pobierz, plaintext 

Hmmm... Jakoś ja nie widzę problemu. Można przecież zrobić __get i __set, a w nich sprawdzać tylko czy do danej zmiennej można się odwołać i wykonuje getXXX albo setXXX, gdzie jest reszta dokładne sprawdzanie czy podane są dobre dane itp. dodatkowo __call i jazda. I wtedy można i $obiekt->zmienna i $obiekt->getZmienna()

Cały kłopot jest w tym kto w czym zaczął programować i jak podatny jest na zmiany.
Bo w Java nie ma możliwości wykonania jakiś operacji przy odwołaniu do zmiennej, dlatego stosuje się setZmienna() i getZmienna(), a że czasem później się okazują potrzebne to się daje od razu wszędzie 'na wszelki wypadek', bo potem przy zmianie interfejsu klasy trzeba było by przerabiać kod wszędzie gdzie są odwołania do tej zmiennej.
Tu PHP ma plusa (nie tak jak wspomniany Python) bo możemy to kontrolować, i można dodać to później, a nie będzie miało to wpływu na resztę kodu, co jest chyba jednych ważniejszych rzeczy?

Dlaczego uważam za zbędne, a nawet nie wskazane, używanie getZmienna(), setZmienna() bo tworzy to sztuczne metody, do tego czasem niewykorzystywane. Tworzyć na przód takie metody, bo mogą być potrzebna, tworzy nadmiarowy kod. Dzięki __set() i __get() mamy możliwość wprowadzania sprawdzenia, do tego nie widocznego przy użyciu.

To co napisał Hacker można użyć, do produkcji "deprecate", bo ostatecznie powinno się przejść na __get() i __set().
Ale to moja opinia, ilu programistów... ale radził bym się zastanowić, bo podejście 'mi się to nie podoba, więc jest złe' jest takie trochę dziecinne.

A to bardzo ciekawe, bo __get jest wykonywane TYLKO wtedy gdy wywołany atrybut NIE istnieje.

Lub jest niewidoczny (private, protected)

Hacker mnie uprzedził
Czyli wystarczy zmienić z public na protected lub private i już przejmują obsługę __set(), __get(), __unset() i __isset(). Tak wiec niczym się nie różni od np. getZmienna() bo ta Zmienna też musiała być niewidoczna.

OK, to zwracam honor i ubolewam nad moją niewiedzą.

Powiązane z tematem, bo jak sprawdzić czy mamy daną zmienną czy też nie w obiekcie...
Można get_object_vars() czy get_class_vars(), a dlaczego w ogóle nad tym myślałem, bo isset() zwraca false jeśli zmienna jest NULL... Więc nie widzę metody aby sprawdzić czy zmiennej nie ma czy jest ustalona na NULL (oprócz wymienionych get_...).
A co ciekawego zauważyłem, że is_null($this->zmienna) sprawdza w obiekcie zmienną, tylko że jak jej nie znajdzie odpala __get() (czyli jak mamy nadpisane, bo przy domyślnym to nic nie zmienia) i sprawdza co zwraca
To samo isset() [zapewne wszystkie tego typu], sprawdzają przy $this->zmienna, najpierw czy taka zmienna jest jeśli nie, to odpalają zewnętrzne pobieranie zmiennych, czyli nasze nadpisane __get() itd.

Chyba to może być przydatne... ale w praktyce jedynie wyjdzie.

(ciekawe czy się nie zbłaźniłem tym 'odkryciem', jak to już raz zrobiłem)

EDIT literówka

No, cóż... Jakby tu powiedzieć.
Niestety nic nie odkryłeś...
nie is_null($this->zmienna) wywołuje __get (gdy nie znajdzie zmiennej w obiekcie), a samo $this->zmienna (zwłaszcza jeżeli zmienna nie jest obiektem to można się tego łatwo domyślić (PHP przekazuje przez wartość, a nie referencje))

Właśnie mnie coś męczyło, co się okazało, jak zwykle nie doczytaniem w manualu (będę musiał go strona po stronie przeczytać w końcu).
Chodzi przy __set(), bo jak umieszczamy w tablicy to array_key_exists() lub jak chcemy to dodajemy [teraz doczytałem, wiedziałem że musi istnieć] property_exists() czy dana zmienna 'jest w klasie'.
Męczyło mnie to bo ta funkcja nie pojawiała się, a pojawiło isset() które przecież zwróci FALSE jeśli zmienna jest NULL, a przy __set() nie o to nam chodziło.

Ja wszystkie własciwosci, które sa dostepne dla "klienta" wole sobie opakowac w getXXX itp, nawet jesli jest to zwykle return $this->zmienna. IMHO o wiele bardziej zwieksza to czytelnosc kodu i jest "bardziej obiektowe". Wiadomo co do czego. __set, __get to tak jak by małe zerwanie z OO. Ale to tylko moje zdanie

@menic - mam dokładnie takie same odczucia jak Ty - trzeba jasno zdeklarować interfejs każdej klasy. Przy zastosowaniu __set i __get taki interfejs jest nieczytelny - nie wiadomo co ma być publiczne a co prywatne.

Mi brakuje jedynie jakiegoś odpowiednika właściwości z C#, żeby nie trzeba było dla każdej zmiennej publicznie dostępnej walić 2 funkcji.

A ja wlasnie trafilem na sytuacje, w ktorej dostep do wlasciwosci przez getZmienna() i setZmienna() skomplikowalby mi kod korzystajacy z klasy i przysporzyl dodatkowej pracy. Otoz przekazuje dane obiektu do systemu szablonow, ale chce to zrobic w formie tablicy, a nie samego obiektu (zeby mi ktos nie wpisal w szablonie np. $obiekt->delete() ).
No i robie:

[PHP] pobierz, plaintext 
<?php
$tablicaWlasciwosci = get_object_vars($obiekt);
?>
[PHP] pobierz, plaintext 

i po krzyku, mam tablice z publicznymi wlasciwosciami.
Gdybym mial zamiast tego kazda wlasciwosc pobierac za pomoca getZmienna() i przepisywac po kolei do tablicy, to byloby to troche zmudne...
No fakt, mozna uzyc get_class_methods(), za pomoca tego wyciagnac metody z get na poczatku i jakos to zautomatyzowac, ale i tak bardziej mi sie widzi uzycie __get() i __set() tylko w razie potrzeby i dostep do wlasciwosci...

marcini82 to co napisałeś nie jest dla mnie jasne... (może ja nie łapię po prostu) ale wydaje mi się że coś przekombinowałeś.

a nie mozesz zrobic metody getVArray() ktora zwroci tablice z polami ktore chcesz przekazac do szablonu?

Moge, oczywiscie Moge dodac jeszcze 5 innych, tylko gdzies jest granica pomiedzy oplacalnoscia czasu zainwestowanego w kodowanie a sztuka dla sztuki... Jak pisze jakas bardzo uniwersalna klase to ok, moge w nia zainwestowac. Ale jak tworze w aplikacji kolejny obiekt, i kolejny i kolejny, to wolalbym jednak nie klepac w kazdym z nich serii podobnych metod... A niestety gettery i settery i ew. inne poboczne metody sa uzaleznione od wlasciwosci danej klasy i musza byc tworzone indywidualnie...


Po prostu przepisuje publiczne wlasciwosci obiektu do tablicy. W momencie, gdy sa one dostepne tylko za pomoca metod get..(), to jest to odrobine utrudnione i mniej wygodne.

Ale jak kto lubi...

Wiesz ja wiem co robi get_object_vars() mi chodzi co chcesz przez to osiągnąć...

Przekazac do szablonu tablice z wlasciwosciami obiektu. Nie chce przekazac obiektu, zeby nie dawac szablonowi dostepu do jego metod. Wiec przepisuje wlasciwosci do tablicy i przekazuje tablice.
Nie wiem czy to wystarczajaco jasne...

Z zasady pola klasy powinny byc prywatne i nie powinno sie do nich odwolywac bezposrednio lecz przez gettery i settery. Nie spotkalem sie do tej pory z problemem, ktory potwierdzilby ze zasady tej nalezy przestrzegac wiem natomiast ze powinno sie.
Zazwyczaj utworzony obiekt przekazuje do obiektu Smarty, a ten sobie odczytuje pola poprzez {$obiekt->pole} i to jest bardzo wygodne aczkolwiek zgodnie z zasadami hermetyzacji nie powinienem robic tego w ten sposob.

Pomyslalem sobie ... czemu by nie zrobic tak:
- ustawic wszystkie pola jako prywatne
- dopisac do kazdej klasy __get() z kodem:

[PHP] pobierz, plaintext 
<?php
public function __get ($name)
{
	$functionName = 'get' . ucfirst ($name);	
 
	$isDeclared = in_array ($name, array_keys (get_class_vars (get_class ())));
 
	if (! $isDeclared)
	{
		throw new Exception (get_class () . '::$' . $name . ' no such a property');
	}
 
	if (method_exists (get_class (), $functionName))
	{
		return $this->$functionName ();
	}
	else
	{
		throw new Exception ('Cannot access private property ' . get_class () . '::$' . $name);
	}
}
?>
[PHP] pobierz, plaintext 

Oczywiscie do tych wlasciwosci, ktore chce wystawiac na zewnatrz pisze getVar i setVar dzieki czemu hermetyzuje pola ... dodatkowo pisze jeszcze metody dostepu dla ... na przyklad szablonow Smarty.
W ten sposob moglbym odwolywac sie do pol tak jak robie to do tej pory trzymajac sie przy tym zasad hermetyzacji.

Co myslicie na ten temat?

PS: Mike dzieki za przeniesienie

@NoiseMC
A jak to sie ma z wydajnoscia? Poniewaz troche duzo tych funkcji tutaj, get_class, get_class_vars, in_array i tak dalej.
Do tego co się orientowałem(nie sprawdzałem w własnych testach) __get jest wolniejsze ( dzięki splatch ).

I kolejna sprawa, odwolujesz się do metod publicznych poprzez __get, tak? Które zwracają zmienne prywatne? W takim razie po co korzystać z __get? Skoro możesz po prostu użyć $myObject->getName() etc. Bo chyba nie do końca rozumiem Twojej idei.

Jak podejrzewam, że obiekt będzie miał dużo setterów i getterów, to:

[PHP] pobierz, plaintext 
<?php
public function __call($method, $args)
	{
 
		if(!method_exists($this, $method))
		{
 
			$pre=substr($method, 0, 3);
			$post=substr($method, 3);
			$propertyName=lcfirst($post);
 
			if($this->has($propertyName))
			{
				if($pre=='set')
				{
					return $this->setProperty($propertyName, $args[0]);
				}
				if($pre=='get')
				{
					return $this->getProperty($propertyName);
				}
			}
		}
 
		return call_user_func_array(
		array($this, $method),
		$args
		);
	}
?>
[PHP] pobierz, plaintext 

Pozdrawiam.

Chodzilo mi o to zebym mogl z poziomy szablonu wyciagac sobie w ten sposob wartosci pol czyli jezeli wolam {$obj->property} to klasa sprawdza czy ma getProperty (), jezeli ma to z niej korzysta jezeli nie to wyrzuca wyjatek ze zmienna jest prywatna i sio od niej, tak sobie tylko mysle.
Co do wydajnosci, nie wiem czy to ma jakiekolwiek znaczenie ... w koncu nie pisze sterownika, wieksze problemy mialem przy optymalizacji zapytan albo rekurencyjnym przetwarzaniu duzych tablic

Stosunkowo nieinwazyjne dorzucenie walidacji z użyciem metod set/get. Oczywiście pytanie czy walidacja powinna być przesunięta tak nisko, czy też powinny załatwiać ją kontrolery pomijam. To jest po prostu przykład. Warto zauważyć, że jest to coś innego niż Obserwator i nie wymaga implementacji żadnych dodatkowych interfejsów od klasy reprezentującej obiekty biznesowy.

[PHP] pobierz, plaintext 
<?php
final class PropertyChangeEvent {
	private $source;
	private $property;
	private $newValue;
	private $oldValue;
 
	public function __construct($source, $property, $newValue, $oldValue) {
		// przypisanie wartości
	}
}
 
 
// Interfejs dla klas, które są zainteresowane zmianami wartości
interface PropertyChangeListener {
	public function propertyChange(PropertyChangeEvent $e);
}
 
// Typowy mediator pośredniczący w propagowaniu z mian z $source do $listeners
class PropertyChangeSupport {
	private $listeners;
	private $source;
 
	public function __construct($object) {
		// assert $object != null
		if ($object == null) {
			throw new UnknowSourceException();
		}
		$this->source = $object;
	}
 
	public function addListener(PropertyChangeListener $listener) {
		$this->listeners[] = $listener;
	}
 
	public function removeListener(PropertyChangeListener $listener) {
		foreach ($this->listeners as $key => $value) {
			if ($value == $listener) {
				unset($this->listeners[$key]);
			}
		}
	}
 
	public function firePropertyChange($property, $newValue, $oldValue) {
		$event = new PropertyChangeEvent($this->source, $property, $newValue, $oldValue);
	}
}
 
// Tu nasza klasa
class Book {
	private $title;
	private $support;
 
	public function __construct() {
		$this->support = new PropertyChangeSupport($this);
	}
 
	public function setTitle($newTitle) {
		$this->support->firePropertyChange('title', $newTitle, $this->title);
		$this->title = $newTitle;
	}
 
	public function addListener(PropertyChangeListener $listener) {
		$this->support->addListener($listener);
	}
}
 
// Przykład walidacji - w przypadku niepowodzenia leci wyjątek.
class ValidatorListener implements PropertyChangeListener {
 
	public function propertyChange(PropertyChangeEvent $event) {
		if ($event->getProperty() == "title") {
			if (strlen($event->getNewValue()) == 0) {
				throw ValidationException($event->getProperty());
			}
		}
	}
 
}
 
$book = new Book();
$book->addListener(new ValidatorListener());
$book->setTitle("a");
$book->setTitle("");
 
// a tu inny przykład, który można uzyskać
class CompositeValidatorListener implements PropertyChangeListener {
	// Map<String, List<PropertyChangeListener>>
	private $validators;
 
	public function put($property, PropertyChangeListener $listener) {
		if ($this->validators[$property] == null) {
			$this->validators[$property] = array();
		}
		$this->validators[$property][] = $listener;
	}
 
	public function propertyChange(PropertyChangeEvent $event) {
		$prop = $event->getProperty();
		if (isset($this->validators[$prop])) {
			foreach ($this->validators[$prop] as $listener) {
				$listener->propertyChanged($event);
			}
		}
	}
}
 
// Walidacja z użyciem maski
class RegexpValidator implements PropertyChangeListener {
	public function __construct($regexp) {
		$this->regexp = $repexp;
	}
 
	public function propertyChange(PropertyChangeEvent $event) {
		if (!preg_match($this->regexp, $event->getNewValue())) {
			throw new ValidationException($event->getNewValue());
		}
	}
}
 
$composite = new CompositeValidatorListener();
$composite->put('age', new RegexpValidator('/d+/'));
$composite->put('name', new RegexpValidator('/w+/'));
 
$author = new Author();
$author->addListener($composite);
 
?>
[PHP] pobierz, plaintext