Noob Frage zu 'static class'

EXDW

Dravere schrieb:

CSL schrieb:

Das es n ctor gibt ist zwar schön und gut, den kann man aber nichts mit geben, den zugriff auf den Singleton könnte man so gestalten das man dem Ctor beim erstellen noch etwas geben kann.

Könnte, aber ob es sinnvoll ist? Da macht man lieber eine Init-Funktion, welche man in der main aufruft. Und das kann man auch für eine static class tun.

Solch eine Methode geht schon, nur ob das so praktisch ist?
Nehmen wir mmal als Beispiel eine Logging Singleton (Sinn und unsinn lassen wir mal bei Seite :D).
Da kann man nun erwarten das die log Datei dem Ctor übergeben wird. Man ist so dann sicher das es auf jeden fall aufgerufen wird, und auch nur einmalig. Eine Init Methode kann dies nicht bieten.

Dravere

CSL schrieb:

Da kann man nun erwarten das die log Datei dem Ctor übergeben wird. Man ist so dann sicher das es auf jeden fall aufgerufen wird, und auch nur einmalig. Eine Init Methode kann dies nicht bieten.

Und dann willst du ständig der Methode, welche das Objekt holt, den Namen des Logfiles mitgeben? Wie unglaublich mühsam! Und was passiert, wenn du dich einmal verschreibst und einen anderen Namen übergibst? Eine Init-Methode muss man nur einmal aufrufen und kann ihr alle benötigten Daten übergeben. Falls sie noch nicht aufgerufen wurde, könnten die Daten zwischenspeichert werden oder es wird eine Exception geworfen, was dir lieber ist.

Grüssli

Firefighter

Dravere schrieb:

Firefighter schrieb:

Aber ich finde man muss differenzieren.
Ein Singleton ist wie schon gesagt ein Software-Pattern. Eine Static-Class hingegeh ist ein Sprachliches Mittel was einem mehr oder weniger durch die Syntax der Sprache zur Verfügung gestellt wird.

Also wenn ein sprachliches Mittel zur Verfügung steht, ein Singleton zu erzeugen, dann ist das für dich kein Singleton?
Wenn wir also das static class durch folgendes ersetzen würden, nur um es ein wenig klarer zu machen:
public singleton class MySingleton
{
  // ...
}
Dann ist dies für dich kein Singleton? Wieso darf eine Sprache nicht eine Syntax zur Verfügung stellen, um ein Software-Pattern einfach umzusetzen?

Grüssli

Ok das is ne Interessante Argumentation, da geb ich dir dann jetzt im Nachhinein Recht.
Für mich bleibt aber bestehen das es nur sehr nahe dran kommt, aber ein Singleton halt ein Objekt zur Verfügung stellt und die static-Class nicht.

EXDW

Gerade gefunden:
http://dotnetperls.com/singleton-static
Besonders interessant dabei die Advantages of singletons. (Wenns auch sehr wenig ist)

Dravere

Firefighter schrieb:

Für mich bleibt aber bestehen das es nur sehr nahe dran kommt, aber ein Singleton halt ein Objekt zur Verfügung stellt und die static-Class nicht.

Könnte man nicht auch die Klasse selbst als Objekt verstehen?

CSL schrieb:

Gerade gefunden:
http://dotnetperls.com/singleton-static
Besonders interessant dabei die Advantages of singletons. (Wenns auch sehr wenig ist)

Wenig ist gut, grundsätzlich ist es nur ein Vorteil, den ich schon genannt hatte: Vererbung.

Grüssli

Firefighter

Hmm Ich weiß nich genau Dravere. Ist ne gewagte Aussage. Weil wenn dem so wäre könnte man ja dieses "Objekt" an eine Funktion übergeben um damit zu arbeiten. Ist ja bei Static-Klassen nicht möglich.

