Alternative für globale Variablen

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

Dravere

marti schrieb:

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

Da bist du über das Ziel der Erkenntnis hinausgeschossen. Korrekter wäre:
1. Singletons ersetzen keine globalen Variablen.
2. Singletons sollten so oft wie möglich vermieden werden, wie auch globale Variablen.

Es gibt halt nicht die Lösung, welche alle Probleme beseitigt. Und man sollte sich bei der Lösung über die Vor- und Nachteile bewusst sein. Gilt aber für alles, deshalb habe ich es auch so allgemein geschrieben.

Grüssli

Dravere schrieb:

marti schrieb:

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

Da bist du über das Ziel der Erkenntnis hinausgeschossen. Korrekter wäre:
1. Singletons ersetzen keine globalen Variablen.
Grüssli

Scheinbar gibt es mehr Nachteile als Vorteile bei der Benutzung von Singletons, wobei es viele unterschiedliche Meinungen gibt. So findet man Einträge wie "Why Singletons are evil". In Punkt eins wird beschrieben, warum Singletons keine alternative für globale Variablen darstellen:

Singletons frequently are used to provide a global access point for some service.
True, they do this, but at what cost? They provide a well-known point of access to some service in your application so that you don't have to pass around a reference to that service. How is that different from a global variable? (remember, globals are bad, right???) What ends up happening is that the dependencies in your design are hidden inside the code, and not visible by examining the interfaces of your classes and methods. You have to inspect the code to understand exactly what other objects your class uses. This is less clear than it could be. The urge to create something as a global to avoid passing it around is a smell in your design; it is not a feature of globals/singletons. If you examine your design more closely, you can almost always come up with a design that it is better and does not have to pass around tramp data to every object and method.

Vielleicht sollte ich mein Design doch nochmals überdenken...

volkard

Nehmen wir einfach mal globale Variablen als Ersatz. Die Reihenfolge der Instanzzierung globaler Variablen über verschiedene Übersetzungseinheiten sicherzustellen, ist schon ein Kapitel für sich. Und wenn die globalen Variablen sich auch noch gegenseitig benutzen...
Will man ALLES bedenken im Umgang mit globalen Variablen, hat man auch einen gewissen Spaßverlust.

volkard schrieb:

Nehmen wir einfach mal globale Variablen als Ersatz. Die Reihenfolge der Instanzzierung globaler Variablen über verschiedene Übersetzungseinheiten sicherzustellen, ist schon ein Kapitel für sich. Und wenn die globalen Variablen sich auch noch gegenseitig benutzen...
Will man ALLES bedenken im Umgang mit globalen Variablen, hat man auch einen gewissen Spaßverlust.

Das ist schon richtig, aber um nochmal auf das Ausgangsproblem zurückzukommen... Wie würdet ihr denn nun verschiedene Settings aus einer ini-Datei Laden und diese für das gesammte Projekt verfügbar machen? Eigentlich fallen mir da nur globale Variablen oder Singleton ein...