Praktische Anwendung von Singleton?
Jens Werner
benutzt das irgend jemand und wofür?
gruss Jens
Martin Kaul
> Wo wendet man den praktischerweise das SingletonPattern an?
> benutzt das irgend jemand und wofür?
Ich benutze das Pattern hauptsächlich für globale Verwaltungsklassen
(z.B. Fehler-Manager, Diagnose-Manager). Ohne das Pattern müssten die
einzige Instanz dieser Klassen überall durch ein Argument (z.B. bei
Methoden oder Konstruktoren von Klassen welche diese Verwalter
verwenden) übergeben werden.
tschaule
Martin
Niels Braczek
> Wo wendet man den praktischerweise das SingletonPattern an?
> benutzt das irgend jemand und wofür?
Das Singleton brauchst du für Alles, wovon du das Original brauchst.
Typisch dafür ist die Datenbankverbindung, das Übersetzungsmodul, die
Registry ...
MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · E-Commerce · Mambo Content Management |
----------------------------------------------------------------
Dirk Thierbach
> Wo wendet man den praktischerweise das SingletonPattern an?
Die Anwendungsbeispiele stehen doch normalerweise bei den Pattern
dabei, oder?
Man wendet es an, wenn man eine einzige globale Instanz braucht,
die moeglicherweise verzoegert initialisiert wird. Also im Prinzip
ueberall da, wo man sonst globale Variablen benutzen muesste.
> benutzt das irgend jemand und wofür?
Ich, dauernd, z.B. um auf Konfigurationsdateien zuzugreifen.
- Dirk
Jens Werner
> dabei, oder?
Natürlich, da steht: immer da wo man nur eine Instanz zulassen will :-)
> Man wendet es an, wenn man eine einzige globale Instanz braucht,
> die moeglicherweise verzoegert initialisiert wird. Also im Prinzip
Gut, hätte ich fragen müssen: Praktische Anwendung einer globalen
Instanz...?
> Ich, dauernd, z.B. um auf Konfigurationsdateien zuzugreifen.
Das ist doch schon mal eine Anwendung :-)
André Löffler
Programm darzustellen. Um alle Objekte einer bestimmten Entity-Klasse zu
verwalten, setze ich für jede Entityklasse eine Ordnerklasse ein.
Während des Programmablaufes darf zu jeder Ordnerklasse und zu jedem
Zeitpunkt höchstens ein Ordnerobjekt existieren. Meine Ordnerklassen bzw.
die daraus erzeugten Objekte sind daher Einzelstücke, die ich nach dem
Singletonmuster verwalte.
Gruß André
Matthew Bakre
"André Löffler" <AndreL...@freenet.de> schrieb im Newsbeitrag
news:442d9946$0$10255$9b62...@news.freenet.de...
>[...] Um alle Objekte einer bestimmten Entity-Klasse zu
> verwalten, setze ich für jede Entityklasse eine Ordnerklasse ein.
> Während des Programmablaufes darf zu jeder Ordnerklasse und zu jedem
> Zeitpunkt höchstens ein Ordnerobjekt existieren.
aus meinem bisherigen Verständnis von OOP und Java heraus würde ich für so
eine Aufgabe zuerst an statische Methoden und statische Attribute denken.
Welchen Vorteil bringt hier ein Singleton?
Matt
Dirk Thierbach
Statischen Methoden/Attribute sind eine Moeglichkeit, Singletons in
einer konkreten Sprache zu implementieren, aber nicht die einzige. In
Eiffel gibt es z.B. keine statischen Methoden/Attribute, dafuer kann
man Singletons direkt erzeugen.
> Welchen Vorteil bringt hier ein Singleton?
Es liegt eine Abstraktionsebene hoeher als statische Methoden/Attribute.
- DIrk
Torsten Robitzki
>
>
> Es liegt eine Abstraktionsebene hoeher als statische Methoden/Attribute.
ist das schon ein Vorteil?
mfg Torsten
Konni Scheller
> > Es liegt eine Abstraktionsebene hoeher als statische Methoden/Attribute.
>
> ist das schon ein Vorteil?
Ja.
Beispielsweise könnte man nachträglich das Singleton durch etwas anderes
austauschen, ohne dass der restliche Code geändert werden muss.
Wie immer, wenn man eine Ebene höher geht, wird das Ganze flexibler
(d.h., so sollte es sein ;-).
Servus,
Konni
--
Warum ich privat versichert bin und der Sozialversichung den Rücken
gekehrt habe:
http://www.roterochs.de/ueberuns/private-krankenversicherung.html
Torsten Robitzki
> Torsten Robitzki <MyFir...@Robitzki.de> wrote:
>
>
>>>Es liegt eine Abstraktionsebene hoeher als statische Methoden/Attribute.
>>
>>ist das schon ein Vorteil?
>
>
> Ja.
Hm, es macht das Interface meist auch komplizierter.
Timer::instance().schedule(work, time) ist halt komplizierter als
Timer::schedule(work, time).
> Beispielsweise könnte man nachträglich das Singleton durch etwas anderes
> austauschen, ohne dass der restliche Code geändert werden muss.
Und eine statische Funktion kann man nicht mehr ändern? Entscheidend ist
doch das Interface. Ein Singleton ist für mich bereits ein
Implementierungsdetail.
> Wie immer, wenn man eine Ebene höher geht, wird das Ganze flexibler
> (d.h., so sollte es sein ;-).
Hm, flexibler ist besser? ;-)
mfg Torsten
Dirk Thierbach
Trivialer Vorteil: Du kannst Singletons auch in Sprachen implementieren,
die diese "statischen" Ueberbleibsel von Fortran nicht mehr haben.
Weniger trivialer Vorteil: Wie immer, wenn man Pattern benutzt,
betrachtet man das ganze unter einem allgemeineren Gesichtspunkt.
Das fuehrt oft ganz von selbst zu einfacheren und uebersichtlicheren
Loesungen. Mit statischen Variablen kann man eine Menge Murks machen,
mit einem Singleton ist der Anwendungszweck offensichtlicher, deshalb
ist muss man sich da schon mehr anstrengen, um sich selbst ins Knie
zu schiessen.
- Dirk
Dirk Thierbach
> Hm, es macht das Interface meist auch komplizierter.
> Timer::instance().schedule(work, time) ist halt komplizierter als
> Timer::schedule(work, time).
Das ist erstens Sprachabhaengig, und zweitens sollte man das Singleton
sowieso einer Variable zuweisen.
> Und eine statische Funktion kann man nicht mehr ändern? Entscheidend ist
> doch das Interface. Ein Singleton ist für mich bereits ein
> Implementierungsdetail.
Andersherum denken. Singleton ist das Interface. Ob man es nun mit
statischen Feldern implementiert oder irgendwie anders (sprachabhaengig),
ist das Implementierungsdetail.
Es hilft, wenn man ausser Java noch andere Sprachen kennt.
- Dirk
Torsten Robitzki
> Torsten Robitzki <MyFir...@robitzki.de> wrote:
>
>>Hm, es macht das Interface meist auch komplizierter.
>
> Andersherum denken. Singleton ist das Interface. Ob man es nun mit
> statischen Feldern implementiert oder irgendwie anders (sprachabhaengig),
> ist das Implementierungsdetail.
Dann nimm halt irgend eine Sprache Deiner Wahl und zeig doch bitte mal
ein Beispiel, bei dem ein Singleton dem Anwender das Leben einfacher macht.
> Es hilft, wenn man ausser Java noch andere Sprachen kennt.
Blöde Retorik; was möchtest Du mir damit sagen?
mfg Torsten
Dirk Thierbach
> Dirk Thierbach wrote:
>> Torsten Robitzki <MyFir...@robitzki.de> wrote:
>>>Hm, es macht das Interface meist auch komplizierter.
>> Andersherum denken. Singleton ist das Interface. Ob man es nun mit
>> statischen Feldern implementiert oder irgendwie anders (sprachabhaengig),
>> ist das Implementierungsdetail.
> Dann nimm halt irgend eine Sprache Deiner Wahl und zeig doch bitte mal
> ein Beispiel, bei dem ein Singleton dem Anwender das Leben einfacher macht.
Es geht nicht um "das Leben einfacher machen". Da man Singletons mit
statischen Attributen implementieren kann, ist das Leben mit statischen
Attributen "genauso einfach" wie mit direkt implementierten Singletons.
(Es ist ein bisschen umstaendlicher, wie Du gesagt hast, da die Syntax
ein kleines bisschen aufwendiger ist. Aber das kann man vernachlaessigen).
Es geht darum, in abstrakteren Konzepten zu denken.
Versuch eines Vergleichs (ja, der hinkt, wie alle Vergleiche):
Du brauchst fuer irgendeine Aufgabe einen Stack. Jetzt kommt einer
an und sagt "ja, das ist doch nur eine verkettete Liste. Wieso macht
mir denn der Stack gegenueber der verketteten Liste das Leben einfacher?".
>> Es hilft, wenn man ausser Java noch andere Sprachen kennt.
> Blöde Retorik; was möchtest Du mir damit sagen?
Es war nicht als bloede Rhetorik gedacht. Wenn Du nur Java kennst,
denkst Du in statischen Attributen, weil Du nie etwas anderes gesehen
hast. Da dann ein Singleton eh nur ein statisches Attribut ist, ist
es schwierig, den Unterschied zu sehen. Das kann ich voellig
nachvollziehen.
Wenn man aber mal ein paar Sprachen gesehen hat, wo das anders geloest
ist (Eiffel, Smalltalk) versteht man den Unterschied viel besser.
- Dirk
Torsten Robitzki
Stefan Ram wrote:
> Dirk Thierbach <dthie...@usenet.arcornews.de> writes:
>
>>Wenn Du nur Java kennst, denkst Du in statischen Attributen,
>>weil Du nie etwas anderes gesehen hast.
>
>
> Jemand, der Java kennt, hat nie etwas anderes als statische
> Attribute gesehen?
>
> Jedenfalls wird jemand, der nur Java kennt, einsehen, daß er
> bei der Implementation eines einmaligen Exemplars als eine
> Klasse, also durch statische Methoden und Felder
>
> - keine Schnittstellen im Sinne der Programmiersprache
> Java implementieren kann,
>
> - keine Referenz auf das einmalige Exemplar an andere
> Methoden übergeben kann (etwa an Testmethoden) und
>
> - weniger Kontrolle über den genauen Zeitpunkt der
> Initialisierung des einmaligen Exemplars hat.
Na, das sind doch wirklich mal konkrete Vorteile eines Singletons
gegenüber statischen Funktionen und Attributen die weit über
"abstrakter" und "flexibler" hinaus gehen ;-)
Die ersten beiden Punkte erscheinen mir sehr ähnlich. Mit Adaptern
könnte man eine Sammlung von Funktionen auch eine Schnittstelle im Sinne
der Programmiersprache Java geben (für C++, Ruby und Delphi funktioniert
das natürlich auch ;-). Wenn ich das aber wirklich brauche, liegt eine
Implementierung als Singleton natürlich nahe, dann müste die
Schnittstelle aber immer noch nicht direkt der Singleton sein.
Den letzten Punkt kann man für eine statische Funktion auch nachrüsten,
ohne dabei die Schnittstelle ändern zu müssen (sprich einen Singleton
als Implementierung).
mfg