Alternative für globale Variablen

Braunstein

Was ist wenn man das Löschen, so wie hier beschrieben:http://www.oop-trainer.de/Themen/Singleton.html, mit einer guard-Klasse macht?

drakon

Klar kann man. Ich habe das "gefährlich" mit Absicht in Anführungszeichen geschrieben, weil es viele mögliche Implementierungen von Singletons gibt. Oftmals reicht aber Meyers völlig. Und ich bevorzuge eine einfache Lösung, wenn sie passt einer komplizierteren.

Ich sehe den wirklichen Unterschied dieses Guards nicht wirklich zu Meyers. Läuft ja auf das gleiche hinaus. Wenn allerdings der Guard noch zusätzliche Funkitionalität, wie z.B eine manuelle Zerstörung anbietet, dann ist das etwas völlig anderes. Aber, wie gesagt braucht man das ja eher selten und das Meyers Singleton reicht völlig.

hustbaer

Oft ist es ideal wenn man Singletons garnicht zerstört.

hustbaer schrieb:

Oft ist es ideal wenn man Singletons garnicht zerstört.

Noch öfters ist es ideal, wenn man Singletons garnicht benutzt.

drakon

hustbaer schrieb:

Oft ist es ideal wenn man Singletons garnicht zerstört.

Wenn nur eines vorhanden ist, dann ist es imo weniger tragisch. Dann zerstört es sich einfach als letztes. Sobald man aber Krieg der Singletons bestreiten will, dann wirds problematisch, wer sich selbst zerstört und wer auf den Leichen rumtrampelt..

AntiPatternInc schrieb:

Noch öfters ist es ideal, wenn man Singletons garnicht benutzt.

Vor allem nicht als Alternative zu globalen Variablen.

SinglePattern dürfte man Abstand das überbenutzteste Pattern überhaupt sein und es ist nahezu nie angebracht.
Ich finde mittlerweile sogar globale Variablen besser als Singletons.

volkard

Braunstein schrieb:

Was ist wenn man das Löschen, so wie hier beschrieben:http://www.oop-trainer.de/Themen/Singleton.html, mit einer guard-Klasse macht?

Dann hat man den Fall nicht zuende gedacht.
Warum hat der Wächter nur das Löschen und nicht auch noch das Erzeugen?
In Listing5 fällt die Asymmetrie stark auf.
Hauen wir das Erzeugen doch mal auch in den Wächter-Konstruktor und beobachten, was geschieht.
Es erinnert an was bekanntes. Moment, gleich kommts.
Den instanz-Zeiger und exemplar() auch in den Wächter rein!
Ja, wir habens raus. Es ist ein Meyers-Singleton, der ein gepimpltes Monster-Objekt hält.

drakon

Wie gesagt. Den Grund so etwas in diese Richtung zu machen, wäre für mich so etwas:

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

   private:
     static Singleton *instanz;
     Singleton() {}
     Singleton( const Singleton& );

     ~Singleton() {}

     class Waechter {
         public: ~Waechter() {
           if( Singleton::instanz != 0 )
             delete Singleton::instanz;
         }

         void destroy()
         {
           if ( !Singleton::instanz )
           {
             delete Singleton::instanz;
             Singleton::instanz = 0;
           }   
         }
     };
     friend class Waechter;
};

Somit könnte man das Singleton selbst zerstören, wenn das irgendwie notwenig ist, und wenn man es verigsst wird es automatisch gemacht.

pumuckl

auchmalanmerker. schrieb:

Ich finde mittlerweile sogar globale Variablen besser als Singletons.

Und ich find Vanilleeis ganz Klasse.
Mal ehrlich: hier sollte es weniger darum gehen was man an persönlichen Präferenzen für und gegen ein bestimmtes Pattern hat, sondern vielmehr darum, welche Vor- und Nachteile das Pattern in der gegebenen Situation gegenüber den Alternativen hat. Deswegen sollte zu jedem "ich finde" auch ein "weil" geliefert werden. Und zwar nicht "weil Vanilleeis einfach lecker ist".

Irgendwie versteh ich die Problematik nicht, die es beim Erzeugen/Zerstören geben soll.

