Gdzie:

• request - żądanie
• A,B,C - obiekty tworzące łańcuch
• Default - obiekt odpowiadający za zachowanie domyślne, stąd też znajduje się na końcu

Zatem żądanie może zakończyć swoją “wędrówkę” już na obiekcie A, ale równie dobrze może dotrzeć do samego końca hierarchii.

Gdybyśmy mieli odnieść się do sytuacji wziętej z życia, to znakomitym przykładem wydaje się być obieg pisma pomiędzy wydziałami dużej organizacji. Po zapoznaniu się z dokumentem konkretna filia podejmuje decyzję o jego rozpatrzeniu lub o przekazaniu do innego oddziału. Koniec końców dokument trafi na odpowiednie biurko.

prosty przykład praktyczny

Przyjmijmy założenie, iż w zależności od typu zmiennej będącej żądaniem, jego obsługa będzie delegowana do dedykowanego obiektu. Na początku potrzebny nam jest abstrakcyjny zarys dla klas stanowiących elementy łańcucha:

abstract class Handler {

	protected $nextHandler = NULL;

	// zajmuje sie obsluga requesta
	abstract public function Request ($request);

	// setter dla kolejnego handler'a
	public function setNextHandler(Handler $h) {

		$this->nextHandler = $h;

	}

}

Teraz ich definicja:

// obsluga dla zmiennej typu boolean
class Boolean extends Handler {

	public function Request ($request) {

		if (is_bool($request))
			return "BOOL";
		else
			if ($this->nextHandler instanceof Handler)
				return $this->nextHandler->Request($request);

	}

}

// obsluga dla zmiennej typu numeric
class Numeric extends Handler {

	public function Request ($request) {

		if (is_numeric($request))
			return "NUMERIC";
		else
			if ($this->nextHandler instanceof Handler)
				return $this->nextHandler->Request($request);

	}

}

// obsluga dla zmiennej typu string
class String extends Handler {

	public function Request ($request) {

		if (is_string($request))
			return "STRING";
		else
			if ($this->nextHandler instanceof Handler)
				return $this->nextHandler->Request($request);

	}

}

// obsluga zachowania domyslnego - na koncu lancucha
class DefaultHandler extends Handler {

	public function Request ($request) {

		return "DON'T KNOW";

	}

}

Na koniec klient:

// klient
class Client {

	public function request ($request) {

		// tworzymy instancje elementow lancucha
		$string = new String();
		$numeric = new Numeric();
		$boolean = new Boolean();
		$default = new DefaultHandler();

		// ustawiamy kolejnosc elementow w lancuchu
		// string > numeric > boolean > default
		$string->setNextHandler($numeric);
		$numeric->setNextHandler($boolean);
		$boolean->setNextHandler($default);
		return $string->Request($request);

	}

}

// przykladowe uzycie
$client = new Client();
var_dump($client->request(array(1)));

Wśród zalet chain of responsibility należy wymienić możliwość dowolnego formowania przebiegu obsługi request’a. W dowolnej chwili można utworzyć nowe elementy lub usunąć istniejące. Zachęcam do głębszego zapoznania się z tym wzorcem projektowym.

prawo amdahla

Na początku mamy skrypt, który działa zbyt wolno. Po dokonaniu szczegółowej analizy okazuje się że:

• 80 % czasu jego wykonywania zajmuje “proces autoryzacji”
• 10 % czasu jego wykonywania zajmuje “logowanie zdarzeń”
• 10 % czasu jego wykonywania zajmują “operacje arytmetyczne”

Który fragment należy poddać optymalizacji, aby uzyskać maksymalny wzrost wydajności? Na to pytanie udziela nam odpowiedzi prawo Amdahla. Choć wykorzystywane głównie w obliczeniach równoległych, to i dla operacji sekwencyjnych przedstawia algorytm postępowania. Dzięki zastosowaniu kilku prostych wzorów, możemy łatwo określić, jakie działania przyniosą najlepsze rezultaty. Poniżej ukazuję najważniejszy z nich (im wyższy wynik, tym lepsza optymalizacja):

Gdzie:

