Michał Wachowski programista php & webdeveloper

W pewnym momencie każdy skrypt dochodzi do etapu gdzie jakiś element Foo potrzebuje do działania elementu Bar. Staje się związany, zależny.
W programowaniu istnieją pojęcia loose coupling i tight coupling określające poziom zależności. Mówi się, że loose coupling jest lepsze, a dependency injection jest magicznym lekarstwem...
Tylko co to znaczy?

Dependency

Przyjmijmy, że mamy klasę Storage, który zapewnia jednolity sposób dostępu do źródła danych, bez znaczenia czy to baza, XML czy jakieś API.
Z obiektu Storage korzysta przykładowy Article, do odczytu, zapisu itd. Article nie ma racji bytu bez instancji Storage.

class Storage {
	
	public function __construct($user, $pass, $database);
	/* costam costam */
}
	
class Article {
	protected $Storage;
	
	public function __construct() {
		$this->Storage = new Storage('admin', 'admin1', 'articles');
	}
	
	public function getById($id) {
		/* costam */
	}
}
	
$Article = new Article();
$article = $Article->getById(123);

Mamy więc obiekt Article, ściśle powiązany ze Storage.
Zależność między Article a Storage sama w sobie nie jest zła. W końcu Article musi skądś pobierać dane by móc artykuły wyświetlić na stronie.
Problemem jest to, że zależność jest zapisana wewnątrz Article.
Ogranicza to późniejsze wykorzystanie Article jedynie do konkretnej implementacji Storage. W momencie, gdy będzie trzeba zmienić źródło danych na inną bazę, XML, czy API, będzie trzeba ingerować w klasę Article. Tak być nie powinno - Article nie musi posiadać wiedzy gdzie składowane są dane, a jedynie jak je pozyskać. Gdzie pozyskać nie oznacza odczytać - to dwie różne rzeczy.

By zrobić to porządnie, trzeba dokonać znacznych poprawek, refaktoryzować Storage i Artilce

class MySQLStorage implements StorageInterface {

	public function __construct($user, $pass);
	/* costam costam */
}

class XMLStorage implements StorageInterface {

	public function __construct($path);
	/* costam costam */
}

class Article {
	protected $Storage;

	public function __construct(StorageInterface $Storage) {
		$this->Storage = $Storage
	}

	public function getById($id) {
		/* costam */
	}
}

$MySQL = new MySQLStorage('admin', 'admin1', 'articles');
$XML = new XMLStorage('articles.xml');

$MySQLArticle = new Article($MySQL);
$article1 = $MySQLArticle->getById(123);

$XMLArticle = new Article($XML);
$article2 = $XMLArticle->getById(456);

Co się stało?
Nie ma już klasy Storage, zamiast niej powstał interfejs StorageInterface, który przez implementację w MySQLStorage i XMLStorage standaryzuje sposób dostępu do źródeł danych. Odpowiednie instancje tychże implementacji są przekazywane - wstrzykiwane do Article. Tym samym Article nie jest już powiązany z konkretnym źródłem danych a jedynie ze standardem dostępu do nich jaki ustanawia StorageInterface.
Stopień zależności zmalał, co prawda Article jest nadal powiązane z jakimś Storage, ale nie ma powiedziane że z tym konkretnym. Wymaga jedynie źródła danych z interfejsem StorageInterface. MySQL, XML czy API - z perspektywy Article nie ma znaczenia.

Dependency Injection

Na tym polega właśnie dependency injection. Obiekt Article wymaga do działania jakiegoś Storage i ten zostaje mu wstrzyknięty, podany.
Article nie wie skąd i w jaki sposób powstaje Storage, zainteresowany jest tylko tym by mu go przekazać.

W powyższym przykładzie Article zależności zostają wstrzyknięte przez konstruktor. Ale są inne sposoby wstrzyknięcia:

wspomniane już przez konstruktor

Jak w powyższym przykładzie, potrzebne instancje są przekazywane jako parametry konstruktora. Najwygodniejszy sposób, od razu widać co jest potrzebne

przez metodę / setter

Jeżeli zależności jest zbyt wiele, to warto je wydzielić do odpowiednich metod / setterów. Trzeba tylko pamiętać o ich wywołaniu

przez parametr / wartość

