PHP Entwurfsmuster: Singleton

Lesetipps

1. Abstract Singleton
2. PHP 5.3 Feature: Late static binding (LSB)
3. Das Singleton, richtig implementiert

Nachdem die letzen zwei Tage nicht wirklich von Softwaretechnik handelten, habe ich mir gedacht, ich schreibe mal wieder was zu meinem Lieblingsthema. Die Entwurfsmuster. Das gute an diesen kleinen Helfern ist, dass es so viele sinnvolle von ihnen gibt. Der heutige Beitrag dreht sich aber nur um eins der meist verwendeten Pattern die man so findet. Und zwar geht es um das Singleton Pattern. Ja ich weiß, keine Überraschung, denn der Titel dieses Postings verrät ja bereits alles.

Die Idee, die hinter einem Singleton steckt ist ganz einfach. Ich benötige genau eine Instanz einer Klasse und möchte sicher gehen, dass es auch keine zweite irgendwie erstellt werden kann. Ein Beispiel für so eine Klasse wäre zum Beispiel eine Datenbankverbindung, wenn man davon ausgeht, dass es nur eine Datenbankverbindung pro Projekt gibt. Wie man dies über einfache PHP Klassen hin bekommt, möchte ich kurz im Folgenden erklären. Aber vielleicht gebe ich einfach am Anfang schon ein Beispiel zu einer Singleton, damit es ein wenig anschaulicher wird.

class Singleton
{
  private static $instance;

  private function __construct( )
  {
  }

  private function __clone( )
  {
  }

  public static function getInstance( )
  {
    if ( is_null( self::$instance ) ) {
      self::$instance = new self( );
    }
    return self::$instance;
  }
}

Man muss zugeben, wirklich komplex sind diese Funktionen nun echt nicht. Die “Privatisierung” des Konstruktors und der Clone Methode sorgen lediglich dafür, dass man keine Instanz der Klasse erstellen kann ohne über die getInstance() Methode zu gehen.
Eigentlich ist bereits jetzt alles wunderbar, nur eine Instanz kann erstellt werden. Technisch gesehen sind wir auch bereits am Ende angelangt, in der Theorie lohnt es sich hingegen noch ein paar Gedanken in diese Thematik zu stecken. Größter Kritikpunkt bei diesem Entwurfsmuster ist, dass es im Grunde genommen nur ein Ersatz für globale Variablen zu sein scheint. Wenn es nur eine Instanz gibt, dann greifen alle Funktionen, die Methoden dieser Klasse verwenden, genau auf das gleiche Objekt zu. Man kann also nie genau sagen, welche Daten derzeit im Singleton gespeichert sind und welchen Zustand sie gerade hat.

Man sollte sich also im klaren sein, wann und in welchem Umfang man eine Singleton verwendet. Keine Probleme sollte es z.B. bei einer Config Klasse geben, solange man nur Daten liest und nicht schreibt. Eine Datenbankklasse kann bei geeignetem Interface auch für dieses Entwurfsmuster prädestiniert sein. Ich könnte noch hunderte Beispiele nennen, nur leider fallen mir keine mehr ein. Nein, Witz bei Seite. Es gibt natürlich sehr viele Anwendungsgebiete, die dieses Pattern wunderbar abdeckt, aber es gibt auch die Schattenseite dieser Programmiertechnik.

4 Kommentare »

• 
  

  Manko10

  am 24. August 2008 um 19:31 Uhr

  Hi,

  ein kleiner Tipp: man kann den Konstruktor auch als protected deklarieren. Dann können evtl. davon abgeleitete Klassen noch darauf zugreifen, wenn das gewünscht ist.

• 
  

  Nils Langner

  am 24. August 2008 um 19:36 Uhr

  Da hast du natürlich Recht, ich würde die Methode aber erst protected machen, sobald ich mir sicher bin, dass ich die Funktion wirklich überschreiben will. Solange sollte sie meiner Meinung nach auch nur die minimale Sichtbarkeit besitzen.

• 
  

  Abstract Singleton | PHP hates me

  am 15. September 2008 um 18:41 Uhr

  [...] 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 [...]

• 
  

  Kim

  am 27. April 2010 um 16:27 Uhr

  Ich würde Nils Aussage sogar noch um ein “final” erweitern.

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar