Předávání služeb do Presenteru pomocí DI

To není pseudokonstruktor, ale zcela regulérní setter injection (nikdo netvrdí, že setter může přijímat právě jeden objekt).

Ale ok, zkus to navrhnout tak, jak by se ti to líbilo. Jen je potřeba počítat s tím, že už samotný UI\Presenter má nějaké závislosti a pochopitelně se mohou časem lehce měnit.

Začnu tím, co já bych od toho očekával:

1. Všechny nutné závislosti by se měly ukojit během vytváření objektu, tj. ideálně konstruktorem.
2. Lazy-load služby, které se využijí jen někdy.
3. Předejít možné budoucí změně hlavičky konstruktoru při změnách v závislostech.
4. Objekt by měl dostat pouze ty služby, které fakt potřebuje.

Teď presenter dostává celý systémový service locator (context), což splňuje první tři body, ale není tak docela jasné, co všechno odtamtud může vyžadovat.

Možným řešením by byl samostatný kontejner (sub-context), který by uspokojoval pouze potřeby třídy UI\Presenter a nic víc. Zhruba něco na tenhle způsob:

class PresenterContext
{
	private $systemContext;
	public function __construct(DI\Container $systemContext)
	{
		$this->systemContext = $systemContext;
	}

	public function getHttpRequest()
	{
		return $this->systemContext->httpRequest;
	}

	// ...atd.

}

Výchozí implementace by pouze takto zapouzdřovala podmnožinu service locatoru, ale dala by se v případě potřeby nahradit. Konstruktor bázové třídy by pak vyžadoval pouze tento PresenterContext, další závislosti v potomcích by si pak už pořešili autoři těch potomků (nejčastěji asi dalšími parametry konstruktoru).

U tříd, které si uživatelé fw poděďují, cítím značný rozdíl mezi závislostmi frameworku (o těch nechci pokud možno nic vědět) a závislostmi té poděděné třídy. Ty by naopak měli být co možná nejvíce vidět.

Obecně vidím několik variant:

• všechny závislosti přes konstruktor – značná nevýhoda v tom, že presenter je pak závislý na implementačních detailech fw a při změně závislostí UI\Presenteru je potřeba měnit své presentery
• závislosti uživatele přes konstruktor, závislosti fw setterem – IMHO nejčistší varianta. Uživatel pak může používat DI v presenterech úplně stejně jako je zvyklý kdekoliv jinde a není závislý na implementaci fw.
• závislosti uživatele setterem, závislosti fw přes konstruktor – relativně dobré řešení, ale WTF pro všechny lidi, kteří už DI použili někde jinde a očekávají, že pro své závislosti mají použít konstruktor.
• property injection (ala Java) pro vlastní závislosti – nejsnadnější pro psaní kódu (napíše se jen anotace @inject k property), ale třída pak už nedává tak jasně najevo, jaké jsou její závislosti (je potřeba pročíst kód třídy).

Editoval dundee (28. 2. 2012 8:41)

Zkopíruju sem svůj příspěvek, co jsem psal Davidovi do svého Facebooku:

Největší problém všech dosavadních řešení je to, že se do presenterů injectuje celý kontejner a pak se uvnitř něj používá jako ServiceLocator. To je špatně, protože není vůbec zřejmé, proč se tam vlastně ten kontejner injectuje (tajení závislostí) a co z něj je potřeba a co se předpokládá, že v něm bude nakonfigurováno, aby presenter vůbec běžel.

Takže první a hlavní směr snažení by měl být zrušit injectování celého kontejneru a místo něj injectovat do presenterů jen jednotlivé dílčí služby, které presenter opravdu potřebuje. Tím bychom měli vyřešeno tajení závislostí.

Druhotná diskuze pak je na téma, zda používat constructor injection, nebo setter injection. Obojí je regulérní deklarace závislostí.

Constructor injection je o dost čistější, protože bez něj se mi instance presenteru vůbec nevytvoří. Zatímco u setter injection se musím spolehnout, že mi to tam někdo nasettuje a pak to kontrolovat, že to opravdu udělal. To ale nemá nic společného s tajením závslostí, v obou případech jsou závislosti (narozdíl od injectování kontejneru) jasně deklarované.

