Statisches

[kowa]

Hallo,

ich weiss bereits was statisch heisst und wozu man es benutzt bei Variablen und Methoden, doch bei ganzen Klassen bin ich mir noch unsicher.

Man kann quasi die gesamte Klasse statisch machen, indem man verhindert, dass ein Objekt erstellt werden kann (privater Konstruktor). Dann ist es nur noch möglich die statischen Variablen und Methoden zu benutzen.

Wenn ich nun Klassen habe, bei denen ich ganz sicher sagen kann, dass ich immer nur eine Instanz davon brauche, ist es dann nicht sinnvoll diese Klasse auch komplett statisch zu machen?
Ein Beispiel:

public class StatusFenster {
	
	private static final long serialVersionUID = 1L;
	private static JLabel label = new JLabel();
	private static JFrame f = new JFrame();
	
	static {

		f.setResizable(false);
		f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		f.setTitle("Status");
		JPanel panel = new JPanel();
		
		panel.add(label);
		f.add(panel);
		
		f.pack();
		f.setLocationRelativeTo(null);
	}
	
        //Verhindert, dass ein Objekt von StatusFenster gebildet werden kann
	private StatusFenster(){}	
	
	
	public static void show(String text)
	{				
		label.setText(text);
		f.pack();
		f.setLocationRelativeTo(null);
		f.setVisible(true);		
	}
	

	public static void setText(String text)
	{
		label.setText(text);
		f.pack();
		f.setLocationRelativeTo(null);
		
	}
	
	public static void hide()
	{
		f.setVisible(false);
	}

}

Bei dieser Klasse rufe ich das Fenster einfach über show() auf und gebe einen Text mit. Dieses Fenster kommt immer nur alleine vor. Es gibt keine Kopien.

Ist es wie in diesem Beispiel sinnvoller lieber Objekte zu erstellen oder mit static zu arbeite? Ich habe auch Fenster, die der Benutzer nur einmal öffnen soll und da muss ich auch immer prüfen, ob das Fenster schon geöffnet wurde. Das könnte man ja statisch relativ leicht lösen, da es auch von überall aus zugänglich ist.

Oder gilt generell nicht static zu benutzen wenn es geht?

Danke!

 

[SlaterB]

generell statisch ist in einfachen Programmen nicht verkehrt,
und kann sich auch langfristig bewähren, siehe java.lang.Math,

in größeren Programmen hast du aber ein Problem, falls die Klasse irgendwann vielleicht nicht mehr statisch sein soll, um z.B. austauschbar zu sein,
Singleton ist dazu ein verwandes Thema, siehe Forumsuche,

es besteht also immer eine gewisse Gefahr, es irgendwann mal mit Aufwand umbauen zu müssen,
aber richtig schocken kann das natürlich auch nicht


Interface funktionieren nicht mit static, ein ActionListener kommt dafür also nie in Frage,
ebenso nichts, was je in einer Variablen gespeichert oder als Parameter übergeben werden muss

statt privaten Konstruktor kannst du die Klasse als abstract markieren, das ist noch etwas deutlicher

 

[Illuvatar]

statt privaten Konstruktor kannst du die Klasse als abstract markieren, das ist noch etwas deutlicher

Hm, ich finde aber "abstract" bedeutet: "Leite mich ab!" Und abstract final ist ja nicht möglich.
Klar, abstract mit private Konstruktor kann man auch nicht ableiten / instantiieren. Da bin ich dann aber eher dafür, final zu deklarieren.

 

[kowa]

Ich hab mich im Internet noch ein wenig weiter schlau gemacht.

Dabei habe ich auch ein paar deiner Argumente gefunden SlaterB. So wie ich das verstehe sollte man statische klassen hauptsächlich als "Hilfsklassen" nutzen so wie Webdienste, denen man eine Anfrage mit Parametern zusendet und eine Antwort zurückbekommt.

 

[Landei]

Für "statische Klassen" gelten im Prinzip die gleichen Kritikpunkte wie für Singletons.

Alex Miller - Patterns I Hate #1: Singleton

 

[bygones]

Für "statische Klassen" gelten im Prinzip die gleichen Kritikpunkte wie für Singletons.

Alex Miller - Patterns I Hate #1: Singleton

jein... statische Klassen bzw deren Methode am Ende des Objektbaums sind nicht so schwerwiegend - z.b. Math

problematisch wirds wenn man ueber Singletons oder sonstige statische Zugriffe sich mitten im baum befindet und die halbe Welt noch mit sich rumschleppt.

 

[tfa]

Das seh ich ähnlich. "Statische Klassen" sind dann in Ordnung, wenn sie wirklich nur Utility-Methoden besitzen und keinen inneren Zustand haben, d.h. es gibt keine Member- bzw. Klassen-Variablen. Dann gelten (die meisten) Singleton-Kritikpunkte nicht mehr.

 

[bygones]

Das seh ich ähnlich. "Statische Klassen" sind dann in Ordnung, wenn sie wirklich nur Utility-Methoden besitzen und keinen inneren Zustand haben, d.h. es gibt keine Member- bzw. Klassen-Variablen. Dann gelten (die meisten) Singleton-Kritikpunkte nicht mehr.

wenn sie aber noch einen wust an weitere Logik verbergen ist es ebenso problematisch... d.h. sie duerfen a) keine inneren Zustaende haben und b) keine weiteren statische / nicht statischen Kontext aufbauen

 

[tfa]

Einen "Wust an weiterer Logik" zu haben ist glaub ich in allen Situationen ein Nachteil, ob jetzt "statische" oder "normale" Klassen.

 

[bygones]

Einen "Wust an weiterer Logik" zu haben ist glaub ich in allen Situationen ein Nachteil, ob jetzt "statische" oder "normale" Klassen.

nicht ganz - vom Testaspekt ist ein nicht statischer "Wust" relativ unbedenklich, da man dies ausmocken kann. Nicht so bei einem statischen Kontext !

 

[tfa]

Achso, mit "statischem Kontext" meinst du festverdrahtete, wilde Methodenaufrufe statt gekapselte Objekte als Member-Variablen der Klasse (was wieder einen inneren Zustand bedeuten würde). Das man das nicht tut hatte ich vorausgesetzt. Andernfalls kann man gerne auch Singletons verwenden, dadurch würde es nicht schlimmer.

 

[bygones]

Das man das nicht tut hatte ich vorausgesetzt.

sag das mal dem Gross der Entwickler ;-)