dsentker

Hallo,

ins Rollen kamen meine Überlegungen, als ich die Methode meines DI-Containers (ServiceContainers) "get()" überdachte, um an ein Objekt des Services zu gelangen.

Im konkreten Fall ging es darum, vom Controller aus eine weitere View zu instanziieren. Die Methode "get()" wirkt hier etwas irreführend auf mich, da man, genau betrachtet, ja kein Objekt erhalten möchte, sondern explizit ein neues erstellen möchte. Ich kam erst auf die Idee, eine Alias-Methode "create()" bereitzustellen, die genau das gleiche tut.

Aber dann dachte ich daran, get() und create() logisch zu trennen: get() würde demnach explizit eine Singleton-Instanz erstellen, create() ein neues Objekt. Das würde aber meinem Grundsatz widersprechen, dass der Service selbst (z.B. via Konfiguration) festlegt, ob er als Singleton abgerufen wird oder nicht.

Wie seht ihr das? Sollten Singleton-Instanzen aus dem DI-Container "on demand" erfolgen? Wenn ja, würde euch stören, ein get() zu benutzen, wenn etwas neues erstellt werden soll?

__________________

Mister Ad

nikosch

Ich finde ja nicht, dass eine Bezeichnerdiskussion ins FG-Forum gehört. Aber naja. Meinetwegen kannst Du das auch fetch() oder retrieve() oder anders nennen, aber get() finde ich recht naheliegend. Ein Service-Container, der immer eine neue Instanz liefert, will mir keinen rechten Sinn ergeben.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

dsentker

Wenn ich falsch kategorisiert habe, tut es mir leid, jedoch denke ich nicht dass Anfänger etwas mit einem ServiceContainer anfangen können. Es geht ja außerdem nicht nur um die Frage zur Benennung einer Methode, sondern ob eine Singleton-Instanz für den Container fest in der Config verankert sein soll.

Nein, nicht immer. Aber dann, wenn der Service es per Konfiguration veranschlagt hat. Es bleibt eben nur die Frage, ob man das nicht bei Bedarf entscheidet (quasi in der betreffenden Controller-Action, z.B.)

__________________

Trainmaster

Im Kontext eines DI-Containers betrachte ich die get()-Methode differenzierter. Sofern zur Laufzeit ein bestimmter Service zum ersten Mal angefordert wird, wird in der Tat ein neues Objekt erstellt und zurückgegeben. Sofern der Service zum wiederholten Male angefordert wird, würde ich schon davon sprechen, dass ich mit dem Aufruf der get()-Methode ein bestimmtes Objekt erhalten möchte. Demnach kann ich deine Auffassung bezüglich der get()-Methode nicht ganzheitlich teilen.

Schon mal darüber nachgedackt, via get() eine Factory anzufordern?

dsentker

Damit meinst du also, dass im Zusammenhang mit einem DI-Container "get()" durchaus für eine neue Instanz stehen könnte?

Ehrlich gesagt, nein. Das liegt aber zum einen vielleicht daran, dass
a) man ja durchaus die Factory als Service definieren kann und
b) ich eh kaum mit Factories arbeite

__________________

nikosch

Fände ich hier aber konsequenter, wenn Du immer neue Instanzen benötigst.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

dsentker

Okay, in der Tat könnte die View eine Factory gebrauchen. Es muss ja allerhand zugewiesen werden, etwa der Renderer, die Konfigruation etc.

Meine View erfordert im Konstruktor die Angabe einer Konfiguration sowie die eines Renderers.
Ich handhabte es so, dass die Config und der Renderer selbst ein Service ist. Per DI krallt sich der Service "View" also den Service "Config" und "ViewRenderer". Ist das denn so falsch?

__________________

Trainmaster

Streng genommen steht sie für eine neue Instanz, sofern der Service zum ersten Mal angefordert wird. Bis zu diesem Zeitpunkt besteht noch keine Instanz des angeforderten Service. Der erstmalige Aufruf bewirkt, dass eine neue Instanz des angegebenen Objekts erzeugt wird. Bei allen weiteren Aufrufen wird eben diese Instanz zurückgegeben. So jedenfalls habe ich das Konzept eines DI/Service-Containers verstanden.

dsentker

Bist du dir sicher? Ein DI-Container kann doch nicht nur Singletons...?

__________________

dr.e.

Dann ist das aber nicht nur ein DI-Container, sondern auch ein service locator und eine abstract factory...

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~