A tady přichází na řadu praktičnost celé věci. A z jejího pohledu mi přijde velice smysluplné nechat konstruktor zcela volný pro injectování uživatelských závislostí, které se liší presenter od presenteru. A všechny závislosti, které jsou „systémové“ a napříč naprosto všemi presentery společné, injectovat přes settery. Což je pro vývojáře výhoda (má volný konstruktor a nemusí vůbec řešit tyhle systémové závislosti, protože si to udělá nette samo) a pro Nette to nevadí (ví, jaké systémové závislosti každý jeho presenter má, tak si je tam při vytváření presenteru pokaždé nastrká).

Takže vlastně totéž, co psal Dan Milde výše – závislosti uživatele přes konstruktor, závislosti frameworku setterem.

HosipLan: To je další možnost, všechny FW závislosti předávat v metodě run. Je něco z toho někdy potřeba ještě před startem životního cyklu presenteru? Pokud ne, tak by to mohl klidně dostat až s tím startem, žádnou nevýhodu teď nevidím.

Editoval llook (28. 2. 2012 12:44)

Já rozhodně stojím na straně Honzy a Media.

Setter injection mi na „systémové“ věci přijde mnohem lepší; už jen pokud by se jednoho krásného dne někdo rozhodl Presenteru ulehčit od jeho spousty zodpovědností a vyčlenil z něj různé systémové věci typu flash zprávičky nebo odkazy jako různé služby.

Protože v ten moment, pokud by se vše předávalo konstruktorem, tak máme docela šíleně zabordelené konstruktory s XY parametry … a nechtěl bych zažít ten očistec, který by nastal v ten moment, kdy bych potřeboval nějakému předkovi přidat další službu. :)

„Strana“ nebylo nejlepší vyjádření, „pohled na věc“ (Constructor/setter injection) by asi bylo lepší vyjádření, ale teďka to už zpětně editovat nebudu. :)

Ale RFCčko by bylo vhodnější než tweet, to jo, no. Nicméně diskusi by to IMHO vyprodukovalo víceméně podobnou… ?

OT: k tomu lazy-loadingu – nedalo by se to vyřešit tak, že by se kromě SystemContaineru vygenerovaly i rozšiřující třídy pro proxy-objekty (wrappery) pro každou službu? Ty by si držely továrničku a pomocí __get(), __call() apod. vytvořily objekt až když si na něj někdo sáhne a jinak jenom delegovaly chování na obalený objekt.

Je to trochu prasárna, ale prošlo by to typehintingem a instanceof. Jedinej problém by byl s get_class() a obsazením jména property pro továrničku a pro obalovaný objekt.

Muselo by se to trochu líp promyslet, ale neříkejte že jsem první koho tenhle přístup napadl.

Edit:

Případně pomocí reflexe pro:

class Service {
  public function test($param) {
    ...
  }
}

vygenerovat něco jako:

class LazyService extends Service {
  private $_factory;
  private $_object;

  public function __construct($factory) {
    $this->_factory = $factory;
  }

  public function test($param) {
    if ($this->_object === null) {
      $this->object = $this->_factory->create();
    }
    return $this->_object->test($param);
  }
}

Editoval mkoubik (28. 2. 2012 18:03)

jantichy napsal(a):

Největší problém všech dosavadních řešení je to, že se do presenterů injectuje celý kontejner a pak se uvnitř něj používá jako ServiceLocator. To je špatně

Ale to přece všichni víme, o tom není vůbec potřeba diskutovat a předělá se to v momentě, kdy bude jasné, jak to předělat, tedy jestli ty věci injektovat přes settery nebo přes konstruktor.

Druhotná diskuze pak je na téma, zda používat constructor injection, nebo setter injection. Obojí je regulérní deklarace závislostí.

To je pro mě primární diskuse, protože když není jasné, jak tam ty závislosti dostat, tak to zatím neřeším. Až to bude jasné, tak se změní jen pár řádků.

Constructor injection je o dost čistější, protože bez něj se mi instance presenteru vůbec nevytvoří. Zatímco u setter injection se musím spolehnout, že mi to tam někdo nasettuje a pak to kontrolovat, že to opravdu udělal. To ale nemá nic společného s tajením závslostí, v obou případech jsou závislosti (narozdíl od injectování kontejneru) jasně deklarované.

Konstruktor injection je více zřejmé než setter injection. Za chvíli se k tomu vrátím.

Vysvětli mi prosím, proč jsi dělal takový povyk, když jsem použil konstruktor injection. Doslova jsi napsal, že „blokuju konstruktory presenterů“. A to jsem tam měl jen jednu ze cca 4 závislostí (ano, i samotný kontejner je z důvodu kompatibility závislost, byť dočasná, nicméně v tuto chvíli doufám nehodnotíme, jaké závislosti presenter má, takže jde o závislost jako každou jinou).

Na jedné straně píšeš, že „constructor injection je o dost čistější“ (zcela souhlasím), na druhé straně šílíte, že vám „blokuju konstruktory presenterů“ :-))

A tady přichází na řadu praktičnost celé věci. A z jejího pohledu mi přijde velice smysluplné nechat konstruktor zcela volný pro injectování uživatelských závislostí, které se liší presenter od presenteru. A všechny závislosti, které jsou „systémové“ a napříč naprosto všemi presentery společné, injectovat přes settery.

(Neexistují žádné systémové závislosti, to jsou úplně normální závislosti třídy UI\Presenter)

Což je pro vývojáře výhoda (má volný konstruktor a nemusí vůbec řešit tyhle systémové závislosti, protože si to udělá nette samo) a pro Nette to nevadí (ví, jaké systémové závislosti každý jeho presenter má, tak si je tam při vytváření presenteru pokaždé nastrká).

Jinými slovy žádáš: udělej závislosti třídy UI\Presenter méně zřejmé..

Bulvárně řečeno: Medio nesmyslně zabíjí DI tak, že chce více tajit závislosti presenterů. To jako vážně? Uááá

Podstatné je to, že jsi nedal žádný argument, proč lepší setter než konstruktor. Slova „přijde mi velice smysluplné“ nejsou argument, mně zase přijde (třeba) velice smysluplné to udělat naopak a závislosti Presenteru přenášet přes konstruktor a uživatelské závislosti přes uživatelkou funkci, která tam k tomu je a jmenuje se setContext.

Tak se pojďme přestat pošťuchovat a dejme dohromady argumenty pro nebo proti konstruktoru. (u UI\Presenter)

Já bych si dovolil trošku zlehčit Davidovo PROTI. V IDE kliknu „overide methods“ > „__construct“ a zmíněnou konstrukci mi doplní. V konstruktoru by se mohla provádět stejná kontrola, jako ve startup().

PROTI:

• „strašně“ dlouhý konstruktor
• musím se ručně starat o předání závislostí presenteru, když chci předávat svoje služby
• u setteru se mi o to může „automaticky“ starat DIC a nemusím o tom vědět, popřípadě se to dá zjednoduššit pomocí „abstraktní definice“ a můžu si dědit závislosti

services:
	presenter:
		setup:
			- setHttpRequest
			- setRouter
	...

	myPresenter < presenter:
		class: MyPresenter(@model)

Nenapadají mě výhody při předávání závislostí presenteru UI\Presenter v konstruktoru.

Editoval HosipLan (28. 2. 2012 21:47)

PRO:

• při použití autowiringu se dá zcela vynechat konfigurace presenteru (není potřeba v konfigu vyjmenovat závislosti), což u setter injection nejde
• doporučovaný způsob předávání závislostí
• nezatajuje závislosti
• pokud zůstane konstruktor volný pro DI uživatelů, budou moci používat jak konstruktor, tak vlastní settery. Budou mít možnost volby. Pokud se konstruktor bude používat pro interní závislosti UI\Presenteru, těžko ho bude moct někdo ještě použít a bude nucen použít settery.

PROTI:

• parametrů konstruktoru může být hodně (při špatném návrhu presenterů)

Co se týče těch tweetů, tak nemůžu mluvit za Honzu, ale já jsem rozhodně nereagoval na to, že nově používáš u UI\Presenter constructor injection, ale na to, že takhle viditelným předáním kontejneru do presenteru nabádáš lidi ještě více než kdy dřív k používání anti-patternu ServiceLocator. Už slyším vývojáře: „Chtěl jsem zkusit DI u presenterů, ale pak jsem zjistil, že už se tam předává kontejner, tak jsem si všechno vytáhl z něj.“. Kdyby se tam kontejner předával méně okatě, tak si toho vývojář třeba ani nevšimne a použije standardní a doporučované DI.

David Grudl napsal(a):

UI\Presenteru nebo presenteru?

*nenapadají mě výhody předávání závislostí potřebných pro chod UI\Presenter přes konstruktor (viz výše)

Té argumentaci moc nerozumím, při použití setContext() jsi přece žádný konstruktor neřešil, nebo ne?

Tedy otázkou je, jestli uživatelský (programátora) konstruktor bude setContext(), nebo __construct()? Může mi tedy vzniknout několik situací

Všechno předávám konstruktorem

UI\Presenter i můj potomek mají všechny služby pěkně vyjmenované, krásně mi je tam doplní autowiring je to voňavé a teoreticky dokonalé. Až na to, že v dalších potomcích se upíšu, abych předal všechno, co potřebuje rodič i potomek a nechci vidět další zanoření a že jsem jich viděl…

Přesně z tohohle důvodu jsem začal razit připojování komponent pomocí return v továrničce a né konstruktorem (new Component($parent, $name)), protože mi vadilo hlídat argumenty předka.

Construktor for UI\Presenter reserved

Smířím se s tím, že UI\Presenter mi zaterasil konstruktor a nebudu ho používat. Budu mít settery na svoje služby a nebudu řešit předávání služeb UI\Presenter rodiči, když ho budu chtít překrýt.

To není moc dobré řešení

Constructor jenom pro uživatele

Nette ustoupí (přesně to co jsi commitl) a constructor uvolní a já si přes ně budu moct předávat svoje věci. Nette si pak někde samo bude doplňovat co potřebuje UI\Presenter. Tohle mi příjde jako dobrá cesta.

Kdyby Nette závilosti (UI\Presenter) byly v konstruktoru, tak mi to může eventuelně vadit v momentě, když bych chtěl vlastní třídy, protože mám vžité na vytváření třídy používat __construct() a je to konstrukce jazyka, nechci používat pseudo-kostruktoru setContext(), ten může používat Nette, protože se to dá krásně zautomatizovat.

Jak jsem psal výše, když budu mít pro sebe __construct() (ten bych taky chtěl používat pro své služby) tak je mi jedno, že Nette si svoje věci předává přes setContext().

Tady je ale nevýhoda z teoretického hlediska, kdy můžu vytvořit instanci UI\Presenter, která nebude fungovat správně, bude existovat, ale nespustím ji. V momentě spuštění totiž začne naříkat, že jí něco chybí.

DIC se stará jako o setContext(), tak o konstruktor.

Ano stará, otázka je, který bude „můj“.

A argumenty ídéčkem neberu vůbec.

ok, to chapu

dundee napsal(a):

nabádáš lidi ještě více než kdy dřív k používání anti-patternu ServiceLocator.

Sranda je, že takto je nabádá i Symfony, oni se asi nesmířili s tím, že by v controllerech neměli lazy-loading služeb. Just saying.

…

Kolem a kolem: Přepsal jsem si kompletně DI v Nette na Symfony DIC a všechny Nette služby injectoval setterama. Používal jsem DIC přes Presenter::setContext($context) i přes Presenter::__construct($context). A ze všeho toho byla z praktického hlediska nejmenší bolest DIC v konstruktoru (service locator).

Jsme banda masochistů :)

Dobře, svůj výše uvedený dlouhý příspěvek shrnu do krátkých bodů. Jaké jsou výhody předávání systémových závislostí přes setter injection a uživatelských přes konstruktor:

• Eliminuje to opakované psaní téhož kódu a tedy zbytečnou práci a prostor pro chyby. Nemusím v každém presenteru zas a znova ručně přehazovat všechny „systémové“ závislosti, které se opakují napříč všemi presentery.
• Přehlednější oddělení „uživatelských“ závislostí specifických pro daný presenter, které chci vidět hned, od „systémových“ závislostí, které se opakují v úplně každém presenteru, kterých může být (a mělo by být) v budoucnu hodně a mezi kterými by se mohly ty zajímavé specifické ztratit.
• Interní chování frameworku se jakoby „zapouzdřuje“ tak, že jeho změny nezasahují do aplikace samotné. Možnost jakýchkoliv flexibilních budoucích změn a refactoringu v samotném frameworku. Po každé změně ve frameworku se mi nerozseká aplikace, nebudu muset pokaždé polovinu aplikace přepsat, vše bude fungovat.

David Grudl napsal(a):

• PRO: konstruktor má tu magickou vlastnost, že nemusí udržovat kompatibilitu argumentů s předkem. Tedy při dědičnosti presenterů není třeba nové služby přidávat s hloupým =NULL
• PROTI: při přepisování konstruktorů zapomene 9/10 programátorů zavolat parent::__construct().

Tohle je myslím jenom implementační detail. Protože s tím, co já navrhuji výše, by UI\Presenter měl konstruktor úplně prázdný. Takže by se v potomcích od něj nemusela dodržovat žádná kompatibilita s ničím a nemuselo by se ani myslet na volání parent::__construct(). Takže zase o pár problémů a věcí k zapamatování méně.

