Abstract Singleton
Ich weiß, ich bin heute ziemlich spät dran, das liegt aber nicht daran, dass ich keine Lust hatte, aber mein Tag war wirklich anstrengend. Deswegen gibt es heute auch nur einen kurzen Beitrag von mir.
Ich habe ja schon vor ein paar Tagen über das Singleton Pattern geredet. Dank PHP 5.3 ist es jetzt kein Problem mehr schon alles für dieses Entwurfsmuster in einer abstrakten Elternklasse zu implementieren.
abstract class aSingleton { private static $instance; public static function getInstance( ) { $className = get_called_class( ); if ( ! isset(self::$instance ) ) { self::$instance = new $className( ); } return self::$instance; } protected function __construct( ) { } final private function __clone( ) { } }
Prinzipiell habe ich ja bereits bei meinem Artikel über die Singleton alles erzählt, was nötig ist, deswegen werde ich jetzt nur noch anmerken, wie man das ganze verwenden sollte.
Class Database extends aSingleton { } $db = Database::getInstance( );
Vielleicht kann man ja noch als Schlusswort hinzufügen, dass es nur funktioniert solange man einen einheitlichen Konstruktor für alle Singletons benutzt, da man in der abstrakten Klasse nicht unterscheiden kann.
Sorry wenn dieser Artikel ein wenig hektisch wird, aber man hat leider nicht immer genug Zeit.
Apropos nicht genug Zeit: das müsste __clone() sein, nicht clone(). Und die Eigenschaft $instance sollte als static deklariert sein. 🙂
Ich kann zwar den Hintergrund verstehen, nämlich dass man nicht immer wieder ein Singleton neu implementieren möchte, finden den Ansatz aber trotzdem nicht gut. Zum einen denke ich ist es wenig sinnvoll, etwas vom Typ Singleton zu haben (wobei sollte das helfen?), zum anderen bekommt man damit eine Hierarchie in alle Singletons, die eine Abhängigkeit darstellt welche so nicht gegeben ist.
IMHO wäre es sinnvoller zu warten bis Traits verfügbar sind, und das dann darüber zu lösen.
Morgen Frank, da muss ich dir absolut recht geben, bei allen deinen Punkten. Die beiden Fehler im Code habe ich behoben, dass ich nicht immer ein Freund des Singleton Musters bin, habe ich ja auch schon geschrieben.
Die Traits Idee werde ich auch jeden Fall noch mal aufgreifen, finde ich ziemlich „sexy“.
Hallo Leute!
Ich beobachte diesen Blog schon längere Zeit und ich muss sagen hier sitzen wirklich fähige Autoren dahinter!
Nun zu meinem Kommentar:
Ich entwickle schon seit anbeginn von PHP5.3 ein recht großes Framework für PHP5.3
Meine Singleton Implementation sieht ein wenig anders aus:
Nutzt halt LSB.
Das schöne is, damit kann man „schöne“ Enums in PHP realisieren.
Nachteil ist natürlich das man den Klassennamen und die Instanzvariable in jeder abgeleiteten Klasse hinterlegen muss.
Bei mir ist das mit dem Klassennamen nicht so das Problem, weil diese Variable bei mir ohnehin in jeder Klasse vorhanden ist.
Grüße aus Österreich
Manuel
@manuel: Erstmal Danke für das Kompliment. Kannst du mal ein Beispiel zu dem ENUM Vorteil bringen? Das ist mir irgendwie noch nicht so ganz klar. Denn ohne das Bsp. finde ich unsere Implementierung schöner, da wir keine protected Variable mitschleppen müssen.
ja, da hast du vollkommen recht, nur mit singletons muss/soll man ohnehin sparsam umgehen, nur beim enum gehts nicht ohne.
Via Reflection ist sogar ein iterierbarer Enum machbar (Delphi like)
das is halt schon a recht komplexe implementierung, aber dann kann man folgendes machen:
und dann:
Das schöne ist, das die wirklich typensicher sind
also
Hoffe das ist klar verständlich soweit, sonst einfach rühren ^^
Ich seh grad das is was aus nem alten commit hochgekommen..
Die iterator methode kann man streichen, dann spart man sich die abfrage im getMethods, weil im getIterator eh kein $this aufgerufen wird (da wären wir wieder bei einem älteren eintrag von euch ^^, in dem fall sogar sinnvoll einsetzbar)
es ginge dann sogar:
foreach (OutputTypes::xhtml() as $outputType)
echo $outputType;
aber das ist schwer zu lesen, und irreführend.