nur 1 Instanz 1 Klasse --> static?

[-frank]

hi,
angenommen ich habe ein x-beliebiges programm, in dem es klassen gibt, von denen ich garantiert immer nur eine instanz brauche (auch bei eventuellen erweiterungen), auf die aber mehrere andere klassen zugreifen müssen.
zb die JDesktopPane des Hauptfensters einer GUI-Anwendung. wenn der user in anderen JComponents etwas tut, soll etwas in der JDesktopPane dargestellt werden (oder dergleichen).

bisher habe ich mir nie viele gedanken drüber gemacht, da ich einfach der anderen Klasse die Referenzen auf benötigte Klassen übergebe und damit hat sichs. wenn ich das obejtk in vielen konstruktoren drin hatte, wurde es mir aber zu blöd und ich hab die klasse static gemacht. nun wollte ich wissen, ob es sich in so einem fall immer anbietet, static objects zu verwenden, also mit klassen-variablen und methoden statt instanzvariablen. so muss man ja keine referenzen übergeben. oder gibt es spezielle situationen, wann man dies macht und wann doch?
wenn ich ein objekt habe, dessen referenz ich nicht weitergeben muss, das aber auch garantiert "allein" bleibt (also nur 1 instanzobjekt), macht ihr es dann static oder nicht?

danke!

 

[Reeny]

Ich mache auf jeden Fall alle Konstanten static. Ganze Konstanten-Sammlungen lege ich in einem Interface an

public interface Constants{
    public static final int RIGHT = 1;
    public static final int LEFT = 2;
    ...
}

Aber auch zum Beispiel ein Haupt-Programm-Fenster, damit ich leichter darauf zugreifen kann. Aber ich bezweifle, dass das wirklich guter Programmierstil ist. :?

 

[foobar]

@Reeny Das public final static kannst du dir in einem Interface sparen, denn diese Modifier werden automatisch gesetzt. Deshalb sind Interfaces ja so beliebt um darin Konstanten zu speichern ;-)

 

[Wildcard]

Nein, guter Stil ist es wirklich nicht.
Leichter Zugriff verführt dazu ein Objekt öfter zu benutzen als eigentlich notwendig. Bei Referenzen überlegt man sich schon eher ob man die wirklich durchschleifen muss.
Dabei entsteht eine ganze Reihe von dependencies die man praktisch nicht mehr aus dem Programm entfernen kann.
static sollte nur für Konstanten und Utility Klassen verwendet werden, während man zum Beispiel Factories häufig zu Singeltons macht.
Hier ist aber vorsicht geboten, das Singelton Pattern sollte sehr sehr sparsam verwendet werden.
Klassen auf die sich zu leicht zugreifen lässt tendieren dazu im laufe der Zeit aufgebläht zu werden, besonders wenn eine GUI im Spiel ist.
Insofern würde ich dir raten weiter Referenzen zu übergeben (aber nur wo das wirklich nötig ist) :wink:

 

[byte]

@Reeny Das public final static kannst du dir in einem Interface sparen, denn diese Modifier werden automatisch gesetzt. Deshalb sind Interfaces ja so beliebt um darin Konstanten zu speichern ;-)

Und man kann dann auch recht komfortabel die Konstanten bei Bedarf typisieren:

public interface Constant {

	public interface ConstantTypeA extends Constant {
		final int CONST_ONE = 1;
		final int CONST_TWO = 2;
	}
	
	public interface ConstantTypeB extends Constant {
		final int CONST_THREE = 3;
		final int CONST_FOUR = 4;
	}
	
}

bzw. mit SE5 auch:

public interface Constant {

	public enum ConstantTypeA implements Constant {
		CONST_ONE, CONST_TWO
	}
	
	public enum ConstantTypeB implements Constant {
		CONST_THREE, CONST_FOUR
	}
	
}

 

[André Uhres]

Eine interessante Alternative sind konstante Objekte

 

[AlArenal]

Eine interessante Alternative sind konstante Objekte

Im Grunde ein alter Hut, für den man nicht in die Ferne schweifen muss. Siehe auch java.util.Locale .

 

[André Uhres]

..Siehe auch java.util.Locale .

Da gibt's aber eine nicht unwesentliche Nuance: der Konstruktor von Country ist nämlich private, und nicht public wie bei Locale.

 

[byte]

Pre Java 5 sicher eine gute Sache. Jetzt würde ich aber Enums empfehlen. Damit kann man echt ne Menge anstellen.

Nur ein Beispiel:

TimeUnit.MILLISECONDS.sleep(100);

 

[AlArenal]

..Siehe auch java.util.Locale .

Da gibt's aber eine nicht unwesentliche Nuance: der Konstruktor von Country ist nämlich private, und nicht public wie bei Locale.

Motiv und Variation gibts nicht nur in der Musik

 

[André Uhres]

Pre Java 5 sicher eine gute Sache. Jetzt würde ich aber Enums empfehlen..

Ja, natürlich. Enums sind auch nichts anderes als eine Weiterentwicklung des Konzeptes der "konstanten Objekte".
Sozusagen ein "alter Hut" (AlArenal) in neuer Ausfertigung. Sie haben im Rahmen des Tigers viele Vorzüge:
sie sind einfacher zu deklarieren, man kann sie in switch Statements benutzen und im for-each Konstrukt,
sie implementieren das Comparable Interface...
Aber da hier im Forum von Einigen schon bemängelt wurde, daß zu sehr auf Java 5 gepocht wird,
der noch nicht überall verfügbar ist, ist der "Alte Hut" sicher immer noch aktuell und gegenüber weniger attraktiven
Lösungen in Erwägung zu ziehen.