• p - fragment kodu przyspieszony p-razy
• f - czas wykonywania fragmentu kodu (nieulegającego poprawkom) przed podjęciem jakichkolwiek działań (f należy do przedziału obustronnie otwartego (0,1) )

Warto sprawdzić powyższy wzór w praktyce. Hipotetycznie przyjmijmy więc, że dla skryptu o którym była mowa na początku tego wpisu, mamy następujące możliwości poprawy jego wydajności.

• 1. proces autoryzacji (80%) może przebiegać dwa razy szybciej
• 2. operacje arytmetyczne (10%) mogą być wykonywane 100 razy szybciej

Choć stukrotny wzrost może robić duże wrażenie, to po podstawieniu danych do formuły i wykonaniu niezbędnych obliczeń wszystko staje się jasne:

• rozwiązanie pierwsze ~ 1,6 (p=2, f=1-0.8, f=0.2)
• rozwiązanie drugie ~ 1,1(p=100, f=1-0.1, f=0.9)

Wybór jest oczywisty - optymalizacja procesu autoryzacji. Czasami podejmowanie decyzji jest trudniejsze, gdyż do wzrostu szybkości dochodzi jeszcze jeden czynnik - nakład pracy. Warto o nim pamiętać, przed dokonaniem ostatecznego wyboru.

xdebug

Profilery najczęściej prezentują dane w dwóch postaciach: tabelarycznej lub / i graficznej. Xdebug pozwala przeanalizować skrypty z wykorzystaniem drugiej formy. Po pomyślnej instalacji potrzebna jest jego szybka konfiguracja (dla zainteresowanych pełna dokumentacja znajduje się TUTAJ).

Pierwsza dyrektywa aktywuje opcję profilera. Druga określa katalog, gdzie wyniki jego pracy mają być zapisywane. Aby je odczytać w zależności od posiadanego systemu operacyjnego potrzebujemy odpowiedni program. Dla Linux’a jest to Kcachegrind (oferuje szerszą gamę funkcjonalności w stosunku do swojego okienkowego konkurenta), a dla Windows’a WinCachegrind. Format tworzonych przez xdebug’a logów przedstawia się następująco: cachegrind.out.xx, gdzie xx to id procesu. Oczywiście nazewnictwo można zmienić, poprzez odpowiednie ustawienie opcji xdebug.profiler_output_name.

Zbytnio nie zwlekając przejdźmy od teorii do praktyki. Poniżej zamieszczam prosty przykład, którego wykonywanie rozłożymy na czynniki pierwsze z użyciem WinCachegrind’a.

function a () {

	$m = 0;
	for ($i=0;$i<1000;++$i)
		$m += 1;

}

function b () {

	$m = 0;
	for ($i=0;$i<10000;$i++)
		$m += 1;

}

a();
b();

Po otwarciu wygenerowanego przez profiler pliku (czyli na dobrą sprawę po uruchomieniu skryptu) naszym oczom ukaże się następujący widok:

Jak na dłoni widać ilości oraz czasy wywołań poszczególnych funkcji, dając nam spore źródło wiedzy niezbędnej do przeprowadzenia efektywnej optymalizacji skryptu.

Proszę traktować ten wpis jako wstęp do zagadnienia jakim jest profilowanie kodu. Osoby zainteresowane pogłębieniem wiedzy w tym zakresie, odsyłam do zapoznania się z takim narzędziem jak XHProf.

metoda szablonowa z życia wzięta

Jeśli po tym krótkim wstępie nadal nie masz pojęcia czym jest i do czego służy metoda szablonowa, to za chwilę wszystko stanie się jasne i zrozumiałe. Weźmy pod lupę pieczenie ciasta. Niezależnie od jego rodzaju możemy wyodrębnić pewne etapy, które zazwyczaj nie ulegają zmianie i są wykonywane w określonej kolejności:

• proces gromadzenia niezbędnych składników
• proces przygotowania ciasta
• proces pieczenia

Dopiero dla konkretnych ciast, każdy z tych kroków wygląda inaczej. Tymczasem szablon nie ulega żadnym przekształceniom.