Wenn ich das wie im Meyer Singleton mache (also eine Referenz auf eine statische lokale Variable liefere), wo ist dann das Problem?
Erzeugung: Nur wenn man die statische Funktion aufruft, wird das Objekt erzeugt. Passt.
Zerstörung: Ok da bin ich etwas überfragt. Finde eine statische lokale Variable eh irgendwie magisch. Wann wird diese Variable denn wieder zerstört? Und was genau ist jetzt dieses Zerstör-Problem? Kann da vielleicht jemand bitte ein kleines Beispiel bringen?

drakon

Statische Variablen werden nach dem Ende der main zerstört.

Das Problem ist die Reihenfolge, in der zerstört wird, wenn du 2 statische Variablen hast. Was passiert z.B, wenn die einte zerstört wird und die andere bei seiner eigenen Zerstörung auf die bereits zerstört zugreift?

Seh da noch immer nicht das Problem. Dann greif ich einfach in den Destruktoren der Singletons auf kein anderes Singleton zu. Dann is doch alles sicher?

Dravere

marti schrieb:

Seh da noch immer nicht das Problem. Dann greif ich einfach in den Destruktoren der Singletons auf kein anderes Singleton zu. Dann is doch alles sicher?

Sofern das möglich ist, was aber nicht immer geht. Ich würde das Problem als sehr selten bezeichnen, aber es kommt tatsächlich manchmal vor.
Deshalb hatte drakon auch gesagt, dass in den meisten Fällen das Meyers Singleton absolut ausreicht.

Grüssli

volkard

marti schrieb:

Seh da noch immer nicht das Problem. Dann greif ich einfach in den Destruktoren der Singletons auf kein anderes Singleton zu. Dann is doch alles sicher?

Jup. Nur kann man sich da manchmal nicht sicher sein, zum Beispiel hast Du irgendwann Sorgen mit dem Drucker und machst zur Sicherheit mal rein, daß die Druckerdestruktion geloggt wird. Hast aber vergessen, daß nicht nur der Drucker ein Singleton ist, sondern das LOG-Makro innendrin auch einen Singleton verwendet. Schade.
Aber will man ALLES bedenken im Umgang mit Singletons, hat man irgendwie einen gewissen Spaßverlust.

Ok, verstehe. Gibt es sonst noch Fallstricke bei Singletons? Vielleicht Probleme bei Multithreading?

drakon

Dravere schrieb:

marti schrieb:

Seh da noch immer nicht das Problem. Dann greif ich einfach in den Destruktoren der Singletons auf kein anderes Singleton zu. Dann is doch alles sicher?

Sofern das möglich ist, was aber nicht immer geht. Ich würde das Problem als sehr selten bezeichnen, aber es kommt tatsächlich manchmal vor.
Deshalb hatte drakon auch gesagt, dass in den meisten Fällen das Meyers Singleton absolut ausreicht.

Grüssli

Und wenn der Fehler auftaucht, dann sucht man bestimmt nicht da.. Respektive man debugg sich zu tode bis man auf die Idee kommt den Debugger doch einmal bis ganz ans Ende laufen zu lassen..

Aber will man ALLES bedenken im Umgang mit Singletons, hat man irgendwie einen gewissen Spaßverlust.

No risk, no fun! Code-Cowboys ftw, Programmierer sind auch coole Leute mit Hut und Sonnenbrille. :p *SCNR*

Ist denn beim Meyers Singleton überhaupt die Sicherheit gegeben, dass das Objekt wirklich erst beim Programmende zerstört wird und nicht während der Ausführung des Programms vom Programm selber? Ich frage, weil man ja i.d.R keine Kontrolle über die Zerstörung von auf dem Stack angelegten Objekten hat.

drakon

Streifen schrieb:

Ist denn beim Meyers Singleton überhaupt die Sicherheit gegeben, dass das Objekt wirklich erst beim Programmende zerstört wird und nicht während der Ausführung des Programms vom Programm selber? Ich frage, weil man ja i.d.R keine Kontrolle über die Zerstörung von auf dem Stack angelegten Objekten hat.

Ja, ist gegeben. Habe den Standard gerade nicht zur Hand, aber das steht da irgendwo.

Hm, irgendwie bringt mich das zur Erkenntnis, dass Singletons stinken..