DI a property injection

Property injection má jednu podstatnou výhodu: stručnost. Srovnejte:

class Foobar
{
	/** @var HttpRequest */
	private $httpRequest;

	/** @var Router */
	private $router;

	function __construct(HttpRequest $httpRequest, Router $router)
	{
		$this->httpRequest = $httpRequest;
		$this->router = $router;
	}

}

versus

class Foobar
{
	/** @var HttpRequest @inject */
	public $httpRequest;

	/** @var Router @inject */
	public $router;

}

Proměnné musíme definovat tak jako tak. Zpravidla u nich uvádíme i anotaci @var a příslušný datový typ. Je lákavé si ušetřit práci a místo psaní rutinního kódu konstruktoru nebo metody inject() doplnit prosté @inject. Property injection kromě minimálního režijního kódu navíc parádně řeší problém s předáváním závislostí a dědičností.

Použití anotace představuje jinou konvenci pro předání závislostí. Zdůrazňuji slovo jinou, protože ať už vyjmenujeme závislosti jakožto argumenty metody nebo anotováním, jde o ekvivalentní činnost. Nejde o závislost na kontejneru, jde jen o konvenci, koneckonců dosud o kontejnerech nepadla řeč a ukázky dávají smysl.

V článku o předávání závislostí jsem se používání proměnných širokým obloukem vyhnul, protože mají vážné nedostatky:

• public proměnné nezajistí typovou kontrolu
• public proměnné nezajistí neměnnost
• private proměnné nelze naplnit žádnou jazykovou konstrukcí
• private proměnné nejsou součástí veřejného API – nejde tedy o deklaraci závislosti!
• pro protected proměnné platí nevýhody obou

Pro properly property injection bychom potřebovali read-only veřejné proměnnou s typovou kontrolou. Kdyby tohle PHP umělo, nic by nebránilo je používat.

(Aktualizace: PHP 8.1 už to umí.)