przykład

A teraz przykład praktyczny. Poniżej znajduje się klasa bazowa implementująca omawiany przeze mnie wzorzec. Zachęcam do zapoznania się z jego kodem i naniesionymi komentarzami.

// klasa zawierajaca metode szablonowa
abstract class TemplateMethod {

	// ta czesc algorytmu jest stala
	private function StartIt () {

		echo __METHOD__,'';

	}

	// ponizsza czesc algorytmu implementuja klasy podrzedne

	protected abstract function DoSomething () ;

	protected abstract function EndIt ();

	// metoda szablonowa jest niezmienna

	public final function Template () {

		$this->StartIt();
		$this->DoSomething();
		$this->EndIt();

	}

}

Czas na klasę dziedzicząca po TemplateMethod:

class Something extends TemplateMethod {

	protected function DoSomething () {

		echo __METHOD__,'';

	}

	protected function EndIt () {

		echo __METHOD__,'';

	}

}

Na koniec zobaczmy, czy wszystko funkcjonuje w sposób prawidłowy:

$obj = new Something ();
$obj->Template();

Na wyjściu otrzymujemy:

Mam nadzieje, iż w tym krótkim wpisie udało mi się zachęcić Was do używania tego lub w ogóle wzorców projektowych. Osoby zainteresowane odsyłam do zapoznania się z “bratem” template method - strategią, o której miałem już okazję napisać parę słów TUTAJ.

testy jednostkowe

Unit tests umożliwiają przeprowadzenie weryfikacji poprawnego funkcjonowania konkretnych klas, ich metod lub funkcji - zatem przynależą do grupy testów białej skrzynki (white box). W metodyce programowania zwinnego (agile software development) są one doskonałą metodą dokumentacji poszczególnych modułów aplikacji.
Programiści piszą testy jednostkowe równolegle z komponentem dla którego są przeznaczone. Choć takie podejście wydłuża czas pracy, to w ostatecznym rozrachunku przynosi sporo korzyści. Moduły są bowiem mniej błędogenne, a ich działanie cechuje się większą niezawodnością. Poprzez wprowadzoną automatyzację oszczędzamy godziny, które poświęcilibyśmy na przeprowadzanie testów ręcznie i nanoszenie ewentualnych poprawek.

narzędzia do testów

Dla programistów PHP istnieją na rynku gotowe rozwiązania. Wśród nich pozwolę sobie wymienić PHPUnit oraz SimpleTest. Oczywiście nic nie stoi na przeszkodzie, by samemu spróbować stworzyć własny komponent do przeprowadzania testów. Potrzebna jest tylko odrobina czasu i chęci, oraz zaznajomienie się z pojęciem asercji, o której miałem już okazję napisać parę słów TUTAJ. Omawiane przeze mnie zagadnienie postaram się wyjaśnić z wykorzystaniem biblioteki SimpleTest.

simpletest

Klasa testowa - Maths będzie bardzo prosta. Jej jedyna metoda, zwróci TRUE, jeżeli iloraz dwóch liczb jest większy od zera. W przeciwnym wypadku - FALSE. Spójrzmy więc na jej deklarację.

class Maths {

	public function IsPositive ($first,$second) {

		if (($first/$second)>0)
			return true;

	}

}

Jako, że test piszemy równocześnie, zatem zobaczmy jak może wyglądać:

// klasa testujaca dziedziczy po UnitTestCase
class TestMaths extends UnitTestCase {

	// wolana przed wykonaniem testow
	public function setUp() {

		$this->maths = new Maths();

	}

	// wolana po zakonczeniu wszytskich testow
	public function tearDown () {

		unset($this->maths);

	}

	// metoda testowa, gdyz zawiera prefiks test
	public function testIsPositive () {

		for ($i=0;$i<100;$i++)
			// sprawdzamy czy metoda klasy Maths
			// zwraca zawsze jakas wartosc
			$this->assertnotNull(
				$this->maths->IsPositive(rand(-10,10),rand(-10,10))
			);

	}

}

