Statische Methoden

[M4D-M4X]

Hi Leute,

könnt ihr mir vllt. genau erklären wofür man statische Methoden braucht, bzw. wie das genau funktioniert?
Das Tutorial hier im Forum aus dem Forum und die Beschreibung im Openbook hab ich auch schon gelesen.

Das einzige was ich davon jetzt mitgenommen habe ist, dass statische Methoden nicht über Instanzen aufgerufen werden, sondern direkt und dies kann überall im Programm geschehen, aber das kann doch noch nicht alles sein oder?

Jetzt ist meine Frage, man kann statische Methoden doch nicht überall aufrufen oder? Habs grad selber probiert mit 2 Klassen aber hat nicht wirklich hingehauen.

Bitte erklärt es mir

 

[XHelp]

Wie hast du es probiert? Statische Methoden kannst du auch über die Instanzen aufrufen.
Und überall im Programm... hmmm... du kannst auch

private static

machen, dann kannst du die nicht überall aufrufen.

 

[nrg]

Stell dir deine Klasse vor wie ein Stempel. Alles was nicht statisch ist, wird abgestempelt. D.h. du erzeugst eine Instanz mit new DeineKlasse() und bekommst in dieser Instanz alles was nicht statisch ist. Alles statische gibt es nur ein einziges mal in deiner Klasse. D.h. alle Instanzen deiner Klasse (ob das nun eine oder 100 sind) haben die gleichen statischen Methoden und Attribute!

public class Test {
	
	static int statisch;
	int nichtStatisch;
	
	public Test() {
		statisch++;
		nichtStatisch++;
	}
	
	public static void main(String[] args) {
		Test t1 = new Test();
		Test t2 = new Test();
		
		System.out.println(t1.nichtStatisch);		// 1, weil Inszanzvariable
		System.out.println(t2.nichtStatisch);		// 1, weil Instanzvariable
		System.out.println(Test.statisch);			// 2, weil 2x instanziiert
		System.out.println(Test.nichtStatisch);  	// Geht nicht - MUSS instanziiert werden
	}
}

 

[XHelp]

dafür geht aber:

System.out.println(t1.statisch);

Hat aber immer noch den Wert von 2.

 

[nrg]

sollte man aber nicht machen

 

[Michael...]

Jetzt ist meine Frage, man kann statische Methoden doch nicht überall aufrufen oder?

Grundsätzlich schon, ausser sie sind private.

Abgesehen davon, dass man versuchen sollte statische Methoden zu vermeiden. Setze ich sie als "Funktionen" ein - die also nichts mit einem Objekt zu tun haben. Ähnlich wie die Methoden der Klasse Math

 

[nrg]

Also ich wüsste nicht, warum man statische Methoden vermeiden sollte. Utility (z.B. Math) bzw. Klassen, die nur eine Definition haben (Locale, Configs) halte ich schon für sinnvoll statisch und abstrakt zu halten. Oder kannst du deine Aussage präzisieren?
Ist halt vorteilhaft, weil man dadurch irgendwo den Wert zuweißen kann (Propertiesinitialisierung) und irgendwo wieder auslesen kann (Process). Natürlich solle man dabei die Kopplung möglichst gering halten.

 

[XHelp]

Ja, aber du kannst die sinnvoll einsetzen, wenn du den ganzen Sinn darin verstanden hast. Ansonsten kommen Programme nur mit static-Methoden raus, weil ja die main schon static ist.

 

[Andi_CH]

Statische Methoden solltest du vermeiden, sobald du welche davon überschreiben willst.
Bis ich das erste mal begriffen habe warum in meine Methode B.funktionDrei() nicht aufgerufen wurde, dauerte es eine Weile.

package ch.andi.demo;

public class A {
	public static void funktionEins() {
		System.out.println("A Eins");
		funktionZwei();
	}
	public static void funktionZwei() {
		System.out.println("A Zwei");
		funktionDrei();
	}
	public static void funktionDrei() {
		System.out.println("A Drei");
	}
}

package ch.andi.demo;

public class B extends A {
	public static void funktionEins() {
		System.out.println("B Eins");
		funktionZwei();
	}
	public static void funktionDrei() {
		System.out.println("B Drei");
	}
}

