Witam,
przeczytałem artykuł ze strony głównej pt. 'Budowa interfejsów bazodanowych' i zaintrygowała mnie kwestia dziwnych funkcji zawartych w umieszczonych tam klasach. Z resztą widziałem podobne w innych artykułach.

Przytocze tutaj taki przykład z sekcji artykułu zatytułowanej 'Składamy wszystko w całość'.

[PHP] pobierz, plaintext 
<?php
/* Notes:
   $db	- instance of ADOdb connection object.
   $user  - instance of the User DB Interface
   $topic - instance of the Topic DB Interface
*/
$db->StartTrans();
 
// update the user's total # of posts
$user->setNumPosts($user->getNumPosts() + 1);	  // PRZYKŁAD
$user->submit($db);								// PRZYKŁAD
 
// update the topics # of messages
$topic->setNumMessages($topic->getNumMessage() + 1);
$topic->submit($db);
 
// create the new message
$message = new Message();
$message->setTopicID($topic->getTopicID());
$message->setTopic($_POST['userTopic']);
$message->setMessage($_POST['message']);
$message->setPoster($user->getUserID());
$message->submit($db);
 
$db->CompleteTrans();
 
?>
[PHP] pobierz, plaintext 

Jaki jest sens używania tego typu funkcji jak tutaj: setNumPosts(), getNumPosts(), submit() ?
Wydaje mi się że kod:

[PHP] pobierz, plaintext 
<?php
$user->setNumPosts($user->getNumPosts() + 1);
$user->submit($db);
?>
[PHP] pobierz, plaintext 

Można z powodzeniem zapisać tak:

[PHP] pobierz, plaintext 
<?php
$user->numPosts += 1; // przyjmujac ze w konstruktorze do zmiennej $numPosts wczytywana jest ilsoc posto
w uzytkownika
?>
[PHP] pobierz, plaintext 

A później w destruktorze wysyłać do bazy zgromadzone przez cały czas działania skryptu dane.

Pozdrawiam.

Settery udostepniają mozliwośc np. walidacji danych przed dalszymi akcjami np.:

[PHP] pobierz, plaintext 
<?php
$client->setEmail('name@domain.com');
?>
[PHP] pobierz, plaintext 

a definicji klasy:

[PHP] pobierz, plaintext 
<?php
public function setEmail($email)
{
	if (Filter::isEmail($email) !== true) {
		throw new ClientException('e-mail is not valid');
	};
}
?>
[PHP] pobierz, plaintext 

Nie do końca, ponieważ często zachodzi potrzeba operacji na danych które powinny zostać uakualnione, jeżeli były to destruktor to różnie to bywa. Pisanie za każdym rażem unset" title="Zobacz w manualu php" target="_manual() też nie jest najlepszym pomysłem, dlatego właśnie stosuje się te metody.

Wspomne tylko jeszcze, że php udostepnia bardzo ubogi mechanizm dotyczący właściwości klasy.

@LBO: Mozna by próbować osiągnąć efekt o którym piszesz, korzystając z magicznej metody __get(), tylko sam nie wiem, jak z zwracaniem wyjątków (z tego co pamiętam to działają aż miło )

Oczywiście, że można używać magiczne metody, ale:
1. Operacje dodatkowe mogą się od siebie różnić, czyli trzeba by było pokombinować nad rozpoznaniem argumentów.
2. Czy to by były magiczne metody czy wklepane hardcoded nie ma znaczenia - idea ta sama, by uzywać gettery i settery. Temat i objętość artykułu po prostu nie pozwalał na zajęcie się tym i opisanie.

@hwao

Mowisz i masz

[PHP] pobierz, plaintext 
<?php
 
class User
{
  private static $_aProprietes = array();
 
  public function __construct() {
	$this->_aProprietes = array('Email' => 'info@domain.com',
								 'Name'  => 'No name');
  }
 
  private function _setEmail($sEmail)
  {
	if (Filter::isEmail($sEmail) !== true) {
		throw new ClientException('e-mail is not valid');
	};
	$this->_aProprietes['Email'] = $sEmail;
  }
 
