Wann statische Methoden, statische Attributen?

[Guest]

Hallo,

wann benutzt man statische Methoden / Attributen?

 

[Tobias]

Wenn möglich: nie.

Es gibt natürlich ein paar Fälle, wo sie unumgänglich sind, zum Beispiel beim Singleton-Pattern oder als Factory-Methode. Darüberhinaus können sie ganz nützlich sein, wenn man nicht immer erst ein Objekt instanziieren möchte, um eine Methode oder ein Attribut zu benutzen - siehe Konstanten oder Utility-Klassen wie Math.

mpG
Tobias

 

[Marco13]

Statische Methoden: So oft wie möglich. Man könnte ganz pauschal sagen: Wenn ein Methode NICHT auf die Attribute einer Klasse zugreift, dann kann man sie statisch machen. ("Das kann nicht schaden"). Häufig ist das für kleine, praktische (häufig private) Utility-Funktionen sinnvoll.

Statische Attribute: So selten wie möglich. Es ist "fast nie" sinnvoll, ausser bei "public static final"-Konstanten.

Statische Klassen (Singletons) : So selten wie möglich. Häufig werden Singletons benutzt, obwohl kein wirklicher Grund dafür besteht. Der Grund, wesewegen sie oft verwendet werden ist, dass sie "so herrlich bequem" sind: Man kann von überall auf die Instanen zugreifen, und braucht sich keine Gedanken über eine vernünftige Programm- bzw. Klassenstruktur zu machen. Irgendwann rächt sich das dann aber in Unübersichtlichkeit und fehlender Wart- und Erweiterbarkeit des Programms.

 

[javaX]

statische methoden schreibe ich nur wenn ich keine objekte dieser klasse erstellen will.
alle verwendeten attribute dieser methode müssen auch statisch sein!

statische attribute sind an klassen und nicht an objekte gebunden.
wenn man zB einen array von objekten einer klasse hat braucht man bei statischen attributen nur bei einem object den wert ändern. er ändert sich bei allen objekten.
static wird oft im zusammenhang mit final verwendet;

 

[Guest]

könnt ihr mir hier einen Anwendungsfall aufzeigen, wo man statische Methoden / Attribute verwendet?

wenn ich das richtig verstanden habe, werden statische Attribute/Methoden verwendet, wenn man explizit keine Objekte dieser Klasse erstellen möchte.

 

[WieselAc]

Naja nicht so pauschal gehts wie fast immer nicht. Statische Methoden sind rein Funtionale ausgelegt.

Das heißt, um es mal konkret zu machen, du hast z.B. eine Klasse Punkt mit zwei Membern (x,y), dann kannst du dir entweder darin oder in einer separaten util Klasse verschiede funktionale Methoden für dieses Objekt definieren wie zu Beispiel:

public static Punkt sum(Punkt sum1, Punkt sum2){
    return new Punkt(sum1.getX() + sum2.getX(), sum1.getY()  + sum2.getY())

}

Ergänzung zu Member:

Statische Member werden meistens (fast ausschließlich) als Konstanten verwendet also

public static final ....

in dem Beispiel Punkt könnte man zum Beispiel den Mittelpunkt des KO so definieren:

public static final Punkt center = new Punkt(0,0);

....


public static double distance(Punkt p){
    int tmpX = center.getX() - p.getX();
    int tmpY = center.getY() - p.getY();
    return Math.sqrt(tmpX * tmpX + tmpY * tmpY);
}

 

[Leroy42]

du hast z.B. eine Klasse Punkt mit zwei Membern (x,y), dann kannst du dir entweder darin oder in einer separaten util Klasse verschiede funktionale Methoden für dieses Objekt definieren

Und genau in diesem Fall sollte man eben keine statischen Methoden sondern
Member-Methoden definieren.

public Punkt sum(Punkt sum2){ 
    return new Punkt(x + sum2.getX(), y  + sum2.getY()) ;
}

oder gleich

public Punkt sum(Punkt sum2){ 
    return new Punkt(x + sum2.x, y  + sum2.y) ;
}

 

[Lim_Dul]

Tendiell verwende ich statische Methoden/Klassen, wenn mein Programm nur einen Wert "transformieren" soll.

Also quasi Methoden, die aus einer Eingabe eine Ausgabe berechnen, die aber nicht der Eingabe oder Ausgabeklasse zuordnebar sind.

Ansonsten bei Klassen, die eine Art Singelton sind, weil ich die Einzigartigkeit brauche und es damals einfach war, die Klasse einfach statisch zu machen, als ein echtes Singelton zu implementieren.

Grundsätzlich bin ich aber mittlerweile der Ansicht, eher weniger als mehr static einzusetzen und finde auch nicht mehr alle Entscheiden, die ich mal getroffen habe, sinnvoll. In den seltensten Fällen braucht man es wirklich.