Ein großer Unterschied der hier noch nicht erwähnt wurde ist auch die Lebenszeit von den Variablen in der Klasse.
Die Lebenszeit bei einem Singelton endet wenn das Objekt zerstört wird.
Wie sieht es bei statischen Variblen aus? Welche Lebenszeit haben sie? Bleiben sie irgendwo als Last im Speicher solange das Programm läuft?

Dravere

Firefighter schrieb:

Hmm Ich weiß nich genau Dravere. Ist ne gewagte Aussage. Weil wenn dem so wäre könnte man ja dieses "Objekt" an eine Funktion übergeben um damit zu arbeiten. Ist ja bei Static-Klassen nicht möglich.

Wer sagt, dass ein Objekt an eine Funktion übergeben werden können muss? Ich habe hier keine Defintion des Singleton-Pattern zur Hand, aber wird dort das Objekt so definiert? Würde mich doch sehr erstaunen.
Allenfalls könnte man dann argumentieren, weil es global verfügbar ist, wird es indirekt auch jeder Funktion übergeben. Sicher wieder eine gewagte Aussage

Aber grundsätzlich ist alles weitere auch etwas egal. Mir ging es nur darum, dass man sich darüber ein paar Gedanken macht. Mal die beiden Lösungen miteinander vergleicht und auch davon abkommt, es einfach als Blödsinn abzustempeln. Nicht einfach irgendwelche pauschalen Aussagen stehen zu lassen, sondern Argumente hervorkramt. Ich bin daher mit dem Resultat der Diskussion bereits sehr zufrieden

Niggelchen schrieb:

Ein großer Unterschied der hier noch nicht erwähnt wurde ist auch die Lebenszeit von den Variablen in der Klasse.
Die Lebenszeit bei einem Singelton endet wenn das Objekt zerstört wird.
Wie sieht es bei statischen Variblen aus? Welche Lebenszeit haben sie? Bleiben sie irgendwo als Last im Speicher solange das Programm läuft?

Und wann wird das Objekt in C# zerstört? Erst recht bei einem Singleton? In C# sehe ich da keinen grossen Unterschied. In einer Sprache wie C++ mag das sicher anders aussehen. Aber auch dort hat ein Singleton oft eine Lebensdauer durch das ganze Programm durch.

Grüssli

Dravere schrieb:

Firefighter schrieb:

Hmm Ich weiß nich genau Dravere. Ist ne gewagte Aussage. Weil wenn dem so wäre könnte man ja dieses "Objekt" an eine Funktion übergeben um damit zu arbeiten. Ist ja bei Static-Klassen nicht möglich.

Wer sagt, dass ein Objekt an eine Funktion übergeben werden können muss? Ich habe hier keine Defintion des Singleton-Pattern zur Hand, aber wird dort das Objekt so definiert? Würde mich doch sehr erstaunen.

"Sichere ab, daß eine Klasse genau ein Exemplar [Instance] besitzt, und stelle einen globalen Zugriffspunkt darauf bereit."

Die Idee, eine Klasse mit nur statischen Membern als Singleton zu bezeichnen ist völlig abwegig, ja sogar als Blödsinn abstempelwürdig.

Zudem ist das Singleton ein Entwurfsmuster in der Objektorientierten Programmierung, eine "static class" ist schonmal inhärent kein Part eines OO Systems.

Singletons sind übrigens unheimlich schlechter Stil und zu vermeiden wo es geht und sollte man sich als Anfänger gar nicht erst angewöhnen. Lieber auf DI o.Ä. ausweichen.

Einen kurzen crashkurs in "Lebenszeiten von Variablen":
lokale Variable: destruktor wird aufgerufen (zerstört) wenn die Funktion endet. Die destruktoren hängen also meist an der schliessenden geschweiften Klammer "}"
Bsp:
for (int i = 0; i < array.length(); i++) //Aufruf Konstruktor von i
{
...
} // Aufruf Destruktor von i (i wird zerstört); Speicherplatz wird freigegeben

