Singleton oder "rein statische" Klasse
-
Naja, ich kann mich da <C++0x> nur anschliessen, mir ist der Einsatz von Singletons auch nicht so ganz klar. Zunächste schliesse ich mich auch der Meinung an, dass Singletons minimal ineffizienter sind, als die Implementierung von statische Funktion und Variablen. Aber dies ist natürlich kein Nachteil von Singletons, da dieser Performancenachteil (wenn überhaupt einer besteht) praktisch Null ist.
Trotzdem weiss ich nicht, wozu man sich die Mühe machen soll, erst einen objektorientieren Ansatz zu wählen, wenn man anschliessen gewaltsam mit Singleton-Eigenschaften diesen Ansatz wieder auf nicht OOP-Elemente reduziert.
Persönlich bin ich zwar ein starker Befürworter der OOP und mache auch erst mal für alles eine Klasse, auch wenn von einer bestimmten Klasse immer nur eine Instanz existiert, die als Hauptklasse agiert. Aber solche Klassen baue ich am Ende des Projekts dann immer noch "sauber" in statische Funktionen/Methoden um, was man natürlich auch als Singleton realisieren könnte.
Ich denke mir, dass ist schliesslich eine reine Geschmackssache, ob man Singletons oder statische Funktionen/Variablen verwendet.
Oder gibt es vielleicht doch noch wichtige Eigenschaften von Singletons, die ich bisher nicht bedacht habe?
-
Es geht darum, dass man ja eigentlich eine statische Klase hat.
Und eine statische Instanz einer Klasse in der Klasse selber hat so ziemlich den gleichen Effekt, wie eine statische Klasse.
Allerdings ist es einfach schöner, nicht vor jedes Element der Klasse ein static schreiben zu müssen und auch nicht jede Variable extra zu definieren.Deswegen ziehe ich SingleTons vor.
MfG MAV
-
Damit ist es wohl eine rein ästhetische Sache, aber "echte" Vorteile gibt es somit anscheinend nicht, die dann explizit für Singletons sprechen würden...?
-
Mir sind jedenfalls keine bekannt.
Aber wenn du das so sagst, dann sind Klassen und alle Elemente C++s auch nicht >wirklich< vorteilhaft.
Schließlich kann man in ASM alles nachmachen, ist der äquivalenete Code.
Es ist einfach viel besser zu schreiben mit Singletons und viel komfortabeler.
Und mehr ist C++ in Bezug auf ASM AFAIK auch nicht.
-
Original erstellt von Mis2com:
Mir sind jedenfalls keine bekannt.
Aber wenn du das so sagst, dann sind Klassen und alle Elemente C++s auch nicht >wirklich< vorteilhaft.Das habe ich nicht gesagt. Wenn man von OOP gebrauch machen will, sind Klassen unumgänglich, aber bei Singletons sind OOP-Ansätze nicht erforderlich. Du lässt ja (wahrscheinlich) auch Dein programm immer in "::main" starten, und schreibst nicht erst einen Singelton
class CApplication { ... };und lässt Dein Proramm dann in CApplication::main() beginnen. Könnte man natürlich machen, aber dies ist so ein Beispiel von dem ich Rede. Man hat immer nur eine Instanz, die mir evtl. ein paar Funktionen und Variablen verpackt. Wenn ich aber immer nur eine Instanz habe, über die ich auf die Elemente zugreife (eben ein Singelton), dann brauche ich sie nicht. Dann kann ich auch gleich die Funktion main(){...} implementieren und globale Variablen und Funktionen einführen. Evtl. verpacke ich sie noch in einen Namespace, um es übersichtlicher zu strukturieren.
Also, gegen OOP und Klassen habe nichts gesagt, mir geht es nur über Sinn und Unsinn von "SINGLETONS" bzw. nicht einmal über Sinn und Unsinn, sondern darüber, ob es "wirkliche" Vorteile der Singeltons gibt, oder ab man es bei "Geschmackssache" belässt.
-
Es ist für mich eine Art Teil eines Programmierstils.
Ähm, naja, von main() aus starte ich eine main Funktion einer SingleTon-Klasse.
Ist aber kein unverbreiteter Programmierstil.
-
wäre das nicht eine gute Idee für C++0x ?
Man schreibt einfachstatic class Foo {};und schwupps! sind alle Elemente und Methoden static und man braucht kein Singleton mehr!
-
Original erstellt von <C++0x>:
**wäre das nicht eine gute Idee für C++0x ?
**naja denke nicht, c++ ist jetzt schon mit syntax und co. überladen
-
Original erstellt von wischmop2:
Trotzdem weiss ich nicht, wozu man sich die Mühe machen soll, erst einen objektorientieren Ansatz zu wählen, wenn man anschliessen gewaltsam mit Singleton-Eigenschaften diesen Ansatz wieder auf nicht OOP-Elemente reduziert.???
Ein Singleton ist doch gerade ein OOA-Element... man erkennt, daß genau _eine_ Instanz einer Klasse notwendig ist und setzt dafür diese Vorgehensweise ein, um die Stückzahl zu limitieren.
-
/me schließt sich Marc++us an
warum denkt ihr, dass eine Klasse bestehend aus static Methoden schöner ist, als ein Singleton?
vorallem: eine klasse mit nur static Methoden hat einen großen nachteil: man kann nicht gut von ihr erben.
wie sieht es mit dem Ctor aus? wann wird er aufgerufen? den muss man anscheinend explizit aufrufen, zumindest fällt mir keine möglichkeit ein.
-
Hallo,
ich habe es schonmal geschrieben und schreibe es auch nochmal:
Singleton != Static Data + Static Functions.Vielleicht sollte ihr erstmal über das DP lesen (z.B. im GoF-Book oder im CUJ-Ausgabe 2/2003) bevor ihr drüber redet. Die wichtigsten Eigenschaften von Singletons wurden in diesem Thread noch überhaupt nicht genannt.
Das Problem ist, dass scheinbar nur wenige die Vorteile von Singletons kennen, trotzdem aber alle welche benutzen. Und dabei leider vergessen, dass *jedes* DP seine eigene Komplexität mit sich bringt.
Und nein, ich werde die Eigenschaften des Singleton-DPs hier nicht aufzählen..
[ Dieser Beitrag wurde am 30.03.2003 um 19:00 Uhr von HumeSikkins editiert. ]
-
Wäre ein Singleton als Sammlung von Funkionen und Variablen gedacht, würde sie tatsächlich keiner Verwenden.
OOP beschäftigt sich doch damit, die im Problem vorhandenen Objekte zu erzeugen und interagieren zu lassen. Ein Singleton ist Einfach ein Objekt, das es nur einmal geben kann. Das Singleton dient dazu, dass man nicht fälschlicherweise mehrere Instanzen erstellt. Es ist also eigentlich ein Schutz vor OOA-technischen Fehlern.
-
Und nein, ich werde die Eigenschaften des Singleton-DPs hier nicht aufzählen.
Doch. Wir machen hier so lange Unfug, bis Du weich wirst.
-
Doch. Wir machen hier so lange Unfug, bis Du weich wirst.
Na dann noch viel Spass.
-
Original erstellt von Helium:
OOP beschäftigt sich doch damit, die im Problem vorhandenen Objekte zu erzeugen und interagieren zu lassen. Ein Singleton ist Einfach ein Objekt, das es nur einmal geben kann. Das Singleton dient dazu, dass man nicht fälschlicherweise mehrere Instanzen erstellt. Es ist also eigentlich ein Schutz vor OOA-technischen Fehlern.Also noch mal langsam, für Menschen wie mich: Ein Objekt ist eine Sammlung von Zugriffsmöglichkeiten ('Methoden'), die auf einem Zustand ('Variablen') rumfuhrwerken. Jetzt baut man zusätzlich irgendetwas (man macht sein Programm komplexer) damit man die Abstraktion, die man vorher gebaut hat, wieder zu entfernen. Irgendwie erschließt sich mir der Sinn nicht.
-
Der Vorteil eines Singletons ist doch, dass garantiert ist, dass das Teil korrekt instanziiert ist, wenn es das erste mal benutzt wird. Bei Klassen mit statischen Members ist das genauso garantiert, wie bei globalen Variablen: garnicht. Die Reihenfolge der Instanziierung ist modulübergreifend nicht definiert.
Dann kann ich auch gleich die Funktion main(){...} implementieren und globale Variablen und Funktionen einführen. Evtl. verpacke ich sie noch in einen Namespace, um es übersichtlicher zu strukturieren.
Könntest Du, außer dass Du die Vorteile von OO aufgibst, nur weil es sich um ein konstrukt handelt, dass es nur einmal geben soll: Datenkapselung, Zugriffsschutz. Mit welchem Grund sollte sich aber etwas anders verhalten, nur weils global ist?
-
Ein Objekt ist eine Sammlung von Zugriffsmöglichkeiten ('Methoden'), die auf einem Zustand ('Variablen') rumfuhrwerken.
Technisch ja, semantisch nein.
Jetzt baut man zusätzlich irgendetwas (man macht sein Programm komplexer) damit man die Abstraktion, die man vorher gebaut hat, wieder zu entfernen. Irgendwie erschließt sich mir der Sinn nicht.
Inwievern zerstöre ich durch Singletons in irgendeinerweise die bereits vorhandene Abstraktion?
-
Original erstellt von Helium:
Technisch ja, semantisch nein.Was ist es dann? Eine Abstraktion von einem Tischbein?
Inwievern zerstöre ich durch Singletons in irgendeinerweise die bereits vorhandene Abstraktion?
Wieso quätscht man Dinge, die man exakt ein mal braucht in eine Klasse und diese Klasse in ein Singleton? Um die Probleme mit mit der Instantierreihenfolge zu umgehen und welche mit der Zerstörung (Zeitpunkt, Ressourcenfreigabe etc) anzufangen?
Ich bin noch nie in die Verlegenheit gekommen, in ein Büch über Designpatterns hineinzusehen, muss ich zugeben. Vielleicht sollte ich das mal tun, aber irgendetwas in mir wehrt sich dagegen ...
-
Original erstellt von Daniel E.:
Wieso quätscht man Dinge, die man exakt ein mal braucht in eine Klasse und diese Klasse in ein Singleton? Um die Probleme mit mit der Instantierreihenfolge zu umgehen und welche mit der Zerstörung (Zeitpunkt, Ressourcenfreigabe etc) anzufangen?Hab mal die drei Hauptgründe zusammengetragen:
- Um das Prog ein wenig lahmer zu machen. (Beim Umbau von globaler Variablen in Meyers-Singleton.)
- Weil der Lehrer immer sagte "nehmt keine globalen Variablen". (Ich wär fast vom Stuhl gefallen, als mir das einer als Begründung antat.)
- Weil das Wort "Singleton" so hübsch ist. (Mein Favorit.)
-
Hallo,
also ich verstehe ja nach wie vor nicht, warum soviele so blind auf das Singleton-DP (oder Highlander) abfahren, wo ein Monostate (oder Borg) doch häufig viel besser geeignet ist. Und häufig ist eine simple globale Variable sowieso am Einfachsten.