Hi Leuts, ich habe eine Frage zu sog. Singleton-Entwurfsmustern. Ich habe in einem Script und auch bei Wikipedia geschaut, aber noch nicht ganz genau verstanden, worum es dabei geht. Ich stelle mir vor, dass Singleton bedeutet, dass eine Singleton-Variable oder eine Sigleton-Funktionnur einmal im Speicher vorhanden ist und erzeugt werden kann und kein zweites mal. Hab ich das so richtig verstanden?
Anfänger schrieb: > Ich stelle mir vor, dass Singleton bedeutet, dass eine > Singleton-Variable oder eine Sigleton-Funktionnur einmal im Speicher > vorhanden ist und erzeugt werden kann und kein zweites mal. Nenne es Objekt (denn Funktionen sind sowieso nur ein einziges mal im Speicher vorhanden). Abgesehen davon stimmts. Der springende Punkt ist die Garantie "Es kann nur Einen geben!". Singleton macht nur im Zusammenhang mit Objekten (also Datenstrukturen) Sinn.
Danke für Deine schnelle Antwort. Eine Frage hätt ich noch - könnte der Sinn von einem Singleton-Objekt sein, dass ich dieses nur einmal im Speicher hab, damit es keine Probleme damit gibt? Gedankenexperiment: Es könnte ja z.b. sein, dass ich einen Messwert in einem Objekt ablege, irgenwann z.B. mach ich von dem Messwert eine Kopie und werte diesen Messwert dann anhand der Kopie aus - aber der Messwert hat sich inzzischen verändert und wenn ich die Kopie verwende ist diese eben nicht mehr aktuell - und durch die Singleton-Methode gibt es keine Kopien dieses Objekts im Speicher, sondern nur dieses eine und somit könnte dieses Problem "vermieden" werden?
Anfänger schrieb: > Danke für Deine schnelle Antwort. > > Eine Frage hätt ich noch - könnte der Sinn von einem Singleton-Objekt > sein, dass ich dieses nur einmal im Speicher hab, damit es keine > Probleme damit gibt? Genau darum geht es beim Singleton. Wenn du einen Drucker am PC an einem bestimmten Anschluss hast, dann willst du im System auch nur 1 Drucker-Objekt dafür haben. Singleton realisiert das Highlander Prinzip: "Es kann nur Einen geben!" > Gedankenexperiment: > Es könnte ja z.b. sein, dass ich einen Messwert in einem Objekt ablege, > irgenwann z.B. mach ich von dem Messwert eine Kopie und werte diesen > Messwert dann anhand der Kopie aus - aber der Messwert hat sich > inzzischen verändert und wenn ich die Kopie verwende ist diese eben > nicht mehr aktuell - und durch die Singleton-Methode gibt es keine > Kopien dieses Objekts im Speicher, sondern nur dieses eine und somit > könnte dieses Problem "vermieden" werden? Na, ja. Ist zwar eine etwas unorthodoxe Verwendung für ein Singleton, weil es ja durchaus realistisch ist, dass man eben doch eine Kopie der Messwertreihe haben will (weil man nach einer Veränderung wieder das Original braucht), aber möglich wärs. Abstrahiere Singleton lieber mit etwas pyhsikalisch Realem. Dein Messaufbau hat nur ein Spektrometer im System. Das ist absichtlich so und muss auch so sein. D.h. jeder Programmteil der was vom Spektrometer will, landet bei immer demselben Gerät, im Programm also beim immer gleichen Objekt. Eine UART hat eine FiFo. EINE Fifo! Nicht mehrere.
Singletons sind oft ein Zeichen für schlechten Programmierstil: http://www.google.com/search?q=the+singleton+antipattern Ein Singleton ist im Prinzip ein Objekt was statisch für den Prozess sein soll, dies aber über eine Instanz einer Klasse anstelle über statische Member und/oder Methoden realisiert. Karl Heinz Buchegger schrieb: > Eine UART hat eine FiFo. EINE Fifo! Nicht mehrere. Und wenn ich zwei UARTS habe müssen die sich ein FIFO teilen --> blöd.
Mir ist ein besseres Beispiel für ein Singleton 'eingefallen' :-) Die röm kath Kirche. Dort gibt es eine Klasse "Papst" (deren Objekte über spezielle Berechtigungen, Queries und Overruling-Capabilities), von der es zu jedem Zeitpunkt nur ein einziges Objekt geben soll. Wäre das Programm "Rom_Kath_Universum.EXE" von den 12 apostolischen Hackern in der Programmiersprache "Urbi et Orbi ++" geschrieben worden, dann hätten sie die Klasse "Papst" als Singleton ausgeführt und das ganze Gesocks mit Papst und Gegenpapst wäre dem Programmlauf erspart geblieben. :-)
Karl Heinz Buchegger schrieb: > dann hätten sie die Klasse "Papst" als Singleton ausgeführt > und das ganze Gesocks mit Papst und Gegenpapst wäre dem > Programmlauf erspart geblieben. Mit dem Ergebnis, dass der erste Papst auch der einzige geblieben wäre, da ein Singleton niemals "Garbagecollected" werden kann ;-) Siehe auch: http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
Läubi .. schrieb: > Karl Heinz Buchegger schrieb: >> dann hätten sie die Klasse "Papst" als Singleton ausgeführt >> und das ganze Gesocks mit Papst und Gegenpapst wäre dem >> Programmlauf erspart geblieben. > Mit dem Ergebnis, dass der erste Papst auch der einzige geblieben wäre, > da ein Singleton niemals "Garbagecollected" werden kann ;-) Aber es sagt ja keiner, dass ein Singleton Objekt nicht seine Member-Ausprägungen ändern kann. Die Klasse hätte einen Member Person. Und mittels SetPerson ändert man im Singleton von John-Paul auf Benedetto. Das Papst Objekt braucht nicht garbage collected werden (auch wenn das manchmal wünschenswert gewesen wäre).
Läubi .. schrieb: > Siehe auch: > http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/ Dem hab ich so nichts hinzuzufügen. In der Tat kämpfe ich in unserem Programmsystem genau mit solchen Problemen. Alles was der Autor dort beschreibt stimmt exakt genau so :-)
Karl Heinz Buchegger schrieb: > Die Klasse hätte einen Member Person. Und mittels SetPerson > ändert man im Singleton von John-Paul auf Benedetto. Also kann jeder (da Singleton Papst global) sich selbst (über SetPerson) zum Papst erheben evilgrin Karl Heinz Buchegger schrieb: > In der Tat kämpfe ich in unserem Programmsystem > genau mit solchen Problemen. Ich kenne das auch nur zu gut :-) C++?
Wenn man sich mal geeinigt hat was ein Singleton macht, und wofuer es gut ist... man implementiert es mit einer Semahore. Die wird bei der instantierung gesetzt, und nicht mehr losgelassen
Ha, gerade unterhalte ich mich mit jemandem darüber :-) Naja. Nun nimmt man noch die Thread-Sicherheit dazu und dann werden Singletons wahlweise langsam oder übelriechend.
Sven P. schrieb: > Ha, gerade unterhalte ich mich mit jemandem darüber :-) > > Naja. Nun nimmt man noch die Thread-Sicherheit dazu und dann werden > Singletons wahlweise langsam oder übelriechend. Zumindest geht es ohne Lock beim Erzeugen der Instanz, wenn die CPU so was wie CAS (68000er) oder CMPXCHG (x86) kennt (beide sind atomar)
Typisch sind Simgeltons bei GUI frameworks. Das Hauptfenster gibts nur ein einziges mal. Daher gibts dann so ziemlich überall ein "Hauptfensterklasse::getInstance()" oder der gleichen das dir dann einen pointer auf das hauptfenster zurückgibt. Sobald der 1. Aufruf kommt, wird das Objekt instanziert (was quasi das higlander-endgame wäre :). mit mutex/semaphore/... hat das wenig zu tun... gui-operationen sind oft eh nicht thread-safe. 73
>Singleton
früher hieß das mal "Globale Variable"
die sind aber BÖSE deshalb wurden sie (in der OO-Welt) umbenannt ;-)
In der Tat eignen sich Singletons dafür einen einfachen globalen Zugriff auf einmalige vorhandene Objekte zu ermöglichen, wie z.B. Hardwarekomponenten in einem System. Besser als globale Variablen sind sie alle Mal, da garantiert ist, dass nur eine Instanz einer Klasse erzeugt werden und diese auch nicht unbeasichtigt überschrieben werden kann.
Der eigentliche Vorteil ist, das man eine startup reihenfolge festelegen kann... bei globalen weis man nie welcher constructor wann aufgerufen wird (vor main ja, aber nicht welche reihenfolge) mit singeltons hat man dann den "vorteil" von globalen, und eine definierte startup reihenfolge. 73
Arc Net schrieb: > Zumindest geht es ohne Lock beim Erzeugen der Instanz, wenn die CPU so > was wie CAS (68000er) oder CMPXCHG (x86) kennt (beide sind atomar) Es geht überall, und wenn man künstlich eine Speicherbarriere einzieht. Das Problem daran: Man kann es in praktisch in keiner Programmiersprache formulieren, ohne dabei fiese Kniffe zu bemühen (Inline-Assembler usw.). In C++ könnte man Inline-ASM benutzen. In Java steht man ganz dumm da. Oder man müsste die ganze Routine aussperren (Mutex), dann wirds wieder fürchterlich ineffizient, denn das bringt jede Menge Pipeline-Hemmnisse mit. Abgesehen von den inhaltlichen Tabus, die man sich mit Singletons einhandelt: http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
Also für mich haben singletons auch immer etwas mit Konfigurationsmanagement zu tun. Dabei gibt es natürliche verschiedene gründe ein singleton zu verwenden. Die Gefahren werden ganz klar im Beitrag erklärt. Das daran die Klassen schuld sind, die singletons verwenden ist auch klar. Die schuld liegt natürlich am Programmierer der die Klasse gebaut hat. Wie mans richtig macht wird in der Diskussion zweifelsfrei dargestellt. Also sind singletons werden böse noch schwer zu verstehen. Der Programmierer ist also dafür verantwortlich es richtig zu machen, wie halt immer.
Hey Leuts, ich danke Euch für diese vielen Beiträge, die Vor- udn Nachteile und der Vergleich mit globalen Variablen. Ich hätte nicht gedacht, dass ich so viel zu meiner urpsrünglich kleinen Frage geschrieben wird.
Sven P. schrieb: > Arc Net schrieb: >> Zumindest geht es ohne Lock beim Erzeugen der Instanz, wenn die CPU so >> was wie CAS (68000er) oder CMPXCHG (x86) kennt (beide sind atomar) > Es geht überall, und wenn man künstlich eine Speicherbarriere einzieht. > > Das Problem daran: Man kann es in praktisch in keiner Programmiersprache > formulieren, ohne dabei fiese Kniffe zu bemühen (Inline-Assembler usw.). > In C++ könnte man Inline-ASM benutzen. Ist zwar immer noch Pointer gecaste... InterlockedCompareExchangePointer (seit wann es die Funktion gibt, keine Ahnung, die älteste hier noch verwendete WinBase.h ist von 1998 ;-)). http://msdn.microsoft.com/en-us/library/windows/desktop/ms683568(v=vs.85).aspx > In Java steht man ganz dumm da. Kein Kommentar ;-)
Anfaenger schrieb: > ich danke Euch für diese vielen Beiträge, die Vor- udn Nachteile und der > Vergleich mit globalen Variablen. Hallo, man könnte auch so formulieren: Singleton löst für Objekte ein Problem, dass es ohne die Objektorientierung nicht gäbe (nicht gegeben hat). Das Beispiel mit dem Drucker zeigt das recht schön, eine globale Variable Drucker leistet das Gleiche. Ich ziehe es aus Sicherheitsgründen auch weiterhin vor, funktionsentscheidende Daten wie die tatsächliche Position der Achse einer Werkzeugmaschine global und fix zu adressieren, auch in ansonsten voll objektorientierter Software. Gruss Reinhard
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.