class Singleton
{
   public:
     static Singleton* exemplar();

   protected:
     Singleton() {}

   private:
     static Singleton *instanz;
};

Singleton* Singleton::instanz = 0;

Singleton* Singleton::exemplar()
{
  if( instanz == 0 )
    instanz = new Singleton();
  return instanz;
}

Quelle: http://www.oop-trainer.de/Themen/Singleton.html

Ich weiss nicht, ist doch static
Singleton erlaubt nur das einmalige Erstellen eines Objektes.

@???: Der Vorteil davon ist, daß der Singleton erst angelegt wird, wenn er wirklich gebraucht wird - und das kann unter Umständen "nie" sein. Außerdem ist das System erweiterbar (du könntest z.B. auch mehrere Objekte der Klasse anlegen und verwalten).

man sollte auch nicht vergessen, daß man über ein singleton ein Programm auch threadsafe machen kann, wenn mehrere Threads auf dieselben Daten (schreibend) zugreifen müssen (in "unserem" Server brauchen wir z.B. einen zentralen Zähler, von dem sich jeder Thread eine eindeutige Nummer abholen muß).. Ein static an sich ist leider nicht threadsafe (sagt Matthew Wilson in "Imperfect C++") ...

Gruß,

Simon2.

Ein static an sich ist leider nicht threadsafe (sagt Matthew Wilson in "Imperfect C++")

Ein Singleton ansich ist auch nicht Threadsafe...

ganz einfach weil du bei lauter statischen Methoden eine noch viel höhere Kopplung erzielst, als es das Singleton ohnehin schon hat. Beim Singleton bestehen aber noch Möglichkeiten, wie das Implementieren einer Schnittstelle, zur Auflösung dieser Kopplung.

class Printer {
    public:
        virtual void printDocument(Document document) = 0;
};

class LocalPrinter : Printer {
    private:
        LocalPrinter() {

        }

    public:
        virtual void printDocument(Document document) {
            // ...
        }

        static LocalPrinter& getInstance() {
            static LocalPrinter printer;
            return printer;
        }
};

void printReports(Printer printer) {
    // ...
}

// anschließend der Aufruf:

printReports(LocalPrinter::getInstance());

Bei einem Singelton werden alle Membervariablen zum gleichen Zeitpunkt initialisiert, ohne dass ich mir darüber Gedanken machen muß. Verwende ich n statische Variablen ist nicht definiert in welcher Reihenfolge diese initialisiert werden. Darum muß ich mich kümmern.

Singeltons müssen außerdem nicht zwingend beim Programmstart erzeugt und erst beim Programmende gelöscht werden. Wenn ich solche Objekte gerade nicht benötige kann ich sie löschen und bei Bedarf wieder erzeugen. Ich kann das Objekt auch als ganzes verwerfen und mir ein vollkommen anderes erzeugen.

weil du dann auch alle daten static machen muesstest, dabei ist dann die initialisierung erst ausgefuehrt wenn du diese daten zum ersten mal verwendest und bei singletons moechte man ja gerade, dass beim ersten zugriff alle daten/member initialisiert sind.

nicht Zwangsläufig:

class MySingleton
{
public
    static PrintSingletonData(void)
    {
        cout << "My Singeltons data : " << m_Singelton.m_iSomeSingletonData << endl;
    }
  private:
    MySingleton() : m_iSomeSingletonData(0){}
    MySingleton m_Singelton;
    int m_iSomeSingletonData;
};

MySingleton MySingleton::m_Singelton;

Ich denke auch, das denjenigen, der das Singleton benutzt eigentlich die Instanz nicht interessieren sollte, sonder eher, was es tut.

@unkreativ003

Bei Deinem Beispiel fehlt die Implementierung von printReports und dort hast du dann eine Kopplung an Printer - gut: zugegeben, an einer Stelle zentral gekapselt.

@unkreativ003
Bei Deinem Beispiel fehlt die Implementierung von printReports und dort hast du dann eine Kopplung an Printer - gut: zugegeben, an einer Stelle zentral gekapselt.

Die Kopplung zur "Schnittstelle" Printer ist ja auch egal, schon alleine weil eine Abhängigkeit zu einer Schnittstelle nicht zusätzlich auch noch transitive Abhängigkeiten mit sich bringt. Das Angenehme an dieser Vorgehensweise ist ja, dass das Singleton ersetzt werden kann, beispielsweise beim Testen. Gerade in Komponententests sind Singletons, bzw. singleton-ähnliche Konstruktre pures Gift, da man sie nicht durch Mock-Objekte oder ähnliches ersetzen kann.

Simon2 schrieb:

Ein static an sich ist leider nicht threadsafe (sagt Matthew Wilson in "Imperfect C++")

Ein Singleton ansich ist auch nicht Threadsafe...

Das wissen aber viele nicht.

