Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Factory Pattern Einsatz

Einklappen

Neue Werbung 2019

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

  • [Erledigt] Factory Pattern Einsatz

    Hallo allerseits. Eine kleine Frage bzgl. dem Factory Pattern. Lohnt es sich egtl, dieses bei kleineren Dingen, wie einer Datebankverbindung zu gebrauchen. Habe mir das so vorgestellt, dass ich eine "Standardklasse" für eine Datebank schreibe und diese für verschiedene Datenbanken in einer Factory gebrauche. Also Datenbank A hat Verbindung x,y,z, kann mit Befehl abc direkt aufgerufen werden, Datenbank B hat,... . Vorteile sind somit, dass ich die Instanzen lokal halte und nicht jedes Mal neu erzeugen und nach außen geben muss und das ganze Unit-Test freundlicher ist. Ist das mit Kanonen auf Spatzen geschossen, oder ist dieses Vorhaben eurer Meinung nach berechtigt?


  • #2
    Eine Factory bietet sich dazu an, die Instanzen selbst würde ich aber in Adaptern vorhalten und diese Adapter mit einer Factory erzeugen.

    Ein Adapter könnte so aussehen: https://gist.github.com/Golpha/8446061
    [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


    • #3
      Vorteile sind somit, dass ich die Instanzen lokal halte und nicht jedes Mal neu erzeugen und nach außen geben muss
      Das ist mit Sicherheit nicht das Wesen des F-Patterns.
      und das ganze Unit-Test freundlicher ist.
      Sehe ich hier auch nicht.
      --

      „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


      • #4
        @Tr0y: Genau das was ich gesucht habe. Nur wie siehts lizenzmäßig aus mit dem Ding?

        Das ist mit Sicherheit nicht das Wesen des F-Patterns.
        schrieb Nikosch auf Grundlage meiner Aussage
        [...]und nicht jedes Mal neu erzeugen und nach außen geben muss
        Das ist mit Sicherheit schon das Wesen des F-Patterns. Eine Factory dient dazu gleichnamige Objekte zu verwalten und nur via Methodenaufruf zu erzeugen. Wikipedia schreibt z.B.
        Das ist insbesondere wertvoll, wenn Frameworks sich während der Lebenszeit einer Applikation weiterentwickeln – so können zu einem späteren Zeitpunkt Instanzen anderer Klassen erzeugt werden, ohne dass sich die Applikation ändern muss.
        Genau das habe ich gesagt.

        Kommentar


        • #5
          Hallöchen,

          eine Factory (der Name lässt es vermuten) erzeugt in erster Linie nur Objekte. Nichts weiter. Instanzen vorzuhalten ist dann wiederrum Aufgabe eines DIC (Dependency Injection Container), eines SL (Service Locator) oder einer anderweitigen Konfigurationsschnittstelle.

          Das
          Das ist insbesondere wertvoll, wenn Frameworks sich während der Lebenszeit einer Applikation weiterentwickeln – so können zu einem späteren Zeitpunkt Instanzen anderer Klassen erzeugt werden, ohne dass sich die Applikation ändern muss.
          hat damit
          Vorteile sind somit, dass ich die Instanzen lokal halte und nicht jedes Mal neu erzeugen und nach außen geben muss und das ganze Unit-Test freundlicher ist.
          nichts zu tun.

          Der Vorteil des Factory-Pattern ist, dass die Instanziierung von Objekten ausgelagert wird und somit zentral beeinflusst werden kann.

          Viele Grüße,
          lotti

          Kommentar


          • #6
            Ok, danke lotti. Kleine Frage: Inwiefern unterscheidet sich dann ein Factory-Pattern von einem Builder-Pattern? Weil beide hören sich doch ziemlich stark nach "erzeugen" an.

            Kommentar


            • #7
              Zitat von Phpyton Beitrag anzeigen
              Ok, danke lotti. Kleine Frage: Inwiefern unterscheidet sich dann ein Factory-Pattern von einem Builder-Pattern? Weil beide hören sich doch ziemlich stark nach "erzeugen" an.
              Google: http://stackoverflow.com/questions/7...design-pattern

              Kommentar


              • #8
                Zitat von Phpyton Beitrag anzeigen
                Ok, danke lotti. Kleine Frage: Inwiefern unterscheidet sich dann ein Factory-Pattern von einem Builder-Pattern? Weil beide hören sich doch ziemlich stark nach "erzeugen" an.
                laut http://de.wikipedia.org/wiki/Erbauer...wurfsmuster%29 ist ein Builder nichts anderes als Factory mit dem Unterschied dass er die Instanzen mit Hilfe von Konfigurationsdateien aufbaut.

                Generell vergiss alle Pattern.

                http://blog.ircmaxell.com/2013/09/be...-patterns.html

                Pattern sind eine Kommunikationsschnittstelle zwischen Entwicklern, eine Art UML
                apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp | Mein Youtube PHP Kanal: https://www.youtube.com/c/VitalijMik

                Kommentar


                • #9
                  Nein nicht wirklich, erzeugen ist hier im Sinne einer Objektinstanz gemeint.

                  Beim Builder passiert vor dem erzeugen noch eine ganze Menge.
                  Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
                  http://www.lit-web.de

                  Kommentar


                  • #10
                    Generell vergiss alle Pattern.
                    Eine ähnliche Diskussion entflammte schon mal unter unseren Entwicklenr. Dem Kunden ist generell "egal", wie der Code aufgebaut ist, solange die Wartung auch vom Entwickler übernommen wird und der Code tut was er tun soll. Da kann man auch prozedural Funktionen herunterhacken. Aber ich finde auch, dass manche Patterns einen gewissen Overhead erzeugen, oder z.B. erst gar nicht für einen produktiven Einsatz geeignet sind, z.B. Antipattern wie Singleton. Ansonsten spreche ich aus eigener Erfahrung, dass ich dennoch nicht auf den Einsatz von Patterns verzichten möchte.

                    Kommentar


                    • #11
                      Zitat von Phpyton Beitrag anzeigen
                      Eine ähnliche Diskussion entflammte schon mal unter unseren Entwicklenr. Dem Kunden ist generell "egal", wie der Code aufgebaut ist, solange die Wartung auch vom Entwickler übernommen wird und der Code tut was er tun soll. Da kann man auch prozedural Funktionen herunterhacken. Aber ich finde auch, dass manche Patterns einen gewissen Overhead erzeugen, oder z.B. erst gar nicht für einen produktiven Einsatz geeignet sind, z.B. Antipattern wie Singleton. Ansonsten spreche ich aus eigener Erfahrung, dass ich dennoch nicht auf den Einsatz von Patterns verzichten möchte.

                      nein du hast den Blog nicht gelesen und mich falsch interpretiert, OOP ist ein MUSS und Pattern kommen von deiner Architektur. Du gehst aktuell den Falschen weg, ala

                      "Hey da ist ein Pattern der mein Problem xyz loesen soll, dann werde ich irgendwie irgendwelche "Basisklassen" umbiegen und irgendwie ableiten und irgendwie das ganze interpretieren" und am Ende wird es nicht einmal klar ob es nun Factory oder Builder ist weil viele dinge magisch in den "Basisklassen" passieren.

                      Mit "vergiss die Pattern" meinte ich, dass du dich auf die Architektur konznetrieren musst, real wirste vielleicht eine Handvoll pattern im gesamten Projekt benutzen.

                      Wie gesagt, die dinge sind eher fuer diskussionen zwischen Entwicklern gut geeignet aber nicht deinen Code auf die besagten pattern umzubiegen.

                      Pattern sind wichtig, und es sind nur Muster.

                      EDIT: dem Kunden ist es auch egal welcher Code sich dahinter verbirgt, wichtig ist die Pflege und Erweiterung und Stabilitaet, diese dinge sind dem Kunden nicht egal, auch workflow der Mitarbeiter ersprart einiges an Geld und Nerven was dem Kunden auch dann nicht mehr egal ist
                      apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp | Mein Youtube PHP Kanal: https://www.youtube.com/c/VitalijMik

                      Kommentar


                      • #12
                        Vllt noch eine Frage, deren Antwort mich brennend interessieren würde: Wenn ich eine Factory nutze, gibt es dann einen Weg iwie sicherzustellen, dass man somit nur die Factory nutzt und nicht die Basisklasse, auf die zugegriffen wird

                        Kommentar


                        • #13
                          Zitat von Phpyton Beitrag anzeigen
                          Vllt noch eine Frage, deren Antwort mich brennend interessieren würde: Wenn ich eine Factory nutze, gibt es dann einen Weg iwie sicherzustellen, dass man somit nur die Factory nutzt und nicht die Basisklasse, auf die zugegriffen wird
                          fuer Datenbanken, nutze ich den simplen Repository pattern, factory pattern sollte man dann beim erzeugen der realen objekte benutzen, nicht fuer die datenbank verbindung.

                          das ist zb mein Repository

                          https://github.com/Opentribes/Core/b...ALUser.php#L46

                          und in der create Methode sollte da eigentlich eine Factory rein(ich war zu faul eine einzubauen)

                          ueber den Konstruktor uebergibst du dem Repository eine Datenbank verbindung, diese erstellst du an einer zentralen stelle, zb eine instanz von PDO.

                          Du hast den Vorteil bei dem Repository Pattern, dass du Datenquellen austauschen , kombinieren und mocken kannst.(Vorausgesetzt du arbeitest mit Interfaces und nicht basis klassen)

                          Als Datenquelle kann FileStorage,Datenbank oder eine API angesehen werden. Und durch die Mocks kannst du es dann tatsaechlich schneller unittesten.

                          Ich habe mich noch nicht ein Mocking Frameworks eingearbeitet, aber wie du hier sehen kannst https://github.com/Opentribes/Core/b...itory/User.php werden die User einfach in ein PHP Array gepackt, Tests laufen durch , pruefen ob richtige Objekte drin sind und fertig. Wenn ich es dann mit einer Datenbank testen will, KANN ich es machen, MUSS aber nicht
                          apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp | Mein Youtube PHP Kanal: https://www.youtube.com/c/VitalijMik

                          Kommentar


                          • #14
                            Warum willst du es verhindern? Wenn eine Klasse der Meinung ist, das Objekt selbst erstellen zu müssen, welchen guten Grund solltest du haben, das verhindern zu wollen?
                            Lerne Grundlagen | Schreibe gute Beispiele | PDO > mysqli > mysql | Versuch nicht, das Rad neu zu erfinden | Warum $foo[bar] böse ist | SQL Injections | Hashes sind keine Verschlüsselungen! | Dein E-Mail Regex ist falsch

                            Kommentar


                            • #15
                              Ich habe einen Grund. Bitte keine Disku starten. Geht das iwie oder nicht?

                              Kommentar

                              Lädt...
                              X