Strategia to czynnościowy wzorzec projektowy, który hermetyzuje algorytmy z danej rodziny w postaci klas. Jeśli taka definicja brzmi skomplikowanie to diagram UML wyjaśnie wszelkie wątpliwości.

Często okazuje się, że dziedziczenie jest niewystarczającym sposobem tworzenia oprogramowania. Wtedy z pomocy przychodzi inne techniki projektowania aplikacji.

Strategia definiuje wspólny interfejs dla każdego obsługiwanego algorytmu. Wymusza to na nas stworzenie implementacji obsługiwanych funckji w klasach dostarczających konkretne algorytmy. Klasa, która korzysta z tych algorytmów, ustawia referencję do aktualnie używanej strategii poprzez motodę ustawStrategie(). Jeśli klient zmienia algorytm danej strategii, wiąże się to z ustwieniem nowej strategii dla klienta. Analogicznie tworzenie następnych algorytmów nie wymaga ingerencji w klasy klienta, ani interfejsu, a jedynie stworznia nowej strategii implementującej znany interfejs.

Wzorzec strategii opiera swoje działanie na kompozycji i delegacji, a nie dziedziczeniu. Dzięki temu unikamy mało elastycznych instrukcji warunkowych w klasie klienta, który wybiera dany algorytm. Poszczególne strategie mogą być zmieniane w trakcie działania programu, co daje korzyści w postaci różnego zużycia zasobów lub złożoności obliczeniowej. Takie rozwiązanie ma też swoje wady w postaci narzutu komunikacji między klientem i strategią, a także większą liczę utworzonych obiektów. Jednak moim zdaniem to mały koszt w stosunku do przytoczonych zalet.

Przykładowe wykorzytanie tego wzorca w PHP opiszę szerzej w artykule dotyczącym wsparcia generowania tabel XHTML.

Fabryka abstrakcyjna

Plusem wykorzystania wzorca fabryki abstrakcyjnej jest możliwość ukrycia szczegółów implementacyjnych klas reprezentujących dany produkt. W ten sposób klient widzi tylko interfejs. Ukryte zostają również nazwy klas, co odizolowuje klienta od problemu określenia, do której klasy należy obiekt.

<?php
interface IUser {
	function getName();
}

class User implements IUser {
	public function __construct($id) { }

	public function getName() {
		return 'Jacek';
	}
}

class UserFactory {
	public static function create($id) {
		return new User($id);
	}
}
?>

Klasa User zaprezentowana powyżej implementuje interfejs IUser, który zawiera metodę getName(). Tworzenie nowego obiektu użytkownika odbywa się poprzez statyczną metodę create(). Szczegóły tworzenia użytkowników ukryte są w klasie User fabryki.

Podsumowanie

Istnieje prosta metoda sprawdzenia czy klasa działa poprawnie.

<?php
$oUser = UserFactory::create(1);
echo($oUser->getName());
?>

Poniższy wydruk pokazuje, że dokładnie tak się dzieje.

Jacek

Wzorzec projektowy fabryki abstrakcyjnej kładzie nacisk na tworzenie produktów z konkretnej rodziny.

Częsta sytuacja, z jaką spotykają się programiści to współdzielenie zasobów. Wszystkie zapytania do bazy danych wymagają połączenia. Taki uchwyt może być wykorzystany wielokrotnie przez różne zapytania przy tym samym żądaniu. Otwieranie i zamykanie połączeń jest najzwyczajniej, mało ekonomiczne.

Singleton

Istnieje proste rozwiązanie tego problemu. Singleton to wzorzec projektowy, który zwraca istniejącą instancję obiektu. Jeśli taka instancja nie istnieje wówczas jest tworzona. Idea rozwiązania jest bardzo prosta i idealnie pasuje do naszego problemu. Poniżej znajduje się kod klasy DB, która dziedziczy z klasy Singleton i tworzy takie połączenie do bazy.

Prawidłowa struktura klas, co zasugerował Wasacz w komentarzach, wymaga dziedziczenia klasy DB po ogólnej klasie wzorca Singleton. Niestety nie mam pomysłu zogranizowanie klasy wzorca poza pustymi metodami i jedną zmienną.

<?php
abstract class Singleton {
	protected static $_instance;

	protected function __construct() { }

	public static function instance() { }
}

class DB extends Singleton {
	private $_conn;

	private function __construct($conf) {
		$this->_conn = mysql_connect($conf['host'], $conf['user'], $conf['pass']) or die($this->error());
	}

	public static function instance($conf=null) {
		if (is_null(self::$_instance)) {
			self::$_instance = new DB($conf);
		}
		return self::$_instance;
	}
}
?>

Klasa DB zaprezentowana powyżej nie jest skomplikowana. Zawiera jednak tylko niezbędne metody, prezentujące działanie klasy. Niemożliwe jest stworzenie egzemplarza klasy DB, ponieważ konstruktor jest prywatny. Dostęp do obiektu możliwy jest poprzez publiczną, statyczną metodę instance().

Podsumowanie

Istnieje prosta metoda sprawdzenia czy klasa działa poprawnie. Próba pobrania obiektu klasy DB powinna zwrócić ten sam zasób.

<?php
print_r(DB::instance());
print_r(DB::instance());
?>

Poniższy wydruk pokazuje, że dokładnie tak się dzieje.

DB Object
(
    [_conn:private] => Resource id #11
)
DB Object
(
    [_conn:private] => Resource id #11
)

Wzorzec projektowy Singleton stosuje się bez względu na stopień skomplikowania aplikacji. Rozwiązanie to jest wygodniejsze i elastyczniejsze niż przechowywanie uchwytu do bazy danych w zmiennej globalnej.