[PHP5] Start mit OOP / Frage zu Klassenstruktur

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

  • #31
    Wo wir gerade von abstrakten Singletons sprechen: Da es in PHP keine Mehrfachvererbung gibt, kommt es doch zwangsweise zu Schwierigkeiten, wenn eine abgeleitete Klasse als Singleton implementiert werden soll. Insofern sehe ich den abstrakten Singleton leider als nicht wirklich hilfreich an, lasse mich aber gerne eines Besseren belehren, wenn es dafür mindestens eine adäquate Lösung geben sollte.
    Nieder mit der Camel Case-Konvention

    Kommentar


    • #32
      lasse mich aber gerne eines Besseren belehren,
      Würde ich ja gerne.....
      Aber du hast leider recht.

      Wie gesagt, das Registry und auch das DI Design Pattern ist erheblich universeller. Obwohl, das DI ist in PHP (fast) nur über die Reflection API realisierbar.
      Auch nicht so schön, zumindest nicht für Massen von Objekten geeignet.
      Wir werden alle sterben

      Kommentar


      • #33
        Öhhmm... es wäre übrigens fantastisch, wenn mir noch jemand konkret weiterhelfen könnte...

        Ich wollte eigentlich keine Grundsatzdiskussionen anstoßen, sondern Hilfe.
        Also ich hatte da auf Seite 1 so einen Ansatz, der auch funktionieren würde. Wenn man mal MDB2 außen vor lässt (bitte!), würde man das dann so machen?

        Also eine Klasse stellt (wie auch immer) eine Verbindung zur DB her, und beinhaltet Funktionen, mit der man Abfragen aller Art durchführen kann (z.B. eine Funktion in die man Tabellenname und Feldname reinschmeisst, und die dann ein "Count" durchführt und den Wert zurück gibt).

        In allen anderen Klassen, in denen ich in Kontakt zur DB komme (quasi in allen Klassen), erstelle ich ein Objekt der DB-Klasse und verwende dieses für meine Queries.

        Macht man's so?
        Oder könnte man zumindest? Oder ist das völliger Quatsch?

        Kommentar


        • #34
          Hättest du aufgepasst, dann hättest du u.U. merken können, das wir genau das Thema "Wann welches Objekt wie erzeugen" abgehandelt haben..

          Mein Vorschlag:
          Erzeuge das DB VerbindungsObjekt im (Main/Haupt)Controller und reiche es von da aus im jeweiligen Konstruktor an die benötigten Modelle weiter.
          Falls dir der Begriff "Modell" Sorgen bereitet, dann schau dir mal Google:"ORM doctrine" an. Die haben das recht elegant gelöst.
          Zuletzt geändert von combie; 25.11.2008, 19:08.
          Wir werden alle sterben

          Kommentar


          • #35
            Ich hab durchaus versucht, zu folgen.
            Aber statt "das DI ist in PHP (fast) nur über die Reflection API realisierbar." hättest Du für mich auch schreiben können "Der nächste Zug fährt in 10 Minuten ab Gleis 1".

            Will sagen: ik versteh nur Bahnhof.

            Aber gegoogelt hab ich schon, und ich werde mir das mal anschauen.

            Über die Klonbarkeit von Singletons mache ich mir Gedanken, "wenn es so weit ist". Im Moment sehe ich noch nicht, dass ich eine Klasse überhaupt klonen muss.
            Aber wer weiß... (ich jedenfalls nicht)

            Kommentar


            • #36
              Reflection: http://www.php.net/manual/de/languag...reflection.php
              DI: http://de.wikipedia.org/wiki/Dependency_Injection
              Wir werden alle sterben

              Kommentar


              • #37
                Hey Leute, interessante Diskussion - Singleton vs Registry.

                Also combie brachte die handfestesten Argumente contra Singleton:

                1.) "Die Singleton Eigenschaft einer Klasse ist unter PHP<5.3 nicht vererbbar. Du machst dir damit also große Teile der OOP kaputt."

                2.) Irgendwann brauchst du einen 2ten Druckerport/Datenbankverbindung/Prozessor/Festplatte oder was auch immer.
                Und dann? Die Klasse umbauen?

                Argument 2.) kann ich persönlich nachvollziehen. Ich hatte eine DB-Klasse als Singleton implementiert. Plötzlich brauchte ich in einer Anwendung zwei verschiedene DB-Objekte, dann habe ich die Klasse kurzerhand umgeschrieben, so dass sie mehrere Instanzen zurückliefern kann: DB::getInstance($key = 'default'), also wenn ein neuer key übergeben wurde, wurde auch eine neue Instanz zurückgegeben.
                Jetzt stellt sich mir die Frage, wie löst man soetwas, also wenn man bei Bedarf eine weitere Instanz benötigt? Beim Registry-Pattern müsste ich ja von vornherein zwei Instanzen in die Registry schieben, auch wenn in den meisten Fällen eine Instanz reichen würde? Bzw. erst überprüfen, ob diese Instanz schon existiert und ggf. eine neue anlegen.
                Wäre in diesem Fall meine o.g. Lösung mit mehren Singleton-Instanzen sinnvoller?

                ---

                unset meinte dann noch:

                "Wenn du tatsächlich das manuelle erstellen von Instanzen verhindern willst, wirst du Exceptions werfen, sollte man das versuchen."

                Also eine statische Klassenvariable (Flag), die man im Konstruktor setzt/überprüft? Klingt gut.

                Kommentar


                • #38
                  dann habe ich die Klasse kurzerhand umgeschrieben, so dass sie mehrere Instanzen zurückliefern kann: DB::getInstance($key = 'default'), also wenn ein neuer key übergeben wurde, wurde auch eine neue Instanz zurückgegeben.
                  Und hast damit Ansätze des Registry-Pattern übernommen.
                  Jetzt stellt sich mir die Frage, wie löst man soetwas, also wenn man bei Bedarf eine weitere Instanz benötigt? Beim Registry-Pattern müsste ich ja von vornherein zwei Instanzen in die Registry schieben, auch wenn in den meisten Fällen eine Instanz reichen würde? Bzw. erst überprüfen, ob diese Instanz schon existiert und ggf. eine neue anlegen.
                  Wäre in diesem Fall meine o.g. Lösung mit mehren Singleton-Instanzen sinnvoller?
                  Diese Pattern sind natürlich nur Ansätze, die in ihrer Gestalt nicht starr sind. D.h. du kannst dir auch eine Art konfigurierbare Registry erstellen oder so, die die Instanzen erst OnDemand erzeugt. Am Sinnvollsten arbeitest du dann auch direkt mit dem Abstrakte Fabrik-Pattern zusammen. Du kannst diese Muster als Grundlage verwenden und entsprechend deiner Bedürfnisse anpassen/abändern.

                  Kommentar

                  Lädt...
                  X