package ch.andi.demo;

public class DemoStatic {
	public static void main(String[] args) {
		System.out.println("Aufruf von A.funktionEins");
		A.funktionEins();
		System.out.println("Aufruf von B.funktionEins");
		B.funktionEins();
	}
}

Aufruf von A.funktionEins
A Eins
A Zwei
A Drei
Aufruf von B.funktionEins
B Eins
A Zwei
A Drei

Wenn die Funktionen nicht statisch definiert und der Aufruf angepasst ist, wird natürlich shön brav

Aufruf von b.funktionEins
B Eins
A Zwei
B Drei

ausgegeben

Das ist der mühsamste Unterschied

 

[Andi_CH]

Wie hast du es probiert? Statische Methoden kannst du auch über die Instanzen aufrufen.

Warum kommt da die Warnung "The static method funktionEins() from the type B should be accessed in a static way" wenn ich das mache?
Ist doch egal wie ich die Anspreche?

 

[ARadauer]

Ist doch egal wie ich die Anspreche?

ja, ist ja auch nur eine Warnung, dass du dir bewusst machst dass du keine Objekt Methode sondern eine Klassen Methode aufrufst....

 

[Marco13]

Es ist nur eine Warnung. Es ist eine statische Methode, und die "sollte" man statisch aufrufen.
Ich habe schon oft genug Code in der Form

Utility utility = new Utility();
utility.callSomeStaticMethod();

gesehen, wo ein Objekt instantiiert wurde, um eine statische Methode aufzurufen :autsch: (Reine Utility-Klassen sollten dann aber auch nur einen privaten Konstruktor haben)

 

[nrg]

sollte man halt nicht machen.

ein instanziierter Aufruf

[c]new MeineKlasse().meineStatischeMethode();[/c]

und ein statischer Aufruf

[c]MeineKlasse.meineStatischeMethode();[/c]

machen - wie XHelp schon sagte - genau das Gleiche. Nur ist es - ohne MeineKlasse zu kennen - auf den ersten Blick ersichtlich, dass es sich beim Zweiten um einen statischen Aufruf handelt.

 

[Marco13]

ein instanziierter Aufruf

[c]new MeineKlasse().meineStatischeMethode();[/c]

und ein statischer Aufruf

[c]MeineKlasse.meineStatischeMethode();[/c]

machen - wie XHelp schon sagte - genau das Gleiche.

class MeineKlasse
{
    public static void meineStatischeMethode()
    {
        System.out.println("Hello");
    }

    public MeineKlasse()
    {
        System.exit(-666);
    }
}

 

[Andi_CH]

Utility utility = new Utility();
utility.callSomeStaticMethod();

Ich wusste echt nicht dass das geht, bis ich es vorhin ausprobiert habe

Warum geht das nicht?

(b.getClass()).funktionEins();

-> The method funktionEins() is undefined for the type Class<capture#2-of ? extends B>

Declaration von getClass:

public final native Class<?> getClass();

(Ich gebs zu die Notation mit dem ? verstehe ich gar nicht, obwwohl ich der auch schon begegnet bin)

 

[nrg]

@Marco13: naja. außer wenn natürlich im Konstruktor statische Attribute geändert werden, die VM ne Keule bekommt oder eine Exception fliegt

 

[tfa]

Warum geht das nicht?

(b.getClass()).funktionEins();

-> The method funktionEins() is undefined for the type Class<capture#2-of ? extends B>

Ganz einfach: in der Klasse [c]Class[/c] gibt es diese Methode nicht. Du musst schon auf die konkrete Utility-Klasse verweisen, damit die Methode gefunden wird.

 

[Andi_CH]

Ganz einfach: in der Klasse [c]Class[/c] gibt es diese Methode nicht. Du musst schon auf die konkrete Utility-Klasse verweisen, damit die Methode gefunden wird.

Ich will ja nicht darauf verweisen sondern die holen ;-) egal, das wäre ja auch ein krankes Konstrukt ;-)

Andererseits ist ja ganz klar definiert von welcher Klasse b ist - da habe ich jetzt aber ernsthaft erwartet, dass das auch aufgelöst werden kann.

 

[bygones]

