Ankündigung

Einklappen
Keine Ankündigung bisher.

Singletons in IoC

Einklappen

Neue Werbung 2019

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

  • Singletons in IoC

    Ahoi,

    ich hab mir gerade mal verschiedene IoC implementierungen in PHP (bitexpert/disco) und C# (Ninject) angeschaut. Alle bieten die Möglichkeit eine Klasseninstanz am Ende als Singleton zu nutzen.

    In Disco z.B: über Annotation

    PHP-Code:
       /**
        * @Bean({"singleton"=true})
        */
       
    public function xyz() : SomeObject
       
    {
          return new 
    SomeObject();
       } 
    In C# ist es eine Methode asSingleTon()

    Aber das kann doch eigentlich nur falsch sein oder?

    Nach meinem Verständnis muss das was ein Singleton ausmacht bereits von der Klasse, die als Singleton nutzbar sein soll, definiert werden und nicht von irgendwelchen anderem Code.

    Nach z.B. GoF (Gang of Four)) ist ein Singleton so zu definieren, das sichergestellt ist das es davon scope unabhängig immer nur eine einzige Instanz geben kann.
    Das ist ja bereits dadurch nicht erfüllt weil eine neue Instanz der zurück gegebenen Klasse beliebig oft abseits des IoC initialisiert werden kann.

    Mir geht es da eigentlich nur um die Benamsung weil ich das irritierend finde.

    Singleton ist in der Informatik ja eigentlich ein Muster mit fest definierten Verhalten.

    Haltet Ihr das für korrekt/richtig das diese Bezeichnung dafür missbraucht wird?

    Oder liegt es einfach nur an schrägen Denken meinerseits und das alles ist eigentlich OK?

  • #2
    Hast du mal nachgeschaut, was die Annotation bewirkt? Ich vermute mal, dass sie die Instanz, wenn einmal erstellt, aus einem Container zieht. Aber ich kenne das von dir beschriebende projekt "Disco überhaupt nicht.

    edit// Ok Frage falsch gelesen. Ignorier die Antwort.

    Kommentar


    • #3
      Die Bezeichnung "Singleton" ist m.M.n. in diesem Fall zweckdienlich, da diese im Kontext betrachtet werden muss. Die meisten IoC Container unterstützen sowohl Prototypen als auch Singletons Scopes. Das Spring-Framework unterstützt darüber hinaus auch Request-, Session- und Application-Singletons. Innerhalb eines bestimmten Kontextes kann ein Service mit einem definierten Alias als Singleton nur einmal existieren und das unabhängig von der Implementierung.

      Selbstverständlich kann eine andere Instanz derselben Klasse einer anderen ID beziehungsweise einem anderen Alias zugeordnet sein. In diesem Sinne können zwei unterschiedliche Instanzen derselben Klasse dem IoC Container bekannt sein, obwohl eine als Singleton deklariert wurde.

      Kommentar


      • #4
        Zitat von Anyone Beitrag anzeigen
        Die Bezeichnung "Singleton" ist m.M.n. in diesem Fall zweckdienlich, da diese im Kontext betrachtet werden muss. Die meisten IoC Container unterstützen sowohl Prototypen als auch Singletons Scopes. Das Spring-Framework unterstützt darüber hinaus auch Request-, Session- und Application-Singletons. Innerhalb eines bestimmten Kontextes kann ein Service mit einem definierten Alias als Singleton nur einmal existieren und das unabhängig von der Implementierung.

        Selbstverständlich kann eine andere Instanz derselben Klasse einer anderen ID beziehungsweise einem anderen Alias zugeordnet sein. In diesem Sinne können zwei unterschiedliche Instanzen derselben Klasse dem IoC Container bekannt sein, obwohl eine als Singleton deklariert wurde.
        Danke, wieder was gelernt

        Ein bisschen Lektüre dazu, weil der Autor von IoC gesprochen hatte und ich die Abkürzung nicht kannte: https://de.wikipedia.org/wiki/Inversion_of_Control Kommt wohl, wie auch sein Anliegen aus dem Java Bereich.

        Interessante Container Bibliothek dieses bitExpert/disco: https://github.com/bitExpert/disco Ist jedoch nicht PHP 5 kompatibel. Was mich wohl noch längere Zeit von der Benutzung dieser Bibliothek abhalten wird. Außerdem, was mich dazu auch mal interessieren würde: Benutzt jemand von euch heute schon diese Bibliothek? Und falls ja, was hat euch dazu bewegt, das anstatt dem Symfony Container zu verwenden?

        Kommentar


        • #5
          Zitat von derwunner Beitrag anzeigen
          Außerdem, was mich dazu auch mal interessieren würde: Benutzt jemand von euch heute schon diese Bibliothek?
          Nö. Ich nutze bis dato php-di.

          Zitat von derwunner Beitrag anzeigen
          Und falls ja, was hat euch dazu bewegt, das anstatt dem Symfony Container zu verwenden?
          Der Symfony Container ist ja nicht die einzige Alternative. Vergleichen müsste man vielmehr Service Locator vs Dependency Injection. Für mich einer der Hauptgründe: Autowiring.
          [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

          Kommentar


          • #6
            Zitat von lottikarotti Beitrag anzeigen
            Der Symfony Container ist ja nicht die einzige Alternative. Vergleichen müsste man vielmehr Service Locator vs Dependency Injection. Für mich einer der Hauptgründe: Autowiring.
            Es ist doch nicht die Frage ob Dependency Injection oder ob Service Locater. Das kann man so gar nicht vergleichen, denn: Das Container Pattern als Software Design Pattern definiert nur, dass darin Service liegen. Wie die letztendlich eingebunden bzw. geladen werden ist für das Design Pattern erstmal nicht relevant. Das ist in den meisten Fällen Dependency Injection, muss aber nicht sein, man könnte die Services auch anders laden. Also von daher ergibt die Frage keinen Sinn. Das ist als würde man Äpfel mit Birnen vergleichen.

            Kommentar


            • #7
              Zitat von Anyone Beitrag anzeigen
              Die Bezeichnung "Singleton" ist m.M.n. in diesem Fall zweckdienlich
              Ich hatte sowas in der Art schon befürchtet Also eine aufgeweichte Begrifflichkeit. Ich sehe das wohl einfach nicht mehr zeitgemäß.

              Zitat von Anyone Beitrag anzeigen
              , da diese im Kontext betrachtet werden muss.
              Warum muss sie das? In der Definition des Singleton Patterns steht das jedenfalls nicht. Zumindest nicht in der der GoF. Ich wäre in dem Fall jedenfalls für eine passendere Namensgebung.

              Zitat von Anyone Beitrag anzeigen
              Die meisten IoC Container unterstützen sowohl Prototypen als auch Singletons Scopes. Das Spring-Framework unterstützt darüber hinaus auch Request-, Session- und Application-Singletons.
              Genau! Also Singleton mit einem Prefix. Z.B.: ScopedSingleton

              Danke für Deine Gedanken!

              Kommentar


              • #8
                Zitat von derwunner Beitrag anzeigen
                Interessante Container Bibliothek dieses bitExpert/disco: https://github.com/bitExpert/disco Ist jedoch nicht PHP 5 kompatibel.
                War für mich das wichtigste Auswahlkriterium das es PHP 7.1 kann bzw. braucht. Da ich mein Libs gerade komlett so überarbeitet habe das diese ebenfalls PHP 7.1 voraussetzen.

                Auf Arbeit kann ich das auch nicht einsetzen da wir dort auch noch leider mit einer 5.6er Version auskommen müssen.

                Zitat von derwunner Beitrag anzeigen
                Außerdem, was mich dazu auch mal interessieren würde: Benutzt jemand von euch heute schon diese Bibliothek?
                Zumindest ich nutze Disco. Dessen Bekanntheitsgrad hält sich noch in Grenzen. Aber dessen Hauptentwickler rürt mächtig die Werbetrommel mit Vorträgen bei z.B. PHP Usergroup Meetups.

                Bei uns in Dresden war der beim vorletzten Meetup (vor 3 Monaten) Da war ich aber leider Krank und konnte nur das aufschnappen was ein Kollege mir dazu erzähl hat. FInde Disco aber klasse.

                Zitat von derwunner Beitrag anzeigen
                Und falls ja, was hat euch dazu bewegt, das anstatt dem Symfony Container zu verwenden?
                Das ist einfach. Um Symfony hab ich schon immer nen großen Bogen gemacht und kenne dessen Module garnicht.

                Kommentar


                • #9
                  Zitat von Messier 1001 Beitrag anzeigen
                  Das ist einfach. Um Symfony hab ich schon immer nen großen Bogen gemacht und kenne dessen Module garnicht.
                  Ok, warum?

                  Kommentar


                  • #10
                    Zitat von derwunner Beitrag anzeigen

                    Es ist doch nicht die Frage ob Dependency Injection oder ob Service Locater. Das kann man so gar nicht vergleichen, denn: Das Container Pattern als Software Design Pattern definiert nur, dass darin Service liegen. Wie die letztendlich eingebunden bzw. geladen werden ist für das Design Pattern erstmal nicht relevant. Das ist in den meisten Fällen Dependency Injection, muss aber nicht sein, man könnte die Services auch anders laden. Also von daher ergibt die Frage keinen Sinn. Das ist als würde man Äpfel mit Birnen vergleichen.
                    Nope. Der Abschnitt "Service Locator vs Dependency Injection" fasst es gut zusammen.
                    [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                    Kommentar


                    • #11
                      Im Endeffekt ist ein IoC Container die konsequente Weiterentwicklung eines Service-Locators. Ein IoC Container kann u.a. einen Service-Locator nutzen, umgekehrt gilt das jedoch nicht. Es sind demnach unterschiedliche Konzepte für unterschiedliche Zwecke. Der Zweck eines Service-Locators ist im groben einen Pool für CRUD-Anfragen für verschiedene Service-Objekte zur Verfügung zu stellen (ähnlich dem Registry-Pattern). Ein IoC Container hingegen ist viel mächtiger und erweitert den Workflow um Konzepte wie Autowiring, Circular Dependency Detection, erweiterte Konfigurierbarkeit, etc. Ein Service-Locator unterstützt kein Hollywood-Prinzip (don't call us, we call you), der IoC Container hingegen schon.

                      Messier 1001
                      Singleton bedeutet übersetzt Einzelstück. Sieht man kurzerhand von dem Singleton-Pattern ab, dann ist die Definition eines Singletons nicht mehr auf die bloße Implementierung beschränkt. Du definierst also anhand von Anforderungen / Geschäftslogik, welche Objekte Einzelstücke sein sollen. Die Anforderung eines IoC Containers ist ein Singleton ein Alias, welcher immer eine Referenz auf dasselbe Objekt besitzt. Also aus der Sicht des Containers heraus ein Einzelstück. Die Anforderung eines Entwicklers kann durchaus sein, dass von einer Klasse nur ein einziges Objekt existieren können muss (Singleton Entwurfsmuster).

                      Beide sind jedoch voneinander unabhängige Anforderungen.

                      Kommentar


                      • #12
                        lottikarotti Ohne mir jetzt komplett den verlinkten Artikel durchzulesen, mein bisheriges Verständnis vom Container Pattern, Dependency Injection und Services was bisher so: Es gibt Dependency Injection, das sagt aus, dass Klassen lose voneinander entkoppelt sind. Dependency Injection sind erstmal einfach nur zwei Klassen mit der jeweils anderen Objektinstanz als Klassenvariable und jeweils Getter und Setter dazu, sowie auch einen überladenen Konstruktor, wenn man das möchte. Das hat erstmal in seiner Definition nichts mit Autoloading zu tun a la Angular 1. DI sagt nur das bisher erwähnte im Entwurfsmuster aus. Autoloading hat sich eingebürgert, sieht das Entwurfsmuster selbst nicht vor. Genauso wenig wie DI mit Autoloading und dem Container Pattern zu koppeln. Was eigentlich Sinn ergibt, aber zwei bis drei völlig unabhängige Patterns erstmal sind.
                        Services sind nichts anderes als Objekte, die im Container liegen (daher auch der Name Container). Und Services werden meistens mittels DI definiert und per DI Autoloading in den Container geladen a la Symfony Services bzw. Symfony Container (services.xml).

                        Kommentar


                        • #13
                          Zitat von derwunner Beitrag anzeigen
                          lottikarotti Ohne mir jetzt komplett den verlinkten Artikel durchzulesen, mein bisheriges Verständnis vom Container Pattern..
                          Dann hol das mal nach
                          [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                          Kommentar


                          • #14
                            Zitat von derwunner Beitrag anzeigen

                            Ok, warum?
                            Inwiefern ist das von Interesse? Aber OK, Du willst es wissen:

                            Das was die als version 1 damals veröffentlicht haben war so grotten schlecht und langsam das ich es nichtmal als v0.0.1 alpha pre veröffentlicht hätte. Sicher wird das besser geworden sein da andere weit verbreitete Libs wie PHPunit auf Teile davon zurück greifen aber wozu jetzt nochmal umschwenken? Es gibt so viele kleine gute Packete bei packagist das ich gar keinen Grund sehe mich da nochmal mit symfony zu beschäftigen. Wenn es irgendwo als Abhängigkeit bei einem zu nutzen Packet mit drin ist ist es halt so aber mehr auch nicht.

                            Kommentar


                            • #15
                              Zitat von Messier 1001 Beitrag anzeigen

                              Inwiefern ist das von Interesse? Aber OK, Du willst es wissen:

                              Das was die als version 1 damals veröffentlicht haben war so grotten schlecht und langsam das ich es nichtmal als v0.0.1 alpha pre veröffentlicht hätte.
                              Kann ich so nicht sagen, eigentlich ganz im Gegenteil: Ich hatte mal ein wirklich großes Projekt unter Symfony 1.4 gesehen. Das lief schon ordentlich schnell, ich hatte jedenfalls keinen Unterschied gemerkt zwischen Plain PHP und Symfony 1.4. Da war eher die langsame Datenbank der Flaschenhals. Zugegeben, für manche Listen waren das auch lange Queries, aber nichts desto trotz kam mir eher MySQL ultra langsam vor. Das warten auf die Query Ergebnisse hatte die meiste Zeit verschluckt, nicht jedoch das Mehr, was ein Framework mit sich bringt. Schließlich gab es auch schon in Version 1 einen Cache, der im prod Environment noch einiges an Optimierungen heraus geholt hatte.

                              Kommentar

                              Lädt...
                              X