Klassenvariable:
Bsp:
class A
{
...
};
void f()
{
A a; // Konstruktor von A wird aufgerufen (Speicherplatz reserviert und eventuell beschrieben)
...
};// Destruktor aufruf von A Speicherplatz wird freigegeben.

In größeren Projekten hat man öfters das Klassen aus 20 Strings, 20 ints und sogar verschieden andere complexen typen bestehen (arrays, class, struct ...) So dass ein Objekt locker mal 100 bytes oder mehr reserviert. Wenn man nun so eine Klasse hat und will dass nur ein Objekt gleichzeitig erzeugt und verändert werden kann ist natürlich ein Singelton eine sehr gute Wahl. Bei einer statischen klasse hat man die ganze zeit diesen Speicherplatz verlust weil der Speicher während der gesamten main reserviert bleibt.

asdghi123nbfaj schrieb:

Singletons sind übrigens unheimlich schlechter Stil und zu vermeiden wo es geht und sollte man sich als Anfänger gar nicht erst angewöhnen. Lieber auf DI o.Ä. ausweichen.

Dazu muss ich sagen. Singelton haben ihre berechtigung und gehören nicht zum schlechten Stil "in c++", vorausgesetzt man arbeitet nicht nur mit Zeigern was ich gerne mache. Aber manch andere verstehen dann nicht mehr was man tut so dass man die Wartung und für Fehlerkorrekturen durch andere vergessen kann.

Was du mit DI meinst ist mir ein Rätsel. Wenn man aber mit mehreren Leuten an einem Projekt arbeitet ist singelton sinnvoll, weil dadurch sichergestellt wird dass deine Klasse nicht aus versehen von jemand anderem gleichzeitig benutzt wird. Was dir bei statischen Klassen nicht zugesichert werden kann.

Dravere

@Niggelchen,
Einen kurzen Crashkurs in "Wo im Forum befindet ich mich?":
Dazu schaust du am besten oben über den Themen hin. Dort steht nämlich "C/C++ Forum :: C# und .NET :: Noob Frage zu 'static class'". Wir sind hier also im C# Forum! In C# ist der Destruktoraufruf nicht deterministisch.

Zusätzlich auch in C++, wenn du das Meyers-Singleton verwendest, besteht das Objekt spätestens ab dem ersten Abruf bis zum Programmende, da es ein statisches lokales Objekt ist.

Und ein Singleton schützt nicht vor simultanem Zugriff, da verwechselst du irgendetwas, schliesslich greifen eben alle auf das gleiche einzelne Objekt zu. Und dieser Zugriff kann man nur mühsam schützen. Da kann man auch in den statischen Methoden eine Mutex verwenden.

@asdghi123nbfaj,
Lies die Diskussion oder troll wo anders.

Grüssli

Niggelchen schrieb:

asdghi123nbfaj schrieb:

Singletons sind übrigens unheimlich schlechter Stil und zu vermeiden wo es geht und sollte man sich als Anfänger gar nicht erst angewöhnen. Lieber auf DI o.Ä. ausweichen.

Dazu muss ich sagen. Singelton haben ihre berechtigung und gehören nicht zum schlechten Stil "in c++", vorausgesetzt man arbeitet nicht nur mit Zeigern was ich gerne mache. Aber manch andere verstehen dann nicht mehr was man tut so dass man die Wartung und für Fehlerkorrekturen durch andere vergessen kann.

Was du mit DI meinst ist mir ein Rätsel. Wenn man aber mit mehreren Leuten an einem Projekt arbeitet ist singelton sinnvoll, weil dadurch sichergestellt wird dass deine Klasse nicht aus versehen von jemand anderem gleichzeitig benutzt wird. Was dir bei statischen Klassen nicht zugesichert werden kann.