Powyższa klasa musi dziedziczyć po UnitTestCase. Metoda setUp() jest wywoływana przed wykonaniem jakichkolwiek testów (czyli wszystkich metod które zaczynają się przedrostkiem test), a tearDown() po ich zakończeniu. Brakuje nam uruchomienia przedstawionego kodu.

require_once(dirname(__FILE__) . '/simpletest/autorun.php');

require_once 'Maths.php';
require_once 'TestMaths.php';
// tworzymy nowa grupe testow
$test = new GroupTest('Moje testy');
// dodajemy testowanie naszej klasy
$test->addTestCase(new TestMaths());
// uruchamiamy test
$test->run(new HtmlReporter());

Na wyjściu otrzymujemy:

Zapomnieliśmy o fakcie, iż nie wolno dzielić przez zero, oraz o zwracaniu wartości FALSE jeśli iloraz jest mniejszy lub równy zero. Wprowadzamy więc poprawki.

class Maths {

	public function IsPositive ($first,$second) {

		if ($second===0)
			return 0;
		if (($first/$second)>0)
			return true;
		else
			return false;

	}

}

Ponowne uruchomienie testu daje wyczekiwany rezultat. Wszystko funkcjonuje poprawnie.

Na koniec prezentuję opis najważniejszych metod klasy UnitTestCase, bez znajomości których ciężko wyobrazić sobie efektywne pisanie unit tests:

