Noob Frage zu 'static class'

Firefighter

O.o schrieb:

Bei statischen Klassen handelt es sich um Singletons.

Was issen das fürn Blödsinn?
Ein Singleton impliziert doch das ein,und zwar nur EINS, Objekt erstellt werden kann.
Aus statischen klassen kann kein Objekt erzeugt werden, schließlich sind sie ja statisch.

LordJaxom

Firefighter schrieb:

Was issen das fürn Blödsinn?
Ein Singleton impliziert doch das ein,und zwar nur EINS, Objekt erstellt werden kann.
Aus statischen klassen kann kein Objekt erzeugt werden, schließlich sind sie ja statisch.

Im Wortsinne handelt es sich nicht um Singletons, aber technisch ist der Vergleich IMHO garnicht so verkehrt.

Singletons existieren genau einmal, und werden meist beim ersten Anfordern der Instanz erzeugt.

(Statische) Membervariablen einer statischen Klasse existieren auch genau einmal, und der statische Konstruktor wird auch beim ersten Aufruf einer Funktion der statischen Klasse aufgerufen.

Firefighter

Ja klar, wenn man es so vergleicht.
Technisch gesehen ist das eine aber ein Objekt und das andere nicht.

EXDW

Auch der zugriff ist unterschiedlich.
Wärend man bei einem Singleton über eine erstellte instanz geht
Bla.Instance.Method
Greift man bei Statischen direkt zu
Bla.Method

-> Singleton ist auch nur ein Pattern was sich ausgeprägt hat da Statische Klassen nicht immer aus reichen.

Dravere

CSL schrieb:

-> Singleton ist auch nur ein Pattern was sich ausgeprägt hat da Statische Klassen nicht immer aus reichen.

Ist korrekt, wäre jetzt aber noch gut, wenn du den Gedanken zu Ende geführt hättest. Wenn wir uns zum Beispiel C++ anschauen, dann ist dort das Singleton Pattern von grossem Vorteil, weil man dann einen Konstruktor erhält. In C# dagegen hast du den static Konstruktor bereits. Die Reihenfolge der Destruktion ist in C# auch nicht sonderlich wichtig, muss man somit auch nicht steuern. Ich sehe ehrlich gesagt aktuell nur noch einen einzigen Nachteil, man hat keine Vererbung mehr. Man kann somit nicht so Dinge wie INotifyPropertyChanged verwenden. Die static class von C# kommt dem Singleton Pattern schon verdammt nahe.

Also einfach als Blödsinn abstempeln, würde ich das nicht.

Grüssli

Firefighter

Ok vielleicht nicht Blödsinn.
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.

Dravere

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

EXDW

Dravere schrieb:

... dort das Singleton Pattern von grossem Vorteil, weil man dann einen Konstruktor erhält. In C# dagegen hast du den static Konstruktor bereits....

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.

Dravere schrieb:

Also einfach als Blödsinn abstempeln, würde ich das nicht.

Verwechsel mich bitte nicht

Dravere schrieb:

Die static class von C# kommt dem Singleton Pattern schon verdammt nahe.

Korrekt, aber eben nur sehr nahe, ne daseinsberechtigung haben beide Varianten weiterhin.

Dravere

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.

CSL schrieb:

Korrekt, aber eben nur sehr nahe, ne daseinsberechtigung haben beide Varianten weiterhin.

Ich habe nie behauptet, dass es die Daseinsberechtigung von einer Lösung verbietet. Aber einfache Singletons, würde ich mir durchaus überlegen, mit einer static class umzusetzen. Weshalb ich der Meinung bin, dass man das Singleton Pattern nicht zu eng sehen sollte. Je nach Sprache gibt es eben unterschiedliche Möglichkeiten ein Singleton umzusetzen.

CSL schrieb:

Dravere schrieb:

Also einfach als Blödsinn abstempeln, würde ich das nicht.

Verwechsel mich bitte nicht

Keine Angst
Das war ganz allgemein gemeint und einfach an das "gegnerische" Lager gerichtet

Grüssli

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