Singleton-Programmierung

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.

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++?

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.

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 ;-)