Ankündigung

Einklappen
Keine Ankündigung bisher.

Strategie mit Factory

Einklappen

Neue Werbung 2019

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

  • Strategie mit Factory

    Guten Tag,

    ich bin gerade an dem Punkt, an dem ich zweifle, ob ich das Strategie Pattern in Zusammenhang mit einer Factory, die mir die eigentlichen Objekte erzeugt, einsetzen soll. Was mich daran stört ist, dass man zur Erzeugung zwei Klassen benötigt, und eine Entfernung, oder Hinzufügung einer Strategie, beide Klassen beeinflussen würde. Wie steht ihr dazu; denn ich finde, dass würde den Prinzipien, wonach eine Klasse nur aus einem einzigen Grund geändert werden soll, wiedersprechen. Sollte ich mich unklar ausgedrückt haben, reiche ich Codebeispiele gerne nach.


  • #2
    mir wäre ein konkretes Beispiel lieb
    https://github.com/Ma27
    Javascript Logic is funny:
    [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

    Kommentar


    • #3
      Ok, schnell aus dem Ärmel geschüttelt. Sie dir das an:http://sourcemaking.com/design_patterns/Strategy/php
      Wenn ich so z.B. eine neue Strategie hinzufüge, muss ich die Factory genauso mitverändern, was meiner Meinung nach bad style ist.
      Und stellen wir uns vor, dass die Factory in einer anderen Klasse weiterverarbeitet wird, dann entstehen noch mehr Abhängigkeiten, die entsprechend bei Änderungen betroffen sind.

      Kommentar


      • #4
        Villeicht steh ich gerade auf dem Schlauch, aber wieso möchtest du überhaupt beide Pattern gleichzeitig nutzen? Und wie schaut dein spezifischer Fall aus?
        Gruß,
        SebTM

        Kommentar


        • #5
          Zumal für mich interessant ist, warum dein Fall ein Strategiemuster erforderlich macht.
          Standards - Best Practices - AwesomePHP - Guideline für WebApps

          Kommentar


          • #6
            Zumal für mich interessant ist, warum dein Fall ein Strategiemuster erforderlich macht.
            Distanzieren wir uns von meinem Fall. Ich will die Diskussion abstrakter halten. Du hast mein Beispiel gesehen, und anhand dessen will ich diskutieren, ob die enge Kopplung gerechtfertigt ist, oder gegen generelle Prinzipien verstößt.

            Kommentar


            • #7
              Naja, ich kann aus Erfahrung sagen, dass man das Strategiemuster nur sehr selten antrifft. Und in 50% dieser Fälle wäre eine andere Lösung eleganter.

              Wenn du das Thema abstrakt halten willst: Wenn das Strategiemuster die Erzeugung der jeweiligen Strategie übernimmt (und nicht mehr), dann tut sie ja genau eine Sache und es gibt keinen weiteren Grund diese Klasse zu ändern.
              Standards - Best Practices - AwesomePHP - Guideline für WebApps

              Kommentar


              • #8
                Wenn ich eine Strategie entferne, muss ich ebenso diese Klasse ändern, und genauso alle anderen, die diese Strategie implementieren. Verstehst du was ich meine?

                Kommentar


                • #9
                  Zitat von Phpyton Beitrag anzeigen
                  ... und genauso alle anderen, die diese Strategie implementieren. Verstehst du was ich meine?
                  Wenn du es richtig machst, eben nicht. Oder kannst du mir kurz beschrieben warum du glaubst, dass du das musst?
                  Standards - Best Practices - AwesomePHP - Guideline für WebApps

                  Kommentar


                  • #10
                    Auszug aus Fachliteratur:
                    Der Client setzt die passende Strategie des Contexts und muss folglich die Implementierungen kennen. Diese enge Kopplung des Clients an die konkreten Strategien ist nachteilig.
                    Willst du mehr?

                    Kommentar


                    • #11
                      Diese Aussage kann ich so nicht nachvollziehen. In dem oben verlinkten Beispiel finde ich gut nachvollziehbar erklärt, dass du ein Objekt des immer gleichen Interface auf Grund einer gegebenen Anfrage ("Strategie") zurückbekommst. Das Strategiemuster ist eben eine Fabrik, die unterschiedliche Implementationen -referenziert durch eine Strategie- erzeugt. Der Client (also in diesem Fall der Anfragesteller) kennt nur das Interface, nicht aber die Implementation.
                      Standards - Best Practices - AwesomePHP - Guideline für WebApps

                      Kommentar


                      • #12
                        Ich würde auf das Pattern komplett verzichten. Stelle dir die einfache Situaion vor: Wir haben einen Taschenrechner. Dieser kann +, -, *, /. Dies kannst du entweder ganz normal in Methoden fassen, oder einen riesigen Umweg mit Strategie gehen und dann sagen, du hast ein Pattern angewandt. Ich persönlich kenne so gut wie keinen Fall, in dem ein Strategie-Pattern sinnvoll wäre. Das ist für mich zu viel (sinnloser) overhead. Aber lasse mich gerne eines besseren belehren, falls jemand was dazu sagen will.

                        Kommentar


                        • #13
                          Also diese Erklärung ist mir jetzt etwas zu plump und pauschal auf etwas zu verzichten halte ich auch nicht für sinnvoll.
                          Für deinen Taschenrechner wäre der Einsatz des Patterns wohl auch ein sehr gekünsteltes Beispiel, aber man könnte z.B. verschiedene Implementierungen haben, etwa einen Taschenrechner der nur binäre Werte zurückgibt, ein anderer gibt hexadezimal zurück.(Beispiel inspiriert durch http://sourcemaking.com/design_patterns/Strategy/php)
                          In so einer Situation könnte ich mir den Einsatz schon eher vorstellen, muss aber gestehen, dass ich mit dem bewussten Einsatz von Pattern eher wenig Erfahrung habe.
                          Relax, you're doing fine.
                          RTFM | php.de Wissenssammlung | Datenbankindizes | Dateien in der DB?

                          Kommentar


                          • #14
                            Zitat von hartCoder Beitrag anzeigen
                            Ich würde auf das Pattern komplett verzichten. Stelle dir die einfache Situaion vor: Wir haben einen Taschenrechner. Dieser kann +, -, *, /. Dies kannst du entweder ganz normal in Methoden fassen, oder einen riesigen Umweg mit Strategie gehen und dann sagen, du hast ein Pattern angewandt. Ich persönlich kenne so gut wie keinen Fall, in dem ein Strategie-Pattern sinnvoll wäre. Das ist für mich zu viel (sinnloser) overhead. Aber lasse mich gerne eines besseren belehren, falls jemand was dazu sagen will.
                            Environment-sensitive Entwicklung ist einer solcher Fälle.

                            Das Strategy Pattern ist nur dann sinnvoll wenn du Factories baust die ihren Erzeuger- oder Konfigurationsmechanismus austauschbar gestalten wollen.
                            [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                            Kommentar


                            • #15
                              Ok, hast du ein kurzes Code-Beispiel?

                              Kommentar

                              Lädt...
                              X