Die Flagge des Marasek

Dekostreifen

English

Aktuell Texte Der Comic Impressum Kalender Suche PHP-Klassen Container-Wizard main.s21

Kategorien

Buch
Computer
Computerspiele
Film
Geschichte
Gesellschaft
Idee
Kunst
Natur
Persönlich
Politik
Programmieren
Religion & Philosophie
Weblog
Weltpolitik
Weltsicht
{{login}}

Paranoid Singleton

Permalink
Vorheriger: The FizzBuzz-TestNächster: What else than ELSEIF?
Eingeordnet in: Programmieren

I did some reading on the Singleton-Pattern, including drastic warnings what would befall me if I should ever use it. So another minefield on the map of Information Technology.

Actually, I haven't used Singleton for seven years except in one short lived exception; when I was more into OOP, I used Registry instead. I mainly follow the reasoning of the Anti-Singleton-Movement; as someone of IBM put it, Singleton pulls a value out of thin air without being immediately visible within, say a method signature. And I really hate it when things are pulled out of thin air, especially if you cannot "ensure beyond paranoid doubt" that it will actually be there.

However, I've seen worse - wide abuse of constants or global values, and, especially evil, global arrays of, say, configuration parameters. Moving them into classes is certainly less evil, and realizing said classes as Singleton might be appropriate in some cases.

The usual Singleton blueprint for PHP usually looks like that:

<?php
class Singleton {
    static private 
$instance;
    private function 
__construct() {
    }
    static function 
getInstance() {
        if(
self::$instance==NULL) {
            
self::$instance = new Singleton();
        }
    return 
self::$instance;
    }
}
?>

This common definition has a drawback. When using Singleton, you will most likely have two different uses. Instantiating the Singleton for the first time, give some information to it, like configuration. The second is when you instantiate it again, somewhere deep within your application, to actually use the Singleton. However, when calling Singleton::getInstance(), you can never be sure whether you get the very first instance or another one. And I'm of the opinion that it is reasonable to force the coder to know what he is doing, having him distinguish between "first" and "further" calls of getInstance:

<?php
class ParanoidSingleton {
    static private 
$instance;
    private function 
__construct() {
    }
    static function 
getFirstInstance() {
        if(
self::$instance!=NULL) {
            throw new 
Exception("Singleton has been instantiated before");
        }
        
self::$instance = new ParanoidSingleton();
    return 
self::$instance;
    }
    
    static function 
getInstance() {
        if(
self::$instance==NULL) {
            throw new 
Exception("Singleton has not been instantiated yet, use getFirstInstance");
        }
    return 
self::$instance;        
    }
}
?>

If the Singleton is wrongly created, the programmer gets what he deserves (and what he needs): an Exception telling him what is wrong and where.

Kommentieren

Bitte beachten: Kommentare sind nicht sofort sichtbar, sondern werden erst nach einer kurzen Prüfung freigegeben, sofern keine rechtliche Beanstandung vorliegt.
Rechtlich bedenkliche Inhalte werden entweder entschärft oder nicht veröffentlicht.

* Titel  
* Nickname  
* Kommentar