Dependency Injection ve 2.1: Anotace @inject

@**Filip Procházka**: koukal ses na ten „kód“:„https://github.com/rosret/rfc“? Pokud někomu nevoní reflexe může napsat settery… například write-once…

Editoval pekelnik (3. 5. 2013 14:59)

ad public vs private property:

Během celého života objektu je záhodno, aby property, ve které je uložena služba, byla private:

• nikdo ji nemůže zrušit nebo změnit za jiný objekt (ani omylem)
• nikdo k ní nemůže přistupovat (závislosti nejsou součástí veřejného API, nikdo s nimi nepočítá)
• patří jen třídě (její dostupnost potomkům via protected je už diskutabilní)

Existuje jediný okamžik, kdy je private překážkou:

• zápis do property zvenčí

Tomuto okamžiku se dá vyhnout extrémně snadno a zcela čistým způsobem:

• do property bude zapisovat metoda (konstruktor nebo setter, který se klidně může jmenovat inject)

Až sem není problém. Problém nastává v momentě, kdy jsme líní setter psát. Tohle třeba zdůraznit: řešíme jen syntactic sugar pro líné programátory. A zdá se, že žádné čisté řešení neexistuje. Zcela chápu, že každý vidí jakožto nepřekročitelnou jinou nevýhodu. Pravdu mají všichni.

Asi jediné čisté řešení: skriptík, který na základě @inject anotací u private property vygeneruje (přegeneruje) konstruktor či setter. Kam nemůže jazyk, tam nasadíme transpiler ;)

Otázka pak je, jestli by se taková věc mohla dít i dynamicky nebo on-the-fly (mezivrstvou ala RobotLoader). Technicky vzato dala, a to už jsme vlastně kousek od injektování do private property, problém ovšem je, že se závislosti vytratí ze „statického“ veřejného API. Tedy třeba toho API, které generuje Apigen nebo zobrazuje code completion ve spoustě editorů.

Druhé v podstatě čisté řešení: použít public property a rezignovat na zapouzdření, za podmínky, že s objektem se nikdy přímo nepracuje (tj. zapouzdření nemůže být třeba omylem porušeno). Této velmi specifické situaci vyhovují právě presentery. (Zdůrazňuji, že nejde o řešení pro presentery, ale pro typ objektů, do nějž presentery pouze spadají).

V případě presenterů se dá namítnout, že je ani neinstancujeme, tudíž můžeme rezignovat na nemožnost zápisu do private property a povolit injektování do nich. To je pravda, ale když už existuje pro presentery čistější nedokonalé řešení s public property, je zbytečné implementovat i to méně šťastné.

U obou typů property injektáže se dostaneme k jinému problém: pro svou jednoduchost budou používány i mimo specifické oblasti, kde je lze tolerovat. Což je vlastně diskriminuje asi nejvíc.

@dg: Výborně, diskuze se konečně zase posunula, díky. :)

Napadlo mě ještě jedno řešení, a totiž, že by injektování v kontejneru bylo snadno upravitelné. Například tak, že kontejner udržoval nějaký injector, který by ve výchozí implementaci injektoval přes konstruktor a přes inject metody, ale který by si každý snadno mohl upravit (a kompozicí kontejneru předat) tak, aby injektoval třeba i do public či private property s nějakou anotací (podle chuti).

Viděl bych to tak, že tenhle hacknutý injector by vůbec nemusel být nativní součástí Nette, takže by Nette nikoho nevedlo k prasáčení (nebo jaký je pro to termín, já se v tom vážně neorientuju). Důležité je, že programátor, který si je schopen napsat takový injector pracující s reflexí, není vyloženě začátečník a je sto vyhodnotit výhody a nevýhody zvoleného řešení ve svém kontextu.

Pokud by to z nějakého důvodu nešlo kompozicí, asi by mělo stačit v kontejneru injektování vyčlenit do nějaké samostatné metody, kterou by pak bylo možné přepsat v poděděném kontejneru a ten by se v aplikaci použil.

Co si myslíte o takovémto řešení?

Editoval Tharos (3. 5. 2013 15:33)

pekelnik napsal(a):
Ještě zajímavější mi přijde možnost pouze aktivovat PrivatePropertyInjector a injektovat foreach $injectors as ...

No já bych to samozřejmě taky ocenil :), ale na to mnozí namítnou, že tím „Nette nabádá k prasněčení, voe!“. Klidně bych si z toho důvodu ten injector napsal sám.

@dg: No! Tak už jenom doplnit možnost nastavit nějaký výchozí setup „globálně“ pro všechny služby, aby to bylo kompatibilní i s kratšími zápisy, a já osobně budu naprosto spokojenej. :)

@dg: Nastíněná řešení se mně osobně líbí určitě více, než public property injection. :)

A co bys řekl třeba na něco podobného? Je to nástřel, kterému chybí milion věcí, ale myšlenka je z něj myslím dobře patrná:

