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

  • #61
    Zitat von nikosch Beitrag anzeigen
    möchtest du mich auf etwas hinweisen?

    der service selber muss dies nicht unterstützen warum auch?
    wenn man den service decorieren will, dann muss der "DECORATED_service" dies unterstützen.
    Es gibt eine Ausnahme, welche aber im nächsten release nicht mehr existiert. so dard das interface des services nicht den konstruktor implementieren da dieser sich ja bei dem DECORATED_service unterscheidet.

    PHP-Code:
    new DECORATED_service(new Service()) 
    nur der decorator bekommt die instanz des services.


    Jeder MEthoden-Aufruf wird ja durch jeden Decorator durchgereicht.
    1. du bsit nicht gewunden die $parent->__FUNCTION__ aufzurufen, ein solcher decorator kann also auch "unterbrechen"

    2. ein decorator ist nicht dafür da services zu ersetzen sondern zu erweitern, willst du ein service ersetzen überschreib einfach das binding:

    http://anydi.ainfach.de/configuration-files

    Kommentar


    • #62
      Zitat von notyyy Beitrag anzeigen
      möchtest du mich auf etwas hinweisen?
      nikosch hat deinen Konstruktor um die Typangabe IService erweitert

      Und ich korrigiere den Methodennamen

      PHP-Code:
      public function __construct(IService $parent) { 
      [I]Es ist schon alles gesagt! Nur noch nicht von allen! (Karl Valentin)[/I]
      [I]Wenn du eine weise Antwort verlangst, musst du vernünftig fragen. (Johann Wolfgang von Goethe)[/I]

      Kommentar


      • #63
        wunderbar - nun verständlich?

        Kommentar


        • #64
          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).
          [COLOR="#F5F5FF"]--[/COLOR]
          [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
          „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
          [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
          [COLOR="#F5F5FF"]
          --[/COLOR]

          Kommentar


          • #65
            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!

            Kommentar


            • #66
              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..

              Kommentar


              • #67
                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.

                Kommentar


                • #68
                  Ah ok - Jetzt habe ich es verstanden.

                  Kommentar


                  • #69
                    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.
                    [COLOR="#F5F5FF"]--[/COLOR]
                    [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                    [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                    [COLOR="#F5F5FF"]
                    --[/COLOR]

                    Kommentar


                    • #70
                      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?

                      Kommentar


                      • #71
                        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.

                        Kommentar


                        • #72
                          Ist der Code eigentlich irgendwo verfügbar von dir @notyyy ?

                          Kommentar


                          • #73
                            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

                            Kommentar


                            • #74
                              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

                              Kommentar


                              • #75
                                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 !!!

                                Kommentar

                                Lädt...
                                X