Statische Klassen/ Singleton

[Semptic]

Wann sollte ich Statische Klassen benutzen?

Bei Klassen die nur eine Instanz haben werden, wie zum Beispiel bei dem Hauptfenster einer Anwendung?

Was sind die Vor- oder Nachteile von Statischen Klassen?

Ich würd sagen Statische Klassen sparen Rechenleistung und auch Speicher und daher sollte ich wenn möglich Statische benutzen, sicher bin ich mir da aber ganz und gar nicht.

 

[Der Müde Joe]

staische Klassen = ?

innere statische Klasse. oder meinst du Singleton?

 

[Semptic]

Ich mein eine Singleton.

 

[Der Müde Joe]

http://www.java-forum.org/softwareentwicklung/80674-singletons.html

 

[Semptic]

=> Am besten nicht benützen

 

[Gast2]

=> Am besten nicht benützen

Wieso?

Die Umfrage unterstützt doch eher:
[c]manchmal ein nützliches Entwurfsmuster. Ich setzte sie hin und wieder ein.[/c]

Wichtig ist halt wie und wann man ein Singelton einsetzt damit es z.B. kein Performance Flaschenhals wird.

 

[Semptic]

Schon, aber die Beiträge in den beiden Threads sagen eher aus das man sie am besten nicht hernimmt, weil es auch ohne geht und man sie so nicht Falsch verwenden kann.

Des einzige wo sich alle einig sind ist das es sinnvoll DI Frameworks (Spring) zu verwenden. Da hab ich aber garkeine Ahnung was des ist und wofür man des braucht bzw. wie man es verwendet. (Umsomehr ich hier im Forum les umso mehr Anfänger bin ich. ) Versuch da mal zumindest den groben überblick zu bekommen, aber man muss ja auch noch nebenher Studieren...^^

 

[maki]

Wichtig ist halt wie und wann man ein Singelton einsetzt damit es z.B. kein Performance Flaschenhals wird.

Naja... "statische" Singletons haben ein problematisches Design... da ist die Performancesache absolut untergeordnet

Semptic, hab keine Angst Singletons einzusetzen, solange du weisst dass es andere Alternativen gibt kannst du dir diese ja in Zukunft ansehen

 

[Gast2]

Ja richtig. Schlechtes Deisgn, miese Testbarkeit etc, kommt viel zusammen was gegen Singletons spricht. Habe extra geschrieben "z.B." Performance Falschenhals.

Performance hatte ich direkt erwähnt weil ich grade damit den Spaß hatte... Ein Singleton das jeden Zugriff in einem großen heavyload mulithreaded System abfrühstückte... Das Problem aufzulösen ohne zuviel umzureißen ist harte Arbeit...

Ich denke für manche Anwendungsfälle halt geeignet, man muss sich nur der Auswirkungen (Skalierbarkeit, Architektur des Gesamtsystems, Testbarkeit etc) bewusst sein wenn man das Pattern wählt.

 

[bygones]

solange man den Unterschied zwischen einer singelton Klasse und einem Singleton kennt ists in Ordnung.

Singleton zwingt sich seine "Einzigartigkeit" selbst auf - das beruehmte bsp mit einer statischen Variable und privaten Konstruktor... das sollte man nicht nutzen (siehe tausend argumentation hier und dort).
Das wuerde schon allein dem Single-Responsibilty widersprechen. Eine Klasse sollte nicht die Aufgabe haben sowohl ihr Erstellung, als auch ihre Logik zu verwalten.

In einer Applikation nur eine Instanz einer Klasse zu haben ist kein Problem - also eine singleton Klasse.

 

[maki]

Ja richtig. Schlechtes Deisgn, miese Testbarkeit etc, kommt viel zusammen was gegen Singletons spricht. Habe extra geschrieben "z.B." Performance Falschenhals.

Performance hatte ich direkt erwähnt weil ich grade damit den Spaß hatte... Ein Singleton das jeden Zugriff in einem großen heavyload mulithreaded System abfrühstückte... Das Problem aufzulösen ohne zuviel umzureißen ist harte Arbeit...

Ich denke für manche Anwendungsfälle halt geeignet, man muss sich nur der Auswirkungen (Skalierbarkeit, Architektur des Gesamtsystems, Testbarkeit etc) bewusst sein wenn man das Pattern wählt.

:toll:

 

[fastjack]

Eine interessante Sache, die ich mal gelesen habe, ist das Enum als Singleton. Hat natürlich auch Vor- und Nachteile. Allerdings sollen auf diese Weise die ganzen üblichen Singeleton-Späße wie double-checked und Co umschifft werden.
Persönlich mag ich die Singletons nicht besonders. Allerdings kenne ich einige Software-Architekten, die grundsätzlich alles in Singeltons verfrachten, totale Globalisierer eben, die ihren Ursprung noch im VB-Basic hatten und sich geistig noch in Subroutinen befinden, weil der return fehlte.

 

[maki]

Ja solche trifft man immer wieder
Für diejeniegen sind allerdings Dinge wie "wie initialisiere ich meine 18 Singletons die alle gegenseitig voneinander abhängig sind" das größte Problem

 

[fastjack]

18 geht ja noch. Am Ende hatten wir über 150 Klassen, die der gute Architekt zu Singletons verwandelte. Zugriff auf bestimmte Methoden regelte er über ThredLoacel und Reflections. Kurze Zeit später war er selber ein Singleton und wurde auf null gesetzt. :noe:

Seitdem gilt bei uns :

if (this instanceof SoftwareArchitect) {
    this.deleted = true;
    this.refresh();
}

:lol: