@inject v service nefunguje v potomkovi

Update:

Zkusil jsem místo @inject použít metodu inject*. Výsledek je takový, že se metoda inject* vůbec nezavolá. Pokud ale udělám chybu v názvu metody, tak to tracy odchytí jako chybu.

Stále nevím, co s tím.

Polki napsal(a):
Někdo nápady jak to vylepšit?

Nejsprávnější řešení je používat předávání závislostí přes konstruktor, pak nebudeš muset nastavovat nic a @inject anotaci používat maximálně tak v presenterech (na což byla primárně vytvořena).

Pokud na použití @inject trváš z nějakého důvodu (který si umíš ideálně obhájit i jinak, než že jsem línej zduplikovat v potomkovi tu jednu závislost do konstruktoru), tak bych použil decorator:

decorator:
    Some\BaseClass:
        inject: true

Případně tady taháček s doporučeným předáváním závislostí.

Editoval Mysteria (4. 1. 2019 9:09)

MajklNajt napsal(a):

ahoj, v provom rade, injecty sa vykonajú až po __costruct(), takže preto ti dump vráti null

@MajklNajt v úvodu jsem psal toto:

Polki napsal(a):

PS: service1 obsahuje null i v jiných metodách, než v __construct, takže tím, že by se to třeba naplnilo až po konstruktoru to není.

Problém byl v tom, že když se nazapne inject pro potomka, tak se inject neprovede v předkovi.

@Mysteria Jde o to, že se snažím vytvořit rozšíření (jde o službu, co něco umí) a toto má umět to, že je vlastně připravená služba, která se zaregistruje do configu a potom z ní dědíš a tím získáš vlastně přesně ty vlastnosti, co ta služba nabízí, což je její účel. Jenže tato služba má závislosti, které potřebuje načíst a tím pádem je třeba je předat například v konstruktoru. Problém je, že těchto závislostí může být třeba 20.

Tím pádem je celkem problém, když někdo, kdo si toto stáhne bude muset v každém potomkovi co si udělá psát tak rozsáhlý konstruktor, když bude potřebovat svoji další závislost načíst.

Edit: 1
Problém je, že závislosti co potřebuje ta služba mají další závislosti, takže vytváření si ji jinak než pommocí DI by byla sebevražda.

Editoval Polki (4. 1. 2019 11:11)

@Polki použij decorátor co radil @Mysteria . Vyhni se anotaci inject (v presenterech jsou ok), protože porušuje zapouzdření.

final public function injectDependencies(/* tvoje závislosti */) {}

decorator:
	FOO\BAR:
		setup:
			- injectDependencies

Editoval Martk (4. 1. 2019 11:20)

Martk napsal(a):

@Polki použij decorátor co radil @Mysteria . Vyhni se anotaci inject (v presenterech jsou ok), protože porušuje zapouzdření.

final public function injectDependencies(/* tvoje závislosti */) {}

decorator:
	FOO\BAR:
		setup:
			- injectDependencies

@Martk Prosím jaký je rozdíl mezi:

public function injectService1(Service1 $s1) {}

public function injectService2(Service2 $s2) {}

a:

public function injectDependencies(Service1 $s1, Service2 $s2) {}

Jde o nějaký zásadní rozdíl, nebo je to jen věc sytaxe?

myslím takto – namiesto:

class MojaServisa extends PolkihoServisa {

	public function mojaMetoda() {...}

	...
}

spraviť:

class MojaServisa {

	public $polkihoServisa;

	public function __construct(PolkihoServisa $polkihoServisa)
	{
		$this->polkihoServisa = $polkihoServisa;
	}

	public function mojaMetoda() {...}

	...
}

rozdiel bude potom len v používaní, že konečný užívateľ bude namiesto $mojaServisa->polkihoMetoda(); volať $mojaServisa->polkihoServisa->polkihoMetoda();

Editoval MajklNajt (4. 1. 2019 12:08)

Tam jde hlavně o to, aby ty property nebyly public, což s pomocí @inject anotace je problém. Proto se používá pro předávání závislostí ideálně konstruktor a závislosti se přiřazují do private / protected properties.

Editoval GEpic (4. 1. 2019 13:09)

Jo, inject metoda je běžný setter (s tím že Nette framework s nimi navíc umí nějak pracovat podle konvence). Takže zapouzdření je ok. Nicméně setterem by se měly předávat jen nepovinné parametry. Vše, co třída nutně potřebuje, to by se mělo předat v konstruktoru (lépe se pak ladí).

Pokud jdou povinné závislosti přes konstruktor, tak žádná injectDependencies() nedává smysl. Nepovinné závislosti si nastavíš kdy a jak potřebuješ kdykoliv v průběhu životního cyklu. Kromě toho to snižuje čitelnost při ručním vytváření objektu, nebo při nějaké složitější konfiguraci (když potřebuješ nějakou zavislost zadat v configu explicitně, třeba když máš víc instancí jedné třídy a tedy pracuješ se jménem, nikoliv typem).

Dokud je pro tebe automatické injectování závislostí magická skříňka, tak v tom asi rozdíl není. Ale principiálně je v tom stejný rozdíl jako:

<?php
$rect = new Rectangle(3, 5); # dejmež tomu, že pro funkčnost objektu jsou potřeba jen rozměry
$rect->setColor('#0088ff');
$rect->setTransparency(0.25);
$rect->setZIndex(5);

# versus
$rect = new Rectangle;
$rect->getPerimeter(); # error - nemáme ani nutné parametry, náš objekt je v tuhle chvíli neživotaschopný
$rect->setAll(3, 5, '#0088ff', 0.25, 5);
?>