• assertTrue($a) - $a musi być prawdą (np. 1,true,12,’a')
• assertFalse($a) - $a musi być fałszem (np. 0,false,”)
• assertNull($a) - $a musi być NULL’em
• assertNotNull($a) - $a nie może być NULL’em
• assertEqual($a,$b) - $a i $b muszą być sobie równe, lecz nie koniecznie tego samego typu

To tylko krótki wstęp możliwości oferowanych przez SimpleTest. Zainteresowanych odsyłam do dokumentacji, którą znajdziecie TUTAJ.

parent i self

Są to dwa słowa kluczowe dzięki którym w sposób prosty, łatwy i przyjemny jesteśmy w stanie odwoływać się do stałych, właściwości statycznych oraz metod - klasy rodzica (parent) lub samej siebie (self). Oczywiście z zachowaniem wszystkich zasad dziedziczenia. Spójrzmy na poniższe dwa skrypty, ilustrujące parent i self w akcji. Prosiłbym o zwrócenie uwagi na komentarze, które zawierają szczegółowe objaśniania.

przykład pierwszy - self

class A {

	protected function Test () {

		echo __CLASS__;

	}

}

class B extends A {

	public function Call() {
		// jako ze jestesmy w klasie B,
		// slowo kluczowe self bedzie
		// odnosilo sie wlasnie do niej
		self::Test();
		// zapis rownoznaczny powyzszemu
		// aczkowiek w przypadku zmiany
		// nazwy klasy wymuszajacy na nas
		// dodatkowa ingerencje w strukture kodu:
		// B::Test();
	}

	public function Test () {

		echo __CLASS__;

	}

}

$obj = new B();
$obj->Call();

Na wyjściu otrzymamy:

przykład drugi - parent

class A {

	protected function Test () {

		echo __CLASS__;

	}

}

class B extends A {

	public function Call() {
		// jako ze jestesmy w klasie B,
		// slowo kluczowe parent bedzie
		// sie odnosilo do klasy rodzica - A
		parent::Test();
		// zapis rownoznaczny powyzszemu
		// aczkowiek w przypadku zmiany
		// nazwy klasy rodzica wymuszajacy na nas
		// dodatkowa ingerencje w strukture kodu:
		// A::Test();
	}

	public function Test () {

		echo __CLASS__;
	}

}

$obj = new B();
$obj->Call();

Na wyjściu otrzymamy:

late static bindings

Opóźnione statyczne wiązania wprowadzają dodatkowe słowo kluczowe static, uzupełniając tym samym spektrum możliwości oferowanych przez wyżej opisane: parent i self. Static bowiem, odwołuje się do klasy biorąc pod uwagę kontekst w jakim nastąpiło żądanie. Prześledźmy to na przykładzie:

class A {

	protected static function Test () {

		echo __CLASS__;

	}

	public function Call() {
		// slowo kluczowe static bedzie
		// sie odnosilo do klasy z kontekstu ktorej
		// zastapilo zadanie
		static::Test();

	}

}

class B extends A {

	protected static function Test () {

		echo __CLASS__;

	}

}

// metoda Call wywola metode klasy B, gdyz w jej kontekscie nastapilo zadanie
B::Call();

// metoda Call wywola metode klasy A, gdyz w jej kontekscie nastapilo zadanie
A::Call();

Na wyjściu otrzymamy:

Osoby zainteresowane poszerzeniem wiedzy na temat late static bindings polecam zapoznanie się z dokumentacją TUTAJ. Tym samym był to mój ostatni post na temat nowości w PHP 5.3. Przyszedł więc czas na małe podsumowanie najważniejszych zmian i nowości wniesionych z tym wydaniem, w formie krótkiej listy:

• funkcje anonimowe - dodatkowe informacje TUTAJ
• przestrzenie nazw - dodatkowe informacje TUTAJ
• nowdoc - dodatkowe informacje TUTAJ
• late static bindings
• metody magiczne __callStatic() i __invoke() - dodatkowe informacje TUTAJ
• możliwość definiowania stałych przy użyciu słowa kluczowego const - dodatkowe informacje TUTAJ
• instrukcja goto - dodatkowe informacje TUTAJ

Więcej informacji szukaj u źródła - w dokumentacji PHP.

Stringi

Zatem istnieją cztery sposoby tworzenia ciągów znaków:

• pojedynczy cudzysłów (łańcuchy nieprzetwarzane)
• cudzysłów (łańcuchy przetwarzane)
• heredoc
• nowdoc

Heredoc i nowdoc

Korzystając ze składni heredoc deklarowane łańcuchy są przetwarzane. Spójrzmy na poniższy przykład:

$a = 1;
// deklaracje przy uzyciu cudzyslowia
// dodano w PHP 5.3
// mozna go spokojnie pominac
echo <<<"HER"
$a
HER;

Na wyjściu otrzymamy:

Natomiast nowdoc nie oferuje takiej możliwości - zachowując się analogicznie jak pojedynczy cudzysłów:

$a = 1;

echo <<<'HER'
$a
HER;

Wypisze:

Od PHP 5.3 obie metody mogą być używane do deklaracji zmiennych statycznych oraz stałych i właściwości klas. Popatrzmy:

class Heredoc {

	const A = <<<"HER"
Test
HER;

	public $m = <<<"HER"
Test
HER;

}

class Nowdoc {

	const A = <<<'HER'
Test
HER;

	public $m = <<<'HER'
Test
HER;

}

I na koniec jeszcze jeden przykład:

function heredoc () {

	static $a = <<<"HER"
1
HER;

	return $a++;

}

function nowdoc () {

	static $a = <<<'HER'
1
HER;

	return $a++;

}

I to tyle w temacie stringów.

przykład pierwszy

Poniżej prezentuję prostą klasę ImplementAction, która korzysta z omawianego przeze mnie wzorca (klasa abstrakcyjna Action). Popatrzmy na jej kod:

abstract class Action {

	abstract public function BeforeAction();

	abstract public function AfterAction();

	public function __construct () {
		$this->BeforeAction ();
	}

	public function __destruct() {
		$this->AfterAction ();
	}

}

class ImplementAction extends Action {

	public function BeforeAction() {
		echo __METHOD__;
	}

	public function AfterAction() {
		echo __METHOD__;
	}

	public function A () {
		echo __METHOD__;
	}

	public function B () {
		echo __METHOD__;
	}

}

$obj = new ImplementAction();
$obj->A();
$obj->b();

Na wyjściu otrzymamy:

Jak widać przy tworzeniu obiektu wywoływana jest metoda BeforeAction(), a w destruktorze AfterAction(). Oczywiście powyższy kod ma swoje wady i zalety. Zależą one jednak od wymogów tworzonego oprogramowania, zatem coś co dla jednych może być dużym plusem, dla innych staje się rozwiązaniem nie do przyjęcia. Najwyższy czas na przyjrzenie się bardziej zaawansowanemu modelowi użycia Intercepting Filter, dzięki któremu zwiększymy jego elastyczność i możliwości.

przykład drugi

// iterfejs dla filtrow
interface InterceptingFilter {

	public function doBefore();
	public function doAfter();

}

// klasa filtra
class FirstFilter implements InterceptingFilter {

	public function doBefore() {

		echo __METHOD__;

	}

	public function doAfter() {

		echo __METHOD__;

	}

}
// klasa filtra
class SecondFilter implements InterceptingFilter {

	public function doBefore() {

		echo __METHOD__;

	}

	public function doAfter() {

		echo __METHOD__;

	}

}
// klasa filtra
class AnotherFilter implements InterceptingFilter {

	public function doBefore() {

		echo __METHOD__;

	}

	public function doAfter() {

		echo __METHOD__;

	}

}
// abstrakcyjna klasa zajmujaca sie odpowiednim wywolywaniem
// filtrow
abstract class UseInterceptingFilter {

	private $filters = array();

	private function doBeforeActions() {

		foreach ($this->filters as $do)
			$do->doBefore();

	}

	private function doAfterActions() {

		foreach ($this->filters as $do)
			$do->doAfter();

	}

	public function __construct (array $filters = array()) {

		$this->filters = $filters;

		$this->doBeforeActions();

	}

	public function __destruct () {
		$this->doAfterActions();
	}

}

// klasa korzystajaca z filtrow
class Example extends UseInterceptingFilter {

	public function A() {

		echo __METHOD__;

	}

	public function B() {

		echo __METHOD__;

	}

}

// tworzymy przykladowe filtry
$filter1 = new FirstFilter();
$filter2 = new SecondFilter();
$filter3 = new AnotherFilter();

// filtry przekazywane w konstruktorze
$obj = new Example(array($filter1,$filter2,$filter3));
$obj->A();
$obj->B();

Na wyjściu dostajemy:

Aby dodać nowy filtr wystarczy napisać klasę implementującą interfejs InterceptingFilter. Natomiast klasy z nich korzystające dziedziczą po UseInterceptingFilter , a ów filtry są przekazywane jako tablica w konstruktorze.

Zachęcam więc do własnych eksperymentów, które doprowadzą do rozwiązań w pełni dostosowanych do stawianych przez Was wymagań.

praktyka

W PHP namespaces można tworzyć na dwa sposoby i oba zostały zaprezentowane poniżej:

namespace A;

function ShowMsg() {

	echo __FUNCTION__;

}

Albo tak:

namespace A {

function ShowMsg() {

	echo __FUNCTION__;

}

}

Jak widać na powyższych przykładach, przestrzeń konstruuje się z użyciem słowa kluczowego namespace, po czym określana jest jej nazwę (w tym wypadku A). Należy pamiętać, aby deklaracja ta znajdowała się na początku skryptu (przed nią może wystąpić tylko declare). Dozwolone jest też tworzenie kilku przestrzeni w jednym pliku, aczkolwiek rozwiązanie to nie jest zalecane:

namespace A ;

function ShowMsg() {

	echo __FUNCTION__;

}

namespace B ;

function ShowMsg() {

	echo __FUNCTION__;

}

Można również organizować pewnego rodzaju hierarchię, formując poziomy (sub-namespaces):

namespace Main\First ;

function ShowMsg() {

	echo __FUNCTION__;

}

namespace Main\First\One ;

function ShowMsg() {

	echo __FUNCTION__;

}

namespace Main\First\Two ;

function ShowMsg() {

	echo __FUNCTION__;

}

Zapewne zastanawiacie się jak wywoływać klasy, funkcje i stałe z różnych przestrzeni. Przełączanie się między nimi przypomina proces poruszania się po strukturze katalogów. Występuje tutaj pojęcie ścieżek względnych i bezwzględnych. Najprościej będzie to zrozumieć analizując prosty kod, zamieszczony poniżej:

// przestrzen A\First
namespace A\First {

	function ShowMsg () {
		// specjalna stala predefiniowana zawiera
		// przestrzen w ktorym sie znajduje struktura
		echo __NAMESPACE__;

	}
}

// przestrzen A\Second
namespace A\Second {

	function ShowMsg () {

		echo __NAMESPACE__;

	}
}

// przestrzen A
namespace A {

	// sciezki bezwzgledne
	\A\First\ShowMsg();
	\A\Second\ShowMsg();

	// sciezki wzgledne (wzgledem obecnej przestrzeni)
	First\ShowMSg();
	Second\ShowMSg();

	// jeszcze jeden sposob namespace to odwolanie
	// do aktualnej przestrzeni
	namespace\First\ShowMsg();
	namespace\Second\ShowMsg();

	// wywolywanie globalnych funkcji, klas i stalych
	echo \count(array(1,2,3));

}

// przestrzen "globalna"
namespace {

}

Oczywiście nie opisałem wszystkich możliwości namespaces w PHP. Zainteresowanych odsyłam TUTAJ.

Introspekcja w PHP

Po krótkim wstępie teoretycznym przechodzimy do praktycznego przykładu, wykorzystującego introspekcję. Na początku przykładowa klasa pełniąca rolę królika doświadczalnego.

class Rabbit {

	public $name;

	public function PrintClassName () {

		echo __CLASS__;

	}

	public function PrintRabbitName () {

		echo $this->name;

	}

}

Pobierzmy podstawowe informacje o tej klasie. Sposób pierwszy - na podstawie nazwy klasy:

var_dump (class_exists('Rabbit'));
var_dump (get_class_methods('Rabbit'));
var_dump (method_exists('Rabbit','PrintRabbitName'));
var_dump (property_exists('Rabbit','name'));

Sposób drugi - korzystając z instancji klasy:

$obj = new Rabbit();
var_dump (get_class_methods($obj));
var_dump (method_exists($obj,'PrintRabbitName'));
var_dump (property_exists($obj,'name'));

Omówmy użyte powyżej funkcje:

• class_exists(string $name) - zwraca bool informując czy klasa została zdefiniowana czy też nie. UWAGA! Funkcja posiada opcjonalny parametr, o którym można przeczytać w dokumentacji.
• get_class_methods(mixed $class) - zwraca array zawierającą wszystkie metody klasy przekazanej w parametrze (instancja lub jej nazwa). Jeśli wystąpił błąd funkcja zwróci NULL.
• method_exists(mixed $class, string $method) - zwraca bool informując czy istnieje metoda $method dla klasy przekazanej w parametrze $class (instancja lub jej nazwa).
• property_exists(mixed $class, string $property) - zwraca bool informując czy istnieje właściwość $property dla klasy przekazanej w parametrze $class (instancja lub jej nazwa).

Oczywiście to tylko wybrane funkcje. Zainteresowanych zapraszam TUTAJ. Źródło przykładu zamieszczonego w tym poście znajdziecie TUTAJ. O refleksji pisałem już trochę TUTAJ.

stan w praktyce

Przyjmijmy następujące założenie. Chcemy uzależnić wywoływanie kolejnych metod na obiekcie, na podstawie typu zmiennej (integer,boolean,itp.) wcześniej do niego przekazanej. Zatem chciałbym, aby do “obsługi” integer’a,boolean’a został delegowany odpowiedni, dedykowany obiekt. Spójrzmy na poniższy przykład:

interface Stan {

	public function CheckIt ($value);
	public function WriteMessage ();

}

Powyżej znajduje się interfejs dla klas (ich implementacja znajduje się poniżej), które będą obsługiwać poszczególne typy zmiennych. Metoda CheckIt($value) sprawdza typ przekazanego parametru a metoda WriteMessage() wypisze go na wyjściu.

class NoStan implements Stan {

	private $stan;

	public function __construct (UseStan $usestan) { 

		$this->stan = $usestan;

	}

	public function CheckIt ($value) {

		if (is_int($value))
			$this->stan->ChangeStan($this->stan->GetIntegerStan());
		elseif (is_bool($value))
			$this->stan->ChangeStan($this->stan->GetBooleanStan());
		elseif (is_string($value))
			$this->stan->ChangeStan($this->stan->GetStringStan());
	}

	public function WriteMessage () {

		echo 'Nie wywolano metody CheckIt()!';

	}

}

class IntegerStan implements Stan {

	private $stan;

	public function __construct (UseStan $usestan) { 

		$this->stan = $usestan;

	}

	public function CheckIt ($value) {

		echo 'Metoda CheckIt() byla juz wolana!';
	}

	public function WriteMessage () {

		$this->stan->ChangeStan($this->stan->GetNoStan());
		echo 'INTEGER';

	}

}

class StringStan implements Stan {

	private $stan;

	public function __construct (UseStan $usestan) { 

		$this->stan = $usestan;

	}

	public function CheckIt ($value) {

		echo 'Metoda CheckIt() byla juz wolana!';
	}

	public function WriteMessage () {

		$this->stan->ChangeStan($this->stan->GetNoStan());
		echo 'STRING';

	}

}

class BooleanStan implements Stan {

	private $stan;

	public function __construct (UseStan $usestan) { 

		$this->stan = $usestan;

	}

	public function CheckIt ($value) {

		echo 'Metoda CheckIt() byla juz wolana!';
	}

	public function WriteMessage () {

		$this->stan->ChangeStan($this->stan->GetNoStan());
		echo 'BOOLEAN';

	}

}

Jak widać każdy typ danych ma swoją klasę (string - StringStan, itd.). Wyjątek stanowi NoStan, której zadaniem jest określenie typu zmiennej $value przekazanej w metodzie CheckIt($value),a następnie wydelegowanie do dalszej obsługi metod interfejsu Stan instancji odpowiedniej klasy(StringStan,BooleanStan,itd.). Może zastanawiać do czego służy i czym jest prywatna właściwość $stan klasy UseStan. Zatem spójrzmy na jej implementację:

class UseStan {

	private $nostan;
	private $integerstan;
	private $stringstan;
	private $booleanstan;

	private $stan;

	public function __construct () {
                // przekazywanie w parametrze obiektu klasy UseStan ($this)
                // pozwoli na swobodna zmiane delegacji przez klasy stanow
                // z uzyciem setter'a stanu i getterow wszystkich stanow
		$this->nostan = new Nostan($this);
		$this->integerstan = new IntegerStan($this);
		$this->stringstan = new StringStan($this);
		$this->booleanstan = new BooleanStan($this);
                // na poczatku nie wiemy jaki typ zmiennej bedzie przekazany, zatem
                // inicjujemy wlasciwosc obiektem klasy NoStan
		$this->stan = $this->nostan;

	}

	//implementacja interfejsu obiektow - stanow

	public function CheckIt ($value) {

		$this->stan->CheckIt($value);

	}

	public function WriteMessage () {

		$this->stan->WriteMessage();

	}

	// metoda delegujaca nowy obiekt stanu do pracy

	public function ChangeStan (Stan $newstan) {

		$this->stan = $newstan;

	}

	// gettery stanów

	public function GetNoStan () {

		return $this->nostan;

	}

	public function GetIntegerStan () {

		return $this->integerstan;

	}

	public function GetStringStan () {

		return $this->stringstan;

	}

	public function GetBooleanStan () {

		return $this->booleanstan;

	}
}

Obiekty stanów używają instancji klasy UseStan która je posiada, do zmiany delegacji (stąd gettery wszystkich stanów i setter ChangeStan($nowystan)). Na koniec użycie:

$obj = new UseStan();
// W zaleznosci od typu parametru, zostanie wydelegowana instancja
// odpowiednej klasy do dalszej obslugi metod interfejsu Stan.
$obj->CheckIt(true); 

// Stad tez metoda WriteMessage wywolana zostanie na obiekcie klasy
// BooleanStan a nie zadnym innym.
$obj->WriteMessage();

Powyższy przykład jest prosty i ma na celu zrozumienie wzorca Stan. Mam nadzieje, iż w jakimś stopniu Wam w tym pomogłem. Kod przykładu znajduje się TUTAJ