Ankündigung

Einklappen
Keine Ankündigung bisher.

Dependency Injection

Einklappen

Neue Werbung 2019

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

  • Dependency Injection

    Hallo Zusammen!

    Ich hätte eine generelle Frage zur Nutzen von Dependency Injection.
    Ziel ist es ja möglichst alle Klassen unabhängig von einander zu entwickeln, so dass der Programmablauf gut testbar und auch wiederverwendbar ist.

    Zu meiner Frage, kann man nun generell sagen, der beste Weg ist z.B. die Interface Injection? Oder wie handhabt ihr das ganze?

    Beste Grüße

  • #2
    Ob du gegen konkrete Implementierungen / Klassen oder Interfaces entwickelst ist für DI erstmal völlig egal. Auch Klassen haben ein "Interface" und können somit von außen verändert und erweitert - und als "Contract" verwendet werden. Wenn du sehr fokussierte Interfaces verwendest sind deine Abhängigkeiten aber auf ganz spezifische Funktionalitäten reduziert.
    [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

    Kommentar


    • #3
      Hallo,

      kurz gesagt ja. Wenn Du Klassen, Interface & Co. mit wenig Abhängigkeiten haben willst, dann ist Dependency Injection der beste Weg das übersichtlich zu halten. Vorallem ist es dann auch leicht mal eine Abhängigkeit zu entfernen, anstatt von an tausend Code stellen suchen.


      MFG

      derwunner

      Kommentar


      • #4
        Gibt es einen Grundsatz welche Art man möglichst nutzen sollte?

        Constructor Injection, Setter Injection oder Interface Injection?

        oder ist dies immer von etwas bestimmten abhängig? oder sogar völlig egal?

        Kommentar


        • #5
          Zitat von yugox Beitrag anzeigen
          Gibt es einen Grundsatz welche Art man möglichst nutzen sollte? Constructor Injection, Setter Injection oder Interface Injection?
          Constructor- & Setter-Injection sind zwei Varianten wie du deine Abhängigkeiten beziehen kannst. Bei der Constructor-Injection hast du den Vorteil, dass das Objekt ohne die Abhängigkeit gar nicht erzeugt werden kann. Bei der Setter-Injection kann es passieren, dass dein Objekt sich in einem "ungültigen" Zustand befindet und Methoden auf Abhängigkeiten zugreifen wollen, die noch gar nicht injiziert wurden.

          Mit "Interface Injection" meinst du vermutlich die Kopplung an Interfaces. An sich ist es immer schöner mit Interfaces zu arbeiten, aber wenn du in deiner Anwendung eine Klasse hast du die niemals nie tauschen wirst, dann kannst du auch die konkrete Klasse als Abhängigkeit verwenden. Over-Engineering bringt letztlich auch nix

          Zitat von yugox Beitrag anzeigen
          oder ist dies immer von etwas bestimmten abhängig? oder sogar völlig egal?
          Es gibt da keine Patentlösung, aber Vor- und Nachteile die es abzuwägen gilt. Letztlich hängt es auch vom Anwendungsfall ab. Nutze das was für dich am meisten Sinn ergibt.
          [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

          Kommentar


          • #6
            Das mit dem Interface hatte ich von hier:
            https://de.wikibooks.org/wiki/Websit...ency_Injection

            Dadurch das die Abhängigkeiten durch das Interface Injection scheinbar am Besten gelöst wäre, dachte ich, dass es am meisten Sinn machen würde möglichst auch auf Interface Injection zu setzen.
            Deine Argumente bei der Constructor-Injection macht natürlich sinn und mit der Setter Injection sehe ich die größten Probleme durch das Risiko mit dem "ungültigen" Zustand.

            Kommentar


            • #7
              Zitat von yugox Beitrag anzeigen
              Dadurch das die Abhängigkeiten durch das Interface Injection scheinbar am Besten gelöst wäre, dachte ich, dass es am meisten Sinn machen würde möglichst auch auf Interface Injection zu setzen.
              Die Verwendung von Interfaces macht es einfacher Implementierungen auszutauschen und ermöglicht es Abhängigkeiten bezogen auf die Funktionalität auf das Wesentliche zu reduzieren. Statt deine Klasse an eine konkrete Logger-Implementierung zu binden (welche u.U. 20 Methoden hat wovon deine Klasse nur eine braucht), kannst du über ein Interface ganz klar festlegen, dass du lediglich eine Komponente brauchst die eine "log"-Methode implementiert.
              [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

              Kommentar


              • #8
                Die Verwendung von Interfaces macht es einfacher Implementierungen auszutauschen und ermöglicht es Abhängigkeiten bezogen auf die Funktionalität auf das Wesentliche zu reduzieren. Statt deine Klasse an eine konkrete Logger-Implementierung zu binden (welche u.U. 20 Methoden hat wovon deine Klasse nur eine braucht), kannst du über ein Interface ganz klar festlegen, dass du lediglich eine Komponente brauchst die eine "log"-Methode implementiert.
                Genau deswegen dachte ich mir auch zuerst das diese Art von Injection evtl. am sinnvollsten wäre und ich möglichst die verwenden sollte.

                Kommentar


                • #9
                  Konstruktor Injection ist der Standard, wenn du Symfony Services hast. Geht natürlich auch über getter/setter, ist aber wie bereits beschrieben fehlanfälliger. Kann aber durchaus nützlicher sein, wenn du eine Abhängigkeit erst zu einem späterem Verarbeitungszeitpunkt setzen kannst.

                  Beispiel: Du möchtest loggen und hälst dich dabei an den PSR Standard. Wenn du nun Monolog in dein Projekt einbindest, dann definiere nicht die Monolog Logger Klasse als Abhängigkeit, sondern nimm das PsrLoggerInterface. Hintergrund: Austauschbarkeit und Erweiterbarkeit.

                  Kommentar


                  • #10
                    Zitat von derwunner Beitrag anzeigen
                    Konstruktor Injection ist der Standard, wenn du Symfony Services hast. Geht natürlich auch über getter/setter, ist aber wie bereits beschrieben fehlanfälliger. Kann aber durchaus nützlicher sein, wenn du eine Abhängigkeit erst zu einem späterem Verarbeitungszeitpunkt setzen kannst.

                    Beispiel: Du möchtest loggen und hälst dich dabei an den PSR Standard. Wenn du nun Monolog in dein Projekt einbindest, dann definiere nicht die Monolog Logger Klasse als Abhängigkeit, sondern nimm das PsrLoggerInterface. Hintergrund: Austauschbarkeit und Erweiterbarkeit.
                    Das Beispiel wäre dann aber Interface Injection, was sich sowohl als Konstruktor als auch Setter Injection realisieren lässt.
                    "Software is like Sex, it's best if it's free." - Linus Torvalds

                    Kommentar


                    • #11
                      Ich bin auch ein Gegner von Setter-Injection aus dem oben genannten Problem: Das Objekt kann einen undefinierten Zustand einnehmen. Außerdem:
                      * Man muss Setter definieren, die man sonst wahrscheinlich nicht bräuchte.
                      * Wenn eine Abhängigkeit erst zu einem späteren Zeitpunkt verfügbar ist, kann man auch Lazy-Loading-Mechanismen verwenden.

                      Kommentar

                      Lädt...
                      X