Ankündigung

Einklappen
Keine Ankündigung bisher.

DI-Container Key

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • notyyy
    hat ein Thema erstellt DI-Container Key.

    DI-Container Key

    Hallo,

    ich bin mir derzeit unterschiedliche DI Container am anschauen und kann teilweise einige Sachen nicht nachvollziehen. Ganz besonders die Tatsache, dass man Services einfach nur einen namen gibt und mit dem Servicenamen arbeitet.

    Hat uns die OOProgrammierung dafür nicht interfaces geschenkt?

    Beispiel:

    $di->get('service.logger');

    hier wird anhand des strings service.logger der logger geholt. dabei ist völlig unklar was der logger für ein objekt ist und welche methoden dieser implementiert.

    warum nicht so?:

    $di->get('\framework\iLogger');

    der unterschied ist, dass der DI Container nun die richtige Klasse für das Interface zurück gibt. Als Key kann also nur ein Interface verwendet werden.

    Es sollte ja sowieso so sein, das jedes Interface nicht einen gewissen concern angehaftet ist. demnach sollte dies doch völlig problemlos möglich sein?

    ich wäre auch super dankbar wenn ihr mir näher bringen könntet, warum meine lösung schlecht ist

  • notyyy
    antwortet
    Zitat von fab Beitrag anzeigen
    Aber dafür sollten sich doch auch die Concerns benutzen lassen, es hindert mich ja niemand daran, für verschiedene Concerns die selbe Klasse mit unterschiedlichen Konfigurationen zu verwenden. Oder übersehe ich da etwas?
    genau dafür sind die concerns da

    praktisches Beispiel:
    Tool welches 2 Datenbankverbindungen benötigt.


    um nochmal etwas für Aufklärung zu sorgen:

    du kannst beliebig viele implementationen an ein interface binden und diese alle gleichzeitig nutzen, man muss nur für jedes dieser bindings ein "Belang (Concern)" angeben.

    Einen Kommentar schreiben:


  • fab
    antwortet
    Zitat von xm22 Beitrag anzeigen
    Mich überzeugt das dahin gehend nicht, dass Du halt pro Interface letztendlich nur einen _einzigen_ Service anbieten kannst. Durch das Dekorieren besteht ja immer die Gefahr, dass die dekorierten Services beeinflusst werden.. Was ist aus der Sache geworden, optional zum Interface einen Namen zu übergeben?
    Ich hatte mir die Doku gestern mal angesehen und genau die Frage stellte sich mir auch, ansonsten gefiel mir der Ansatz nämlich durchaus.

    Aber dafür sollten sich doch auch die Concerns benutzen lassen, es hindert mich ja niemand daran, für verschiedene Concerns die selbe Klasse mit unterschiedlichen Konfigurationen zu verwenden. Oder übersehe ich da etwas?

    Einen Kommentar schreiben:


  • notyyy
    antwortet
    Zitat von mYkon Beitrag anzeigen
    Ist der Code eigentlich irgendwo verfügbar von dir @notyyy ?
    Doku:
    http://anydi.ainfach.de/

    Code:
    [url]https://github.com/timglabisch/pimDI[/url

    PS:
    Beitrag 1000 !!!

    Einen Kommentar schreiben:


  • notyyy
    antwortet
    Zitat von xm22 Beitrag anzeigen
    Aber hiermit wird es Frickelei
    ich werde das in aller ruhe evaluieren und erstmal in einem branch entwickeln, vielleicht hast du recht und diese idee wird nie released. derzeit steht erstmal caching ganz oben auf der todo

    Einen Kommentar schreiben:


  • xm22
    antwortet
    ein interface anzulegen und zur laufzeit zu prüfen ob das interface auf eine klasse passt
    Hm.. Bisher war Deine Lösung ja ziemlich sauber, auch wenn mir das Prinzip selbst nicht so gefällt (Das ist ja Ansichtssache). Aber hiermit wird es Frickelei

    Einen Kommentar schreiben:


  • mYkon
    antwortet
    Ist der Code eigentlich irgendwo verfügbar von dir @notyyy ?

    Einen Kommentar schreiben:


  • notyyy
    antwortet
    Du halt pro Interface letztendlich nur einen _einzigen_ Service anbieten kannst
    google denkt da genauso wie ich (guice). Du kannst nur das tauschen wo du dir sicher bist das es passt, demnach wird ein interface benötigt.
    demnächst wird es die möglichkeit geben ein interface anzulegen und zur laufzeit zu prüfen ob das interface auf eine klasse passt, dank caching wird dies performant genug sein. so hast du z.b. die möglichkeit ein Interface für Zend_Mail anzulegen und die Klasse an das Interface zu binden ohne das diese das Interface explizit implementiert. die Prüfung findet zur Laufzeit statt und es funktioniert nicht bei der Konstruktor/Getter injection.

    Ein Interface gewährt auch, dass die Code Completion funktioniert. Ich schreibe lieber ein Interface mehr und habe dadurch eine brauchbare Code Completion.

    Was ist aus der Sache geworden, optional zum Interface einen Namen zu übergeben?
    ah ich glaube ich hatte die Frage kurzzeitig falsch verstanden. siehe Antwort oben.

    Dein DIC Konzept überzeugt mich überhaupt nicht.
    Ich lege sehr viel wert auf deine Meinung, ich würde mich weiterhin über konstruktive Kritik freuen. Hast du dir mal Google Guice angeschaut? gefällt dir dieser DiC?

    Decoratoren sind eher die Ausnahme und ermöglichen lediglich das spätere Modifizieren von Services. Als Entwickler wirst du diese wohl nur nutzen wenn du eine bestehende Funktionalität erweitern möchtest.

    Einen Kommentar schreiben:


  • xm22
    antwortet
    Mich überzeugt das dahin gehend nicht, dass Du halt pro Interface letztendlich nur einen _einzigen_ Service anbieten kannst. Durch das Dekorieren besteht ja immer die Gefahr, dass die dekorierten Services beeinflusst werden.. Was ist aus der Sache geworden, optional zum Interface einen Namen zu übergeben?

    Einen Kommentar schreiben:


  • nikosch
    antwortet
    Ich hab ja letztes mal schon gemeckert. Keine Ahnung - Dein DIC Konzept überzeugt mich überhaupt nicht.

    PS: Wenn überhaupt solltest Du die Sevices Decoratable nennen. Im Normalfall weiß ein dekoriertes Objekt allerdings nicht, ob es dekoriert ist. Von daher schon ein seltsames Konzept.

    Einen Kommentar schreiben:


  • xm22
    antwortet
    Ah ok - Jetzt habe ich es verstanden.

    Einen Kommentar schreiben:


  • notyyy
    antwortet
    nein es gibt beide möglichkeiten
    PHP-Code:
    $di->bind('interface')->to('service')
    $di->bind('interface')->to('service2'
    interface ist auf service2 gebunden

    PHP-Code:
    $di->bind('interface')->to('service')
    $di->bind('interface')->to('service2')->decorated(true
    interface ist auf service2(service()) gebunden

    PHP-Code:
    $di->bind('interface')->to('service')
    $di->bind('interface')->decoratedWith('service2'
    interface ist auf service2(service()) gebunden

    bei den letzen beiden beispielen ist klar das service2 ein decorator ist. beim ersten beispiel braucht er kein decorator zu sein.

    du musst dir also vorher klar sein, will ich einen service decorieren oder neu binden.

    Einen Kommentar schreiben:


  • xm22
    antwortet
    Versteh ich immer noch nicht. Wenn Du mehrere Services an ein Interface binden willst, dann hast Du geschrieben, werden diese dekoriert. Das setzt doch aber voraus, dass die Services Dekorieren und dekoriert werden können..

    Einen Kommentar schreiben:


  • notyyy
    antwortet
    Zitat von nikosch Beitrag anzeigen
    Ein Decorator braucht ein Type-Hint, um das Interface des dekorierten Objekts zu kennen (bzw. garantiert zu haben).
    ja, habe ich etwas anderes gesagt? der service der decoriert wird muss jedoch kein decorator sein.

    decorator(decorator(service))

    wichtig ist nur das alle das selbe interface (iService in diesem Falle) implementieren.

    braucht ein Type-Hint
    brauchen in Bezug auf php und typisierung stimmt wohl nicht der Type hint ist aber angebracht!

    Einen Kommentar schreiben:


  • nikosch
    antwortet
    Das fragst Du uns? Anscheinend weißt Du doch nicht, wie Decorator funktionieren.
    der service selber muss dies nicht unterstützen warum auch?
    wenn man den service decorieren will, dann muss der "DECORATED_service" dies unterstützen.
    Ähm, häh? Ein Decorator braucht ein Type-Hint, um das Interface des dekorierten Objekts zu kennen (bzw. garantiert zu haben).

    Einen Kommentar schreiben:

Lädt...
X