Andererseits ist ja ganz klar definiert von welcher Klasse b ist - da habe ich jetzt aber ernsthaft erwartet, dass das auch aufgelöst werden kann.

erwarte nicht zuviel magic - und das ist auch gut so

statische methoden generell sollte man so gut wie geht vermeiden. Einzig legitime Stellen sind wenn man sich im Objektgraph in einem Blatt findet, also keine weitere Instanzierungen bzw Objektaufrufe mehr hat - bsp Math

 

[Marco13]

statische methoden generell sollte man so gut wie geht vermeiden.

Das klingt ... ein bißchen zu pauschal. Ich habe eigentlich die Daumenregel "Methoden statisch machen, wenn man das ohne Aufwand machen kann, Fields statisch machen, wenn es nicht anders geht". Deine Erläuterungen im zweiten Teil gehen schon in diese Richtung: Wenn man eine Methode hat, die nicht auf Instanzvariablen arbeitet (und nicht polymorph verwendet werden soll) dann sollte man die IMHO static machen.

 

[bygones]

bewusst pauschal gemacht. In 9 von 10 fällen wird statisch falsch eingesetzt, daher meine Regel "generell erstmal nicht statisch", ausnahme ist dann erklärt.

 

[Wuella]

Statische Methoden solltest du vermeiden, sobald du welche davon überschreiben willst.
Bis ich das erste mal begriffen habe warum in meine Methode B.funktionDrei() nicht aufgerufen wurde, dauerte es eine Weile.

package ch.andi.demo;

public class A {
	public static void funktionEins() {
		System.out.println("A Eins");
		funktionZwei();
	}
	public static void funktionZwei() {
		System.out.println("A Zwei");
		funktionDrei();
	}
	public static void funktionDrei() {
		System.out.println("A Drei");
	}
}

package ch.andi.demo;

public class B extends A {
	public static void funktionEins() {
		System.out.println("B Eins");
		funktionZwei();
	}
	public static void funktionDrei() {
		System.out.println("B Drei");
	}
}

package ch.andi.demo;

public class DemoStatic {
	public static void main(String[] args) {
		System.out.println("Aufruf von A.funktionEins");
		A.funktionEins();
		System.out.println("Aufruf von B.funktionEins");
		B.funktionEins();
	}
}

Aufruf von A.funktionEins
A Eins
A Zwei
A Drei
Aufruf von B.funktionEins
B Eins
A Zwei
A Drei

Wenn die Funktionen nicht statisch definiert und der Aufruf angepasst ist, wird natürlich shön brav

Aufruf von b.funktionEins
B Eins
A Zwei
B Drei

ausgegeben

Das ist der mühsamste Unterschied

Ist doch klar, dass da:

Aufruf von B.funktionEins
B Eins
A Zwei
A Drei

rauskommt.
du rufst ja in funktionEins von B die geerbte methode funktionZwei von A auf, in der dann funktionDrei, auch von der Klasse A, aufgerufen wird.

Wenn du stattdessen in funktionEins von Klasse B direkt funktionDrei aufrufst, klappt das doch mit dem Überschreiben.

 

[Andi_CH]

Nein es klappt eben NICHT so wie es IMHO sein SOLLTE!

Die funktionZwei() müsste nämlich funktionDrei() aus A oder B aufrufen, abhängig davon woher sie aufgerufen wurde! (In meinem Fall sind funktionZwei() und funktionDrei() protected)

Nimm alle static weg, instanziere die Klasse und schau an was dann ausgegeben wird... so müsste ich es haben.

Die Verkettung der Funktionen ist gegeben! (Bestehendes Projekt)
Es ist ein ganz kleiner Teil der bestehende funktionZwei der jetzt kontextabhängig geändert werden muss, also lagert man den doch aus -> funktionDrei() und überschreibt diese in der abgeleiteten spezialisierten Klasse B - so das was man sich von OO gewöhnt ist.

Nur ist static leider nicht OO :-(

Ich musste in der abstrakten Klasse ein if-Konstrukt einfügen, das mir beeinflusst welche funktionDrei() nun ausgeführt werden soll. funktionZwei() zu kopieren macht in diesem Fall absolut keinen Sinn, da sie sehr gross ist....