Ankündigung

Einklappen
Keine Ankündigung bisher.

Setter vs Constructor Injection

Einklappen

Neue Werbung 2019

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

  • Setter vs Constructor Injection

    Aloah,

    folgender Fall:

    Ich habe mir einen DI-Container / ServiceManager (wie auch immer man das nennen mag und der Unterschied ist) gebaut.

    Im Prinzip werden die Klassen geladen und per Setter-Injection werden die Dependencies injected. Dazu stellt die Klasse einfach eine Settermethode zur Verfügung.

    Jedoch ist mir jetzt erst klar geworden, dass man praktisch die Basisklasse instanziert und erst dann die Dependencies injected, was natürlich ziemlich blöd ist, wenn man z.B. im Konstruktor schon auf die Dependencies zugreifen möchte. Zur Runtime sind diese nämlich noch gar nicht vorhanden (da noch nicht injeziert).

    Irgendwelche Ideen, wie man dies beheben könnte? Mit der Constructor Injection habe ich ein paar technische Probleme v.a. mit der Argumentübergabe (explizit: wie kann der Container dynamisch auf die geforderten Argumente reagieren?)

    Liebe Grüße

    Gruber's Hans

  • #2
    Wie du schon erkannt hast, haben beide Varianten ihre Vor- und Nachteile. Um explizite Abhängigkeiten zu injizieren macht es nach den OO-Prinzipien definitiv Sinn, abhängige Elemente im Konstruktor zu injizieren.

    Andererseits ist es einfacher und auch hinsichtlich eines Interfaces schöner zu realisieren über Methoden zu injizieren. Ich habe mich für letzteres entschieden, da die Konfiguration in dann einfacher zu realisieren ist (siehe http://adventure-php-framework.org/S...plexe-Services).
    Viele Grüße,
    Dr.E.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    1. Think about software design [B]before[/B] you start to write code!
    2. Discuss and review it together with [B]experts[/B]!
    3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
    4. Write [I][B]clean and reusable[/B][/I] software only!
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Kommentar


    • #3
      Zitat von Gruber's Hans Beitrag anzeigen
      Irgendwelche Ideen, wie man dies beheben könnte? Mit der Constructor Injection habe ich ein paar technische Probleme v.a. mit der Argumentübergabe (explizit: wie kann der Container dynamisch auf die geforderten Argumente reagieren?)
      Evil eval, Reflection?
      Oder, was mir spontan noch einfällt, create_function().
      Am ehesten würde ich aber zur Reflection tendieren, auch wenn die aufwändiger ist.

      Vielleicht findest du auch noch ein paar Inspirationen in exTSend_DIContainer.
      VokeIT GmbH & Co. KG - VokeIT-oss @ github

      Kommentar


      • #4
        Zitat von G.Schuster Beitrag anzeigen
        Evil eval, Reflection?
        Oder, was mir spontan noch einfällt, create_function().
        Am ehesten würde ich aber zur Reflection tendieren, auch wenn die aufwändiger ist.

        Vielleicht findest du auch noch ein paar Inspirationen in exTSend_DIContainer.
        mit evil eval bin ich durch. Reflectionclasses wollte ich mir diesbezüglich noch einmal anschauen.

        Hat jemand vielleicht ein Beispiel für eine generische Factory? Die müsste doch auch dynamisch auf geforderte Argumente reagieren?

        Ich hatte auch schon daran gedacht die Dependencies einfach in einem array an die Klasse zu übergeben und es der Klasse dann zu überlassen, wie die Objekte integriert werden, wobei mir dieser Ansatz nicht wirklich gefällt. Ich würde gerne so viel wie möglich im Container selber machen.

        Kommentar


        • #5
          Ich habe mir jetzt mal die ReflectionAPI angesehen und werde den Container wohl so umsetzen.

          Hat jemand 'ne Ahnung wie performant die API ist?

          Kommentar


          • #6
            du kannst dir auch gerne mal meinen dic anschauen, meiner meinung nach habe ich da was echt cooles geschaffen. Testabdeckung ~99% und Doku existieren auch.
            http://anydi.ainfach.de

            im schnitt ist sowas 50-70x langsamer als ein einfaches new statement, die reflextion api ist erstaunlich flott.

            Kommentar


            • #7
              Normalerweise "baut" man sich seinen DIC zur "compiletime", sodass man zur runtime keine Nachteile hat durch Performanceverluste. Alles andere ist eher kappes... Skaliert ja dann nicht so gut.

              Kommentar

              Lädt...
              X