Argumenty z mého pohodlného pohledu vývojáře (přičemž se vůbec nechci starat o předávání systémových závislostí, protože de facto vždycky je chci mít na místě):

b) Systémové závislosti injectovat přes settery a uživatelské injectovat přes konstruktor.

c) Systémové závislosti injectovat přes konstruktor a uživatelské injectovat přes settery.

U mě nakonec vítězí vlastní služby přes konstruktor.

Editoval vojtech.dobes (29. 2. 2012 16:02)

dundee napsal(a):

• vývojář hned vidí, jaké uživatelské závislostí tam jsou

Ale právě naopak! Vypadá to, že závislostí je mnohem méně, než jich tam doopravdy je. Prostě tzv „systémové“ (zavádějící termín) nejsou vidět. Presenter, který nemá žádné vlastní závislosti, budí dojem, že nemá žádné závislosti. (Viz tvé mínus: není na první pohled patrné, jaké uživatelské závislosti presenter má)

lze použít vyšší level autowiringu

Můžeš to prosím rozvést?

Já bych si taky dovolil se svojí troškou…

Prvně, to jak budou zadávaný uživatelský služby podle mě s řešením moc vážně nesouvisí, s drbornou vyjímkou níže, a viděl bych to jako best practice do dokumentace… nevim proč uživatele(programátora) omezovat v tom jak zadávat jeho vlastní služby… Když chce setter nastaví si setter, když chce konstruktor nastaví si konstruktor…

K systémovým bych používal spíš settery a to ze tří důvodů:

1. pokud použiju konstruktor tak ho prakticky zabiju pro uživatele, každá změna byť jen pořadí nebo typu v parametrech si vyžádá zásah do aplikace a úpravy, který budou ve většině případů jenom pro to abych změnil pár písmenek a na samotnou logiku bez vlivu, to mě přijde jako zbytečný puritánství…
2. když použiju settery tak budu muset dělat úpravy jenom pokud dojde k opravdu zásadní změně… A to si myslim bude případ v řádech desetin promile, takže změna služeb bude mít dopad na aplikace blízký nule…
3. Když použiju setter tak je můžu přetěžovat(ano konstruktor taky, já vim) a například při nastavení služby vytvořit/nastavit ty uživatelský služby/objekty který takovou službu potřebujou nebo například pokud je chci logovat…

Ano, settery jsou víc magický pro testování, ale opravdu je to zrovna u presenterů takovej problém?

awsickness napsal(a):

neslo by udela nekde poll se 3 / 4 variantama a podle toho jak se to odvoli tak se to pouzije ? takhle se to tu davaji porad ty same + a – takze to hlasovani by mozna nebylo od veci.

This is not Nette-way ;)

David Grudl napsal(a):
Ale právě naopak! Vypadá to, že závislostí je mnohem méně, než jich tam doopravdy je. Prostě tzv „systémové“ (zavádějící termín) nejsou vidět.

Viz můj post o něco výše. Opravdu potřebuji znát systémové závislosti (a to rozdělení opravdu má smysl) presenteru? Já si to nemyslím. Když presenter konfiguruju, potřebuju znát pouze ty uživatelské. O ty systémové by se měla postarat PresenterFactory.

lze použít vyšší level autowiringu

Můžeš to prosím rozvést?

Nevím, jestli to Nette kontejner umí, ale my používáme upravený kontejner ze Symfony a ten umí to, že přes reflexi zjistí jaké závislosti třída potřebuje a pokud tyto závislosti je schopný vytvořit, tak třídu instancuje i bez explicitně napsané konfigurace. Tedy stačí třeba něco takového:

<?php
  presenter_front_offer:
    class: HomeSweetHome\FrontModule\OfferPresenter
?>

Chceš tím tedy říct, že protože jsou všechny závislosti stejně důležité, měli bychom je předávat všechny konstruktorem? Měl jsem dojem, že jsi před chvíli psal, že to rozhodně nechceš.

Honza: * a – Všechny závislosti obou typů injectovat přes konstruktor.*
Ty: Variantu a) jako naprosto nepoužitelnou nemusíme snad vůbec brát v úvahu, to je zcela zřejmé.

Jakým způsobem to, krom konstruktoru, může zjistit?

Může to zjistit z konstruktoru. Proč bych měl chtít něco víc? Tohle je jeden z důvodů, proč se doporučuje constructor injection. V případě, že takovýhle autowiring nepoužiješ, tak se u většího projektu z psaní konfigurace brzy zblázníš.

