[PHP] OOP - pytanie o konstruktor, __construct - możliwie najprostszy czy może być rozbudowany? Opcje

[kreatiff]

Witam. Zaczynam raczkować w OOP, i natrafiłem na taką wątpliwość.
Czy mógłbym prosić o prostą wykładnię, które podejście jest bardziej "prawidłowe" dla poniższego przykładu (o ile którekolwiek jest prawidłowe (IMG:style_emoticons/default/wink.gif) )?
Chodzi mi o to, czy dla zasady konstruktor powinien być możliwie jak najmniej skomplikowany i dalsze zadania na atrybutach powinno się wykonywać w osobnych metodach, czy nic nie stoi na przeszkodzie, by już w konstruktorze wykonywać działania?

Co lepsze? Ta klasa:

[PHP] pobierz, plaintext 
class A {
	private	$zmienna = '';
	private $info = '';
 
	public function __construct($zmienna) {
		$this->zmienna = $zmienna;
		$this->info = $info;
		if ( $this->zmienna == 'test' ) $this->info = 'ok';
		else $this->info = 'coś nie gra';
	}
 
	public function wyswietl() {
		return $this->info;
	}
}
[PHP] pobierz, plaintext 

czy może ta klasa:

[PHP] pobierz, plaintext 
class A {
	private	$zmienna = '';
	private $info = '';
 
	public function __construct($zmienna) {
		$this->zmienna = $zmienna;
		$this->info = $info;
	}
 
	private function sprawdz() {
		if ( $this->zmienna == 'test' ) return 'ok';
		else return 'coś nie gra';
	}
 
	public function wyswietl() {
		return $this->sprawdz();
	}
}
[PHP] pobierz, plaintext 

Proszę nie zwracać uwagi na bezsensowny przykład, możliwy do rozwiązania w 1 linijce w sposób proceduralny. No chyba, że za pomocą klasy ten problem powinien być rozwiązany w kompletnie inny sposób. Wynik końcowy ma za zadanie zwrócić 'ok', albo 'coś nie gra', w zależności od parametru początkowego przy tworzeniu obiektu klasy A.

[PHP] pobierz, plaintext 
$a = new A('test');
echo 'Info: '. $a->wyswietl(); // wyświetli 'ok' 
[PHP] pobierz, plaintext 

[Sephirus]

Nic nie stoi na przeszkodzie by sprawdzać niektóre rzeczy w konstruktorze o ile nie jest za dużo. Nie ma ogólnych zasad co do tego co powinien robić konstruktor poza tym, że ma spełniać rolę inicjowania obiektu i wykonania działań wymaganych do poprawnego działania klasy.

Z punktu widzenia wydajności jednak dużo lepiej jest jeśli ograniczy się rolę konstruktora do minimum a nawet pójdzie w stronę leniwości. W twoim przykładzie (jest on wzorcowy wręcz) druga opcja jest prawidłowa - dlaczego? Dlatego że sama klasa po załadowaniu nie musi mieć informacji o tym czy jakieś info jest ok czy nie. W momencie odwołania powinno to być sprawdzane tak jak w przykładzie drugim.

Nie jest to jednak taka oczywista oczywistość i wszystko zależy. Bo jeśli będziesz się odwoływał do tej metody sprawdzającej bardzo często (kilka razy na odpalenie skryptu) to lepiej przerzucić to do konstruktora. Ewentualnie zapisać stan po pierwszym odpytaniu i dalej zwracać już zapisany stan (leniwość).

Musisz sam wyczuć jaką drogą pójść (IMG:style_emoticons/default/smile.gif)

Jeśli masz klasę, która jest spora i odwołujesz się rzadko do jej metod - staraj się aby dane metody posiadały więcej kodu - wówczas jeśli nie zostaną wywołane uzyskasz na wydajności.

W przypadku gdy masz klasę w której non-stop odpytujesz jakąś metodę lepiej przygotować jej dane na początku i przeliczać ewentualnie te, które muszą być przeliczone (na przykład jak się poda jakieś argumenty).

A teraz prosty przykład.

Klasa obsługi bazy danych.

Pytanie czy w konstruktorze powinno się tworzyć połączenie z bazą?

Załóżmy że tak. Wówczas w jakimś modelu na przykład zawsze na zaś masz gotowy obiekt obsługi bazy nawet jak z niego nie korzystasz. Po co więc się łączyć?

W takim razie łączmy się z bazą przy pierwszym odpytaniu jakiejś metody obiektu. Zyskamy tyle, że jak baza nie będzie odpytywana nie będzie połączenia. Co stracimy? To że przy każdej metodzie musimy sprawdzać czy jest połączenie bo jeśli nie ma musimy się najpierw połączyć.

Nie ma prostej odpowiedzi (IMG:style_emoticons/default/smile.gif) Wszystko zależy od tego w jaki sposób będziesz to wykorzystywał. Szkoda że PHP nie udostępnia leniwych funkcji itp... to by się przydało (IMG:style_emoticons/default/smile.gif)

Ten post edytował Sephirus 28.11.2012, 16:55:38