Bei einem Singleton ist auch klar, dass man nur entsprechende Memberfunktionen zugreift und dabei eine gewisse Funktionalität bereitstellt (zu der auch Serialisierung gehören kann).
WENN außerdem später doch ein Multithreading unterstützt werden soll, muß man beim singleton nur die Zugriffsfunktionen anpassen, während man bei einem "einfachen static" jeden einzelnen Zugriff rauspulen muß ...

Gruß,

Simon2.

Das Singleton-Muster wird zu 95% falsch eingesetzt.

99% der Thesen Unregistrierter sind zu schwach begründet.

Gruß,

Simon2.

Najo da hat er aber schon recht...

Ich aber auch ! :p

BTW: Hat hier eigentlich irgendjemand behauptet, singletons seien von sich aus threadsafe ?
Solange das nicht der Fall ist, kann man vielleicht seine Gebetsmühlen wieder einpacken und mit diskutieren anfangen (wer will).

Gruß,

Simon2.

Damit ich das Singleton austauschen kann muss ich ja ein interface zurückgeben und irgendwie wird dann das Singleton immer mehr zur Factory

Ansatzweise richtig erkannt, aber es liegt vielmehr daran, dass man das Singleton bei einer Schnittstelle nicht mehr direkt verwendet, sondern sich beispielsweise als Parameter übergeben lässt, wodurch also auch keine Notwendigkeit für den globalen Zugriff gegeben ist. Ich selbst geh auch immer öfter in Richtung Factory, die ich wenn nötig einfach zusätzlich entsprechend dekoriere, so dass nur eine Instanz erstellt wird. Ansich ist diese Grundsatzfrage vergleich mit der Frage um die Abhängigkeitsauflösung (Inversion of Control oder Service Locator).

Das Problem beim Singleton ist ja wie bereits erwähnt einfach, dass es zu leichtfertig verwendet wird. Die Vernetzung einzelner Software-Komponenten gestaltet sich oft aufgrund falscher Design-Maßnahmen als schwierig. "Dank" dem globalen Zugriff eines Singletons kann man diesen falschen Design-Maßnahmen entgegenwirken, zahlt aber einen sehr teueren Preis - hohe Kopplung. Wenn man allerdings zu Beginn schon nicht das richtige Design gewählt hat, wird einem diese zusätzliche Kopplung aber auch egal sein.

WENN außerdem später doch ein Multithreading unterstützt werden soll, muß man beim singleton nur die Zugriffsfunktionen anpassen, während man bei einem "einfachen static" jeden einzelnen Zugriff rauspulen muß ...

Ne.

Du musst jede Methode synchronisieren. Es mag einige tricks geben wie zB Adapter, die dir das bei einem Singleton erleichtern, aber du musst jede Methode abwaegen und synchronisieren. getInstance() zu synchronisieren reicht nicht aus.

@TheBigW:
doof nur dass du damit keine Objekte mehr rumreichen kannst.

Löscht ihr singletons wieder? Was bringt das eigentlich? Es bleibt ja bis zum Programmende immer das selbe und wird dann vomOS automatisch gelöscht.

nö. ich lösche singletons nicht. globale statische variablen sind für mich auch eine sorte singletons.
bei korrekt implementioerten singletons löscht c++ die irgendwie automatisch. gelöscht müssen sie aber werden bevor das bs den speicher wegräumen darf. zu leicht baut man später ein, daß das gesiglete objekt am ende eine datei schließen muss oder dergleichen.

doof nur dass du damit keine Objekte mehr rumreichen kannst.

@Shade

Naja, kommt doch auf den Anwendungsfall an, oder? Wenn ich ein Singleton habe, was nur eine public Memberfunktion hat, dann nervt es sicher (aus Anwendersich) auf Dauer, wenn ich immer erst meine Instanz holen muß. Wer sagt, das ich es unbedingt als Objekt herumreichen will/muß?

Ansich zeigt diese Diskussion doch nur, dass es DAS Singleton so im Detail nicht giebt. Sei es das Thema initialisierung/deinitialisierung, Zugriff oder was auch immer. Singleton sagt eben nur etwas über die Instanziierbarkeit aus und läßt die anderen Details im Dunkeln.

Es bringt halt Vorteile mit sich, dass ein Singleton als Objekt behandelt wird. Du kannst das Objekt im Nachhinein spezialisieren, indem Du davon ableitest. Du kannst bei Bedarf refactorn, falls Du doch mal mehrere Instanzen erlauben willst. usw...

Wenn Du die Funktionalität statisch bereit stellst, dann kannst Du sie nie im Nachhinein polymorph überschreiben. -> unflexibel

Es geht mir auch nicht darum hier zu sagen, das immer alle member statisch sein sollen. Ich sage nur, das es Fälle giebt wo das durchaus Sinn machen kann. Es schließt ja nicht mal aus, das man die Instanz trotzdem durch die Gegend reicht.

Warum bleibt es bis Programmende das Selbe?

Weil das doch gerade der Sinn des Singleton ist.