Wspominam o tym dla porządku, bo szczerze odradzam taki sposób. Publiczne parametry są łatwe w modyfikacji, aż prosi się o stratę zależnej instancji lub podmianę na jakieś bzdury

DI Container

Każdorazowe tworzenie instancji obiektów potrzebnych dla przykładowego Article będzie masakrą. Za każdym razem trzeba sprawdzić czy nie utworzono instancji MySQLStorage, utworzyć gdy jest potrzebna, przekazać do Article i tak co jakiś czas.

By zaoszczędzić sobie roboty, wymyślono Dependency Injection Container, który pomaga zapanować nad sytuacją. Tworzy obiekty wraz z zależnościami, kontroluje czy obiekt może mieć jedną instancję czy wiele. Można też wykorzystać go do przechowywania różnego rodzaju wartości - zamiast globali.

W sieci można znaleźć wiele różnych kontenerów, z mniejszą lub większą funkcjonalnością. A ja mam swój, cały kod dostępny jest na GitHubie.
W zależności od implementacji, kontener będzie tworzył instancje obiektów w momencie utworzenia definicji (co wg mnie jest głupotą) lub dopiero w momencie pierwszego wywołania (czyli tak jak u mnie)
Całość składa się z trzech klas, na upartego można skrócić do dwóch.

ComponentDefinition

Obiekty tejże klasy przechowują definicje za pomocą której będzie można tworzyć inne obiekty w chwili ich użycia.

ParameterDefinition

Przechowuje konkretną wartość, string, integer, czy co tam się mu przekaże.

Container

Klasa z definicjami komponentów i parametrów, to do niej należy się odwoływać by uzyskać pożądaną instancję.

Sam Container nie jest wielce skomplikowany, zapewnia zestaw metod do rejestracji definicji w kontenerze, sprawdzenia czy definicja istnieje i pobrania instancji obiektu z definicji.
Cały mechanizm opiera się na identyfikatorach. Rejestrując definicję, podaje się identyfikator tekstowy pod jakim będzie dostępna.

$Condainer = new Container();
$Container->register('DatabaseStorage', new ComponentDefinition('MySQLStorage', true));
	
$MySQLArticle = new Article($Container->getComponent('DatabaseStorage'));
$article1 = $MySQLArticle->getById(123);

Utworzyłem instancję kontenera, zarejestrowałem definicję komponentu MySQLStorage pod identyfikatorem DatabaseStorage i tyle. Od tego momentu mogę wywoływać $Container->getComponent('DatabaseStorage') i za każdym razem dostanę tę samą instancję.

W przypadku ParameterDefinition można powiedzieć, że jest to przerost formy nad treścią. W końcu obiekt przechowuje tylko jakąś wartość. Chciałem jednak zachować schemat i tak zostało.

Zaś ComponentDefinition to bardziej złożona rzecz.
Tak jak pisałem wcześniej, Container sam w sobie niewiele potrafi, przechowuje tylko definicje i zapewnia interfejs. Całe tworzenie instancji, przekazywanie parametrów do konstruktorów, sprawdzanie czy już wcześniej została utworzona instancja odbywa się w definicji komponentu.

ComponentDefinition::__construct($className, $shared = false, $instance = null)

• $className - Jako pierwszy parametr należy podać klasę obiektów jakiej instancje będzie tworzyć definicja, oczywiście jako string, wraz z przestrzenią nazw
• $shared - Określa czy instancja ma być współdzielona czy nie, jeśli ma być - to definicja pozwoli na utworzenie tylko jednej instancji. Każde kolejne wywołanie, będzie powodować zwrócenie tej samej instancji
• $instance - Ten parametr może wywołać lekkie oburzenie. Mianowicie, możemy przekazać istniejącą instancję obiektu i zarejestrować ją w kontenerze. W momencie kiedy przekazujemy instancję, informacja o klasie obiektu jest zbędna, tym samym pierwszy parametr może mieć wartość null.

Wartym podkreślenia jest to, że tylko współdzielone definicje mogą być tworzone z instancji. Nie jest to ograniczenie skryptu, ale narzucone przeze mnie. Nie widzę sensu, tworzenia definicji wielu na podstawie jednej konkretnej instancji. Do kolonowania, są odpowiednie komendy.
Ktoś może pokusić się do rozszerzenia funkcjonalności i usunąć ową niedogodność - do czego gorąco zachęcam. Ja takiej potrzeby nie miałem i nie mam, komuś jednak może się to przydać.

Po utworzeniu instancji definicji, można podawać parametry/argumenty, które będą przekazywane do konstruktora w momencie tworzenia instancji. Kolejność parametrów ma znaczenie, w takiej samej jak zostaną dodane, zostaną przekazane do konstruktora.

ComponentDefinition::argument($type, $value)

• $type - Typ parametru, definicja obsługuje cztery typy, są to:
  • container - do konstruktora zostanie przekazana instancja kontenera, dla tego typu wartość jest zbędna,
  • component - określa, że do konstruktora zostanie przekazany inny komponent zdefiniowany w kontenerze, gdzie wartością jest identyfikator komponentu
  • parameter - do konstruktora zostanie przekazana wartość parametru zdefiniowanego w kontenerze, jako wartość należy podać identyfikator parametru
  • variable - parametrem będzie jakaś wartość
• $value - wartość dla danego typu (patrz $type)

Definicja dla MySQLStorage będzie wyglądać tak:

$Definition = new ComponentDefinition('MySQLStorage', true);
$Definition
	->argument('variable', 'admin')
	->argument('variable', 'admin1')
	->argument('variable', 'articles')
;

$Condainer = new Container();
$Container->register('DatabaseStorage', $Definition);

$MySQLArticle = new Article($Container->getComponent('DatabaseStorage'));
$article1 = $MySQLArticle->getById(123);

Kolejną metodą definicji jest ComponentDefinition::isShared(), która zwraca true jeśli instancja ma być wspóldzielona.

Ostatnią metodą jest tworzenie instancji.

public function &retrieve(\lib\Container $Container = null) {
	if($this->shared && $this->instance) { /* 1 */
		return $this->instance;
	}

	if(empty($this->arguments)) { /* 2 */
		$instance = new $this->className();
	}
	else { /* 3 */
		foreach($this->arguments as &$arg) {
			if(!is_array($arg)) {
				continue;
			}

			if($arg['type'] != 'variable' && !$Container) { /* 4 */
				throw new \InvalidArgumentException(sprintf('Unable to resolve dependency for %s - missing container', $this->className));
			}

			switch($arg['type']) {
				case 'container':
					$arg = $Container;
					break;
				case 'component':
					$arg = $Container->getComponent($arg['value']);
					break;
				case 'parameter':
					$arg = $Container->getParameter($arg['value']);
					break;
				case 'variable':
					$arg = $arg['value'];
					break;
				default:
					throw new \InvalidArgumentException(sprintf('Invalid argument type %s', $arg['type']));
			}
			unset($arg);
		}

		/* 5 */
		$ref = new \ReflectionClass($this->className);
		$instance = $ref->newInstanceArgs($this->arguments);
	}

	/* 6 */
	if($this->shared) {
		$this->instance = &$instance;
	}

	/* 7 */
	return $instance;
}

Krótki opis co się dzieje, krok po kroku.

1. Definicja sprawdza, czy instancja jest współdzielona i czy już została stworzona - jeśli tak, zwraca ją
2. Jeżeli definicja nie posiada argumentów, tworzy instancję obiektu
3. Ma argumenty, więc trzeba je zebrać, na podstawie zdefiniowanych typów tworzona jest tablica argumentów przesyłanch później do konstruktora. Za każdym razem, gdy tworzona jest nowa instancja, argumenty są zbierane od nowa - na wypadek, gdyby stan któregoś z istniejących już komponentów się zmienił.
4. Definicja potrafi stworzyć instancję bez użycia kontenera, pod warunkiem że żaden z argumentów nie wymaga jego istnienia - jest typu variable
5. Dopiero w tym momencie tworzona jest instancja.
6. Jeżeli instancja ma być współdzielona, instancja jest zapisywana do późniejszego wykorzystania
7. Nowo utworzona instancja jest zwracana, koniec pracy

Skąd się biorą definicje? Skąd się komu zechce, kontener nie narzuca źródła. Może to być tablica, XML, JSON, YAML, czy cokolwiek innego

Jak pisałem wyżej, cały kod jest na GitHubie