use Nette\Reflection\ClassType;

abstract class Injectable
{

	public function __call($name, array $arguments)
	{
		if ($name === 'inject') {
			$services = array();
			foreach ($arguments as $service) {
				$services[get_class($service)] = $service;
			}
			$reflection = new ClassType(get_called_class());
			foreach ($reflection->getProperties() as $property) {
				if ($property->hasAnnotation('inject')) {
					$type = $property->getAnnotation('var');
					if (isset($services[$type])) {
						$this->{$property->getName()} = $services[$type];
					}
				}
			}
		}
	}

}

class A {};
class B {};

class C extends Injectable
{

	/**
	 * @var B
	 * @inject
	 */
	protected $a;

	/**
	 * @var A
	 * @inject
	 */
	protected $b;

	public function isProperlyInitialized()
	{
		return $this->a !== null and $this->b !== null;
	}

}

$a = new A;
$b = new B;

$c = new C;
$c->inject($a, $b);

$c->isProperlyInitialized(); // returns true

Samozřejmě s tím, že magickou metodu inject by volal automaticky kontejner. Plus Ti, co chtějí mít navenek deklarované závislosti, si mohou ke třídě dopsat například tu @method void inject(...) anotaci.

Třeba s Tebou navrženou anotací @method void injectFoo(A $a, B $b) je na můj vkus pořád moc psaní (já už se za tu lenost fakt stydím), protože typ píšu dvakrát, název proměnné dvakrát…

Plus jsem se Tě chtěl zeptat, jestli se Ti obecně líbí myšlenka nějakých extenzí samotného kontejneru, které by dokázaly doladit, jak kontejner injektuje?

Díky za utišení toho flame tady! :)

Editoval Tharos (3. 5. 2013 21:35)

@Tharos Pokud bude všechno v anotacích je třeba automatizovat i validaci.

Ďábelská myšlenka, co nepodporovat NULL a nutit tak programátora psát NullObjekty? Došlo by k redukci stavů a nevědomky by lidi psaly míň podmínek v kódu. (Až na ty co by měly špatný návrh/neuměly navrhnout NullObjekt.)

@Tharos Místo isProperlyInitialized je zavádějící, protože podmiňuje stav isUnproperlyInitialized, které neexistuje (nelze takového stavu z principu dosáhnout, inicializace buď proběhne pořádně nebo dojde k vyjímce nebo neproběhne vůbec).

Bych byl pro jeden z těchto názvů:
$object->isJackedOnStimpacks();
$object->isVaccinated();
nebo fádní $object->hasBeenInjected();
nejlépe i s opačnou funkcí hasNotBeenInjected.

Editoval mishak (6. 5. 2013 16:31)

Známe, ale bohužel je třeba držet kompatibilitu s PHP 5.3.

Tak kromě presenterů využívám inject metody i v komponentách. Je to z toho důvodu, že v základu mají dva nepovinné parametry, se kterýma si neporadí autowiring.
Když je skryju, tak je to v pohodě, dokud nechci třeba v BaseControl injectovat nějakou službu (u mě templateLocator). Vpodstatě je situace stejná jako u presenterů (moje komponenty mají už v základu tři parametry – $parent, $name a $templateLocator). Ten mi ale dělá z nepovinných parametrů povinné a je problém při vytváření.

Těch dvou nepovinných parametrů jsem se zbavil, ale $templateLocator mi tam dost vadí. U každé komponenty, které chci injectovat nějakou závislost ho musím uvést. Přitom je to spíš taková ‚technologická‘ záležitost, která nesouvisí s logikou modelu.

<?php

/**
 * Abstraktní komponenta, která si umí dohledat šablonu
 */
abstract class BaseControl extends Nette\Application\UI\Control
{
	/** @var Annivers\Services\TemplateLocator */
	protected $templateLocator;


	/**
	 * V konstruktoru skryjeme nepovinné parametry kvůli DI kontejneru
	 */
	public function __construct(Annivers\Services\TemplateLocator $templateLocator)
	{
		parent::__construct();
		$this->templateLocator = $templateLocator;
	}
.
.

?>

<?php

/**
 * Komponenta události
 */
class EventControl extends BaseControl
{

	/** @var Annivers\Model\Data\EventRepository */
    protected $eventRepository;


    public function __construct(Annivers\Services\TemplateLocator $templateLocator, Annivers\Model\Data\EventRepository $eventRepository)
	{
		parent::__construct($templateLocator);
		$this->eventRepository = $eventRepository;
    }
.
.

?>

Raději bych $templateLocator injectoval pomocí metody a nechal konstruktor prázdný pro logické vazby. Přemýšlím o tom, že tuto věc vyřeším tím, že šablonu bude hledat přímo metoda v abstraktní komponentě, ale obecné řešení to není.

Editoval Šaman (5. 6. 2013 19:56)