  private function _getName()
  {
	return 'My name is ' . $this->_aProprietes['Name'];
  }
 
  public function __set($sProperty, $mValue){
	if(method_exists($this, '_set'.$sProperty)) {
	  call_user_func(array($this,'_set'.$sProperty), $mValue);
	  return true;
	}
	if(!array_key_exists($sProperty, $this->_aProprietes)) {
	  throw new Exception('Undefined property '.$sProperty.'!');
	}
	$this->_aProprietes[$sProperty] = $mValue;
	return true;
  }
 
  public function __get($sProperty){
	if(method_exists($this, '_get'.$sProperty)) {
	  return call_user_func(array($this,'_get'.$sProperty));
	}
	if(!array_key_exists($sProperty, $this->_aProprietes)) {
	  throw new Exception('Undefined property '.$sProperty.'!');
	}
	return $this->_aProprietes[$sProperty]
  }
}
 
$oU = new User();
$oU->Name = 'Bond';
$oU->Email = 'bond@domain.com';
 
echo $oU->Master;
echo $oU->Email;
 
?>
[PHP] pobierz, plaintext 

No, i dobrze, bardzo ładnie BigZbig, ale pomimo tej całej otoczki fancy-oprogramowania to nadal to samo, nie uważasz?. Jak dla mnie temat zamknięty, bo jednoznacznie odpowiedzieliśmy czemu metody, a nie bezposrednia aktualizacja zmiennych.

Settery i gettery to w zasadzie jeden z ważniejszych przystanków na drodze ku dobrej hermetyzacji klas. Jak teraz sobie myślę, że ktoś mógłby swoimi brudnymi, obleśnymi łapskami dotykać moich składowych, to mi niedobrze. Interfejs musi być!!!

nie zapominajmy o ppp. składowe mozna okreslic jako private i juz nikt brudnymi łapskami nic nie zrobi z tym czego nie powinien dotykać.

Klas sie nie hermetyzuje. Hermetyzuje się dane.

Fakt. Dane, nie klasy. Dzieki za zwrócenie uwagi

z tego co pamietam to w php5.1 takie cos

[PHP] pobierz, plaintext 
<?php
call_user_func(array($this,'_get'.$sProperty));
?>
[PHP] pobierz, plaintext 

Nie przejdzie

Swoja droga to mysalem o troche innym rozwiazaniu mianowiscie
$Obiekt-><filtr><wlasciwosc>
W wyrazeniu reg. zlapac oco chodzi i odpowiednio przekazac

Np:
$Object->intId = 'string';

Obiekt rozpozna ze int i poleci do

[PHP] pobierz, plaintext 
<?php
private function Integer( $mValue ) { 
  return (int) $mValue;
}
?>
[PHP] pobierz, plaintext 

A potem do wlasciwosci

Zawsze możesz użyć funkcji method_exists

Twoja propozycja rozwiazanie jest malo elastyczna bo ogranicza sie jedynie do rozpoznawania typow.

mozesz sobie napisac inne typy, ja tylko napisalem najprostrzy

Czyli jednoznacznie hermetyzacja?
A co mam zrobić w przypadku dużej ilości zmiennych w których zapisane są zwykłe liczby, które nie potrzebują jakiś hermetyzacji ze względu na to, że nie są 'zagrożone' niepożądanymi wynikami wpisywanymi przez użytkownika. Też tworzyć dla każdej takie dodatkowe funkcje ?

Ewentualnie stworzyć tablice typu $liczby i funkcje dla tej tablicy ?

@MagnuM - niedajmy sie zwariowac. Co prawda ogolnie rzecz biorac zalecane jest definiowanie wlasciwosci jako chronione lub prywatne, ale nie jesli ma to byc sztuka dla sztuki. W koncu poto wymyslono klauzule public aby ja stosowac.

Czyli trzeba to wyważyć, nieprawdaż. Okreslać zmienne jako publiczne, gdy nie trzeba walidować. W przeciwnym razie private i ustawiać setter.

Wszystko jasne, dzieki za odpowiedź.