In welcher Sprache man arbeitet ist eigentlich irrelevant, Singletons sind nicht nur in Java und C# schlechter Stil, auch in C++ und allen anderen Sprachen. Dein Einwand vonwegen "gleichzeitig benutzen" (meinst du gleichzeitig mehrere Instanzen instantiieren?) ist übrigens hinfällig, Singletons kann ich natürlich genauso 'gleichzeitig' wie statische Klassen verwenden. Als Alternative wie gesagt DI (= Dependency Injection...)

@Dravere: Ganz schön erwachsene Antwort, aber wenn du sonst nichts beizutragen hast mach nicht einen auf reg-troll.

inflames2k

Ich stell mir auch gerade die Frage an welcher Stelle Singletons schlechter Stil sind. - In jedem Buch über Design Patterns werden sie vorgestellt (was jetzt nicht heißt, dass dies besagt es sei guter Stil).

Aber es gibt einige Anwendungsfälle in denen Singletons doch ihre Berechtigung haben und vorallem der beste und sauberste Lösungsweg sind.

Klar kann ich statts der Singletons auch Static klassen definieren, aber das wiederum wäre eher der schlechte Stil. - Singletons werden erst dann erzeugt wenn ich sie das erste mal brauche, wie es hier bereits auch gesagt wurde.

Ein möglicher Anwendungsfall wäre Beispielsweise Remoting. Wenn ich Zugriff auf eine Bestimmte Klasse so gestalten möchte, dass jeder Remoting Client auf die selbe Instanz zugreift ist und bleibt Singleton meine erste Wahl, da ich so sicher gehen kann dass es auch wirklich die gleiche Instanz ist. Das wäre zwar nur meine Vorgehensweise aber aus meiner Sicht ist daran nichts unsauber.

Dravere

inflames2k schrieb:

Klar kann ich statts der Singletons auch Static klassen definieren, aber das wiederum wäre eher der schlechte Stil. - Singletons werden erst dann erzeugt wenn ich sie das erste mal brauche, wie es hier bereits auch gesagt wurde.

Wieso wäre es der schlechte Stil?
Auch ein Singleton über static class kann verzögert geladen werden. In C# haben wir sowieso kaum grössere Objekte als irgendwelche Referenzen. Und ein paar Referenzen allenfalls auf null zu belassen und später dann laden, ist wirklich nicht alle Welt. Auch muss ein static Konstruktor nicht bei Programmstart aufgerufen werden. Dies kann durchaus auch erst passieren, wenn die Klasse und somit das Singleton zum ersten Mal verwendet wird.
Und ganz am Ende stellt sich noch eine Frage. Spielt sowas überhaupt eine Rolle? Gibt es Programme, welche ausgeführt werden und wo das Objekt am Ende gar nie erstellt wird?

Ich will ja nicht, dass man Singletons durch static class ersetzt. Aber es gibt unterschiedliche Singleton-Umsetzungen und wieso nicht static class als eine davon ansehen?

Diese pure Ablehnung erscheint mir einfach wie das reinste Tunneldenken.

Grüssli

Zeus

Dravere schrieb:

Diese pure Ablehnung erscheint mir einfach wie das reinste Tunneldenken.

Besonders weil es Programmiersprache gibst, die direkt Singletons als Sprachmittel unterstützen, kann es nicht schlecht sein.

inflames2k

Ich wollt mit meiner Aussage nicht ausdrücken dass static class schlechter Stil ist zumindest nicht so direkt wie es aufgefasst wurde, sondern dass hier in den meißten Fällen ein einfacher Singleton vorzuziehen wäre.

Auch ich nutze ab und an reine static Klassen. Bietet sich halt in einigen Fällen auch mal an.

Verteufeln kann man alles, irgendwann kommt man auf einen Anwendungsfall, wo das was man verteufelt hat die beste Lösung wäre.

Im Grunde genommen ist das aber kein Thema wo man nun ewig drüber debattieren muss, also steig ich hier aus der Diskussion aus.