dundee napsal(a):

Chceš tím tedy říct, že protože jsou všechny závislosti stejně důležité, měli bychom je předávat všechny konstruktorem? Měl jsem dojem, že jsi před chvíli psal, že to rozhodně nechceš.

Onu variantu, v tuto chvíli jednu z pěti variant, rozhodně nechci, je zcela mimo hru. Mezi dalšími variantami stále váhám.

Může to zjistit z konstruktoru. Proč bych měl chtít něco víc? Tohle je jeden z důvodů, proč se doporučuje constructor injection. V případě, že takovýhle autowiring nepoužiješ, tak se u většího projektu z psaní konfigurace brzy zblázníš.

Dane, bavíš se se mnou jako s malým dítětem. Ano, Nette umí autowiring, Nette dokonce umí předávat presenterům uživatelské i systémové závislosti (fakt!), a dělá to tak už nějaký pátek. Rozhodně nezabíjí, na rozdíl od této diskuse, DI ;-)

Psal jsi mi, že vám stačí napsat class: HomeSweetHome\FrontModule\OfferPresenter a autowiring všechno vyřeší. Já se ptám, jak vyřeší tebou preferovaný stav, kdy v konstruktoru budou jen uživatelské služby a na „systémové“ se použijí settery. Jak jeden řádek předá presenteru „systémové“ objekty Http\Request nebo Router, které potřebuje ke generování odkazů?

dundee napsal(a):

Psal jsi mi, že vám stačí napsat class: HomeSweetHome\FrontModule\OfferPresenter
a autowiring všechno vyřeší.
Já se ptám, jak vyřeší tebou preferovaný stav, kdy v konstruktoru budou jen
uživatelské služby a na „systémové“ se použijí settery.
Jak jeden řádek předá presenteru „systémové“ objekty Http\Request nebo Router,
které potřebuje ke >generování odkazů?

Davide, psal jsem to tu už několikrát. Systémové závislosti by mohla do presenteru dodat PresenterFactory. PresenterFactory si je bude buď tahat z kontejneru a nebo je dostane jako závislosti konstruktorem.

Pokud to dobře chápu tak @dundee to myslí tak že to bude fungovat stejně jako teď (presenterFactory explicitně volá setContext nad presenterem a cpe mu tam tak závyslosti pomocí autowire). Jen né pro „uživatelské“ ale pro „systémové“ závyslosti.

Tj. bylo by tam něco takového:

/**
 * Create new presenter instance.
 * @param  string  presenter name
 * @return IPresenter
 */
public function createPresenter($name)
{
	$presenter = $this->context->createInstance($this->getPresenterClass($name));
	$this->context->callMethod(array($presenter, 'setRequest'));
	$this->context->callMethod(array($presenter, 'setResponse'));
	$this->context->callMethod(array($presenter, 'setApplication'));
	// ...
	return $presenter;
}

Dalo by se to řešit i tak další variantou:

class Presenter extends \Nette\Application\UI\Presenter
{
	public function setContext(Request $request, Response $response, Application $application, ...)
	{
		//...
	}
}

/**
 * Create new presenter instance.
 * @param  string  presenter name
 * @return IPresenter
 */
public function createPresenter($name)
{
	$presenter = $this->context->createInstance($this->getPresenterClass($name));
	$this->context->callMethod(array($presenter, 'setContext'));
	return $presenter;
}

Tj. že by se prohodilo stávající fungování a místo containeru se předávali „systémové“ závyslosti jako jednotlivé argumenty metody setContext.

@Patrik: Nevýhoda varianty D je, že ti nedává žádnou jinou možnost, než injectovat uživatelské závislosti přes ten jeden setter (případně víc setterů). Varianta B přináší větší svobodu, protože pak pro uživatelské závislosti můžeš použít konstruktor, jeden setter nebo víc setterů. To znamená, že nikdo nemusí nic přepisovat, varianta B se přizpůsobí všem požadavkům.

Líbí se mi, co píše @**dundee**, protože kdo jiný, než @presenterFactory, by měl vytvářet presenter. Tedy o settery se postará on, nad konstruktorem zavolá autowire, nebo podle naming-convention by se mohl podívat, jestli neexistuje služba/factory se stejným názvem a použil tu.

O systémové závislosti UI\Presenter by se tedy staral vždy @presenterFactory. Stačí tedy prohlásit za standard, že na vytvoření libovolného presenteru se musí použít @presenterFactory a je po problému se skrytým závislostmi :)