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

  • #46
    Das mit der Bezeichnung sollte ja auch keine Kritik an deinem Ansatz sein, man muss halt so wie es aktuell ist immer aufpassen, bei welchem Container jetzt welche Nomenklatur gilt.

    Und zum "Key". Die Lösung über das Interface zu gehen un bei mehrfachem Vorkommen zusätzlich einen Namen zu vergeben favorisiere ich ja auch.

    Kommentar


    • #47
      ich habe weiter intensiv an dem DiC gearbeitet,

      er hat nun eine code coverage von 100% und ist dokumentiert:
      http://anydi.ainfach.de

      Feedback natürlich erwünscht, besonders wenn es konstruktiv + negativ ist

      Kommentar


      • #48
        Ich verstehe nicht, wozu das Dekorieren gut ist. Kannst Du das vielleicht mal anhand eines Bsp. erklären?

        Kommentar


        • #49
          stell dir du ermöglichst deinen plugins das ändern von implementationen.


          so könnte z.b. ein die klasse für das rechtemanagement ersetzen um z.b. andere Kriterien für die isAdmin Funktion hinzuzufügen. Die Klasse könnte von der ehemaligen Klasse erben.

          soweit alles wunderbar.

          was passiert aber nun, wenn du 2 Plugins hast welche beide die isAdmin Funktion beeinflussen wollen? Die Plugins überschreiben sich gegenseitig.

          new PLUGIN2_rechtemanagement(new PLUGIN1_rechtemanagement(new rechtemanagement()))

          löst das Problem. wichtig ist nur das alle das selbe Interface implementieren.

          Fazit:
          das decorieren erlaubt dir Klassen beliebig oft zu modifizieren.

          Ein weiteres Beispiel findest du hier:
          http://prezi.com/zijnwebmohfx/dependency-injection/
          etwa bei Folie ~25

          Kommentar


          • #50
            Ich habe mir den Code jetzt gerade nicht angeschaut - Wie löst Du das? Werden die "Decorators" iterativ durchlaufen?

            Und wie bindest Du Bibliotheken ein, bei denen Du kein Interface setzen kannst, wie z. B. Zend_Mail?

            Kommentar


            • #51
              Zitat von xm22 Beitrag anzeigen
              Ich habe mir den Code jetzt gerade nicht angeschaut - Wie löst Du das? Werden die "Decorators" iterativ durchlaufen?
              ja genau, jede klasse die als decorator fungiert bekommt als ersten parameter im konstruktor die letzte instanz.

              Zitat von xm22 Beitrag anzeigen
              Und wie bindest Du Bibliotheken ein, bei denen Du kein Interface setzen kannst, wie z. B. Zend_Mail?
              Sehr gute Frage, ich habe lange darüber nachgedacht und bin zu dem Schluss gekommen das es keinen Sinn macht Sachen austauschbar zu halten wenn dieses nicht durch ein Vertrag (Interface) gesichert sind.

              Derzeit gibt es dafür keine sinnvolle Möglichkeit welche mir bekannt ist. Es gibt nur die Möglichkeit eine weiter Klasse hinzuzufügen welche von Zend_Mail erbt und ein Interface implementiert.

              wenn du wolltest wäre es aber kein Problem eine solche Mechanik zu implementieren:

              $di->get('ZF')->getInstance('Zend_Mail')

              der DiC könnte dich lediglich dabei unterstützen den loader f+r das (ZF) zu laden, du wiederum könntest die einfache methode getInstance() schreiben und so andere Klassen laden.

              ich finde die Thematik sehr interessant und werde mich damit wohl nochmal intensiv auseinandersetzen.

              Kommentar


              • #52
                ja genau, jede klasse die als decorator fungiert bekommt als ersten parameter im konstruktor die letzte instanz.
                Ah ok.. Da finde ich halt nur nervig, dass ja konsequenterweise jedes Objekt "decorable" sein müsste oder sehe ich das falsch?

                Ich hätte gedacht, dass Du einen Decorator nur "simulierst", in dem Du z. B. die decorators in einer Liste speicherst und dann durchläufst.

                Kommentar


                • #53
                  welches objekt ist nicht "decorateable"?

                  nur die decoratoren müssen im Konstruktor die Instanz entgegen nehmen können. interessant wirds wenn im interface der konstruktor mit definiert wird.

                  das nächste Release wird etwas anders damit umgehen und diese "Schwachstelle" elegant (versprochen ) beseitigen.

                  Kommentar


                  • #54
                    welches objekt ist nicht "decorateable"?
                    Jedes, das das nicht explizit implementiert.

                    Einen Service, der vielleicht so aussieht:
                    PHP-Code:
                    class Service implements IService {
                        public function 
                    __constructor() {

                        }

                    Kann man für Dein Decoration nicht benutzen.

                    Kommentar


                    • #55
                      PHP-Code:
                      class Service implements IService {
                          public function 
                      __constructor() {

                          }


                      PHP-Code:
                      class DECORATED_Service implements IService {
                          public function 
                      __constructor($parent) {

                          }

                      ???

                      Kommentar


                      • #56
                        Ich hätte gedacht, dass Du einen Decorator nur "simulierst", in dem Du z. B. die decorators in einer Liste speicherst und dann durchläufst.
                        So hat man zusätzlich die Möglichkeit die Ausgabe komplett zu unterbrechen, man muss nicht mit dem Parent arbeiten kann es aber tun.

                        bitte verwechsel das nicht mit hooks.

                        Kommentar


                        • #57
                          Zu #55: Das meinte ich ja - Die Klasse muss das auch unterstützen. Das ist zwar Prinzip-bedingt, aber ich finde es nicht so praktisch, da man seine Services alle darauf trimmen muss, dass sie das Decoration unterstützen. Das bedeutet, wenn man das Decoration benutzen will, _muss_ man diese Funktionalität in all seine Services einbauen, was ich persönlich unpraktisch finde, da ich mich i. d. R. bei Services auf deren eigentliche Funktion konzentrieren will.
                          bitte verwechsel das nicht mit hooks.
                          Tu ich nicht.

                          EDIT: Ich halte das mit dem Dekorieren auch insofern für kritisch, als dass ja jede Ebene der Dekoration Einfluss auf Rückgabewerte nehmen kann.. Da kann Plugin 1 auf Rückgabewert x hoffen, was aber nie eintritt, weil Plugin 2 nur Rückgabewert y zulässt..

                          Kommentar


                          • #58
                            Zitat von xm22 Beitrag anzeigen
                            Zu #55: Das meinte ich ja - Die Klasse muss das auch unterstützen. Das ist zwar Prinzip-bedingt, aber ich finde es nicht so praktisch, da man seine Services alle darauf trimmen muss, dass sie das Decoration unterstützen.
                            aber wo? nur der decorator dieser klasse muss das unterstützen, die original implementation keineswegs.

                            Kommentar


                            • #59
                              Zitat von notyyy Beitrag anzeigen
                              PHP-Code:
                              class DECORATED_Service implements IService {
                                  public function 
                              __constructor($parent) {

                                  }

                              ???
                              PHP-Code:
                              class DECORATED_Service implements IService {
                                  public function 
                              __constructor(IService $parent) {

                                  }

                              --

                              „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                              Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                              --

                              Kommentar


                              • #60
                                nur der decorator dieser klasse muss das unterstützen,
                                Dann habe ich das vielleicht falsch verstanden. ICh habe das so verstanden, dass Service und Decorator das selbe sind. Angenommen, man hat einen Service, der einen Mailing-Mechanismus bereit stellt, dann muss der doch trotzdem Decoration unterstützen.

                                Wie will man hier dekorieren:
                                PHP-Code:
                                class MailService implements IMailService {
                                    public function 
                                __Construct() {
                                        
                                //...
                                    
                                }

                                Dafür bräuchte man schon das hier:
                                PHP-Code:
                                class MailService implements IMailService {
                                    public function 
                                __Construct(IMailService $mailService) {
                                        
                                //...
                                    
                                }

                                Ein weiteres Problem, das ich da in Bezug auf das Dekorieren am Bsp. des Mailing-Services sehe: Jeder MEthoden-Aufruf wird ja durch jeden Decorator durchgereicht. Dann würde das doch hier bedeuten, dass jeder Decorator bis zur letzen Instanz eine eigene Mail versendet, oder?

                                Kommentar

                                Lädt...
                                X