Noch eine Architekturfrage ;-)

[Roger Bieri]

Hallo,

Wie lässt sich im reinen OO von C# ein Singleton realisieren, also ein Objekt, das während der gesamten Laufzeit existiert.

Konkret: Die Daten des aktuellen Benutzers meines Programms.

In Delphi hatte ich sowas mit simplen globalen Variablen gelöst, gehandelt im initialization und finalization-Code.

Auch die 'AppSettings'-Klasse muss ja über eine Variable angesprochen werden, die irgendjemandem gehört. Das Main-Form finde ich nicht sehr gut, "zu hoch" in der Hierarchie, dann brauche ich gegenseitige Referenzen.

Im Grunde würde ich das irgendwo tief ansiedeln, damit auch die Problem DOmain-Object Zugriff drauf haben...

[Andreas Kosch]

Hallo,

in diesem Detail ist VB.NET näher am alten Delphi, denn in VB.NET kann anstelle einer Klasse ein <b>Module</b> deklariert werden. In Wirklichkeit sind die Module ebenfalls Klassen, der einzige Unterschied besteht darin, dass Module implizit nur aus <i>Shared Members</i> bestehen, so dass keine Instanz erzeugt werden muss. Aus diesem Grund arbeiten alle Programmteile immer mit der gleichen Modul-Instanz und somit mit den gleichen Daten (Variablen) aus diesem Modul.

In C# gibt es diese Bequemlichkeit nicht, hier müssen wir über das Schlüsselwort <b>static</b> eine gemeinsam zu nutzende Variable explizit kennzeichnen. Das folgende Beispiel verdeutlicht (hoffentlich) das Prinzip: <i><a href="/webx?13@@.4a870a72/1">Andreas Kosch "Zugriff auf Variablen" 01.07.2004 05:37</a></i>

Eine Singleton-Klasse kann in C# zum Beispiel so umgesetzt werden:
<pre>
<b>using</b> System;
<b>using</b> System.Diagnostics;
<br>
<b>namespace</b> SingletonKonstruktor
{
<b>public</b> <b>class</b> SingletonClass
{
<font color="#003399"><i>// Sperrobjekt für Multithread-Zugriffe</i></font>
<b>private</b> <b>static</b> <b>object</b> aLockObj = <b>new</b> <b>object</b>();
<font color="#003399"><i>// Ablageplatz für die Singleton-Instanz</i></font>
<b>private</b> <b>static</b> SingletonClass aInstance = <b>null</b>;
<br>
<b>private</b> SingletonClass()
{
<font color="#003399"><i>// Default-Constructor ist von außen nicht erreichbar</i></font>
Trace.WriteLine(<font color="#9933CC">&quot;SingleClass: Default-Constructor aufgerufen&quot;</font>);
}
<br>
<b>public</b> <b>static</b> SingletonClass GetSingletonInstance()
{
<b>lock</b>(aLockObj)
{
<b>if</b> (aInstance == <b>null</b>)
aInstance = <b>new</b> SingletonClass();
<b>return</b> aInstance;
}
}
}
}
</pre>
Die Nutzer dieser Klasse rufen über <i>SingletonClass.GetSingletonInstance();</i> die gemeinsam zu nutztende Instanz ab

[Roger Bieri]

Hallo Andreas

Du meinst also

1. Mit SingletonClass.GetSingleInstance() mir eine Referenz der (im Hintergrund) gemeinsamen Klasse in eine Variable holen....

2. Müssen nun Member-Eigenschaften oder gar Methoden dieser Klasse ebenfalls als static implementiert werden ?

3. Wer räumt die Sache auf ? die GC

[Andreas Kosch]

Hallo Roger,

an der Stelle hast Du die Wahl zwischen a) statisches Objektfeldern oder b) einer Singleton-Klasse. Da im Fall der Singleton-Klasse alle Nutzer garantiert die gleiche Instanz erhalten, können alle Nutzer der Klasse die gleichen Objektfelder (alias Member-Variablen) nutzen. Wenn es nur um wenige zu speichernde Werte geht, sollte static bequemer zum Ziel führen.

Da die Singleton-Klasse keine externen Ressourcen belegt, reicht in diesem Fall der GC beim Abräumen völlig aus

[Roger Bieri]

Danke
Funktioniert bestens ;-

[svepol]

Statische Objektfelder sind nur in einfachen Fällen sinnvoll.

Im Gegensatz zu Delphi ist es nicht möglich, einen Finalisierungscode anzugeben (statischer Destruktor). Darüberhinaus ist die "Freigabe" der Klassen nicht deterministisch, d.h. die Reihenfolge ist zufällig.

Gezielte Freigabe - etwa von Ressourcen - sind also nur mit Singleton-Objekten möglich. Sie sind daher in jedem Fall vorzuziehen