Klassen - Static

[dadom110]

Moin zusammen,

hatte grade mit meinem Kollegen eine Diskussion über den Aufbau einer Klasse, und zwar um die verwenden des Schlüsselwortes "static".

Zwei Varianten eines einfachen Codebeispiels, nehmen wir an wir haben eine "Rahmenklasse", die ein Hauptframe aufbaut und die wiederum andere Klassen aufruft. Von diesem Hauptframe brauchen wir ja im Grunde nur ein Exemplar, würde es sich dann anbieten den aufbau so aussehen zu lassen:

public class mainframe 
{
	static int variable1;
	static String variable2;
	public static void main(String[] args) 
	{
		//erzeugen des Frames...
		listenfuellen();
	}
	
	public static void listenfuellen()
	{
		//fuellen der Listen....
	}
}

oder es auf die "objekt?" Methode zu machen, und aus der Klasse erst ein Objekt zu erzeugen und damit weiter zu arbeiten und das ganze so auf zu bauen

public static void main(String[] args) 
	{
		//erzeugen des Frames...
		mainframe mein_objekt_mainframe=new mainframe();
		
		mein_objekt_mainframe.listenfuellen();
	}

Wie sieht das Speicherbedinung aus? Handhabungstechnisch? Und was ensprich dem "Codex" der Java-Programmierer ?

Liebe Grüße
Dom

 

[schnuffie]

Man sieht gleich, daß Du nicht aus der Java-Welt kommst.

Ordentlicher Java-Stil ist, private Member-Variablen zu verwenden, Klassennamen groß schreiben, ect...

Was willst Du eigentlich bezwecken?

Grundsätzlich heißt "static" soviel wie "einmalig". Statische Methoden/Variablen existieren nur einmal, sind also von Instanzen unabhängig.

Beispiel Objekt-Zähler:

public class Z {
private static int i;
private int j;
public Z() {
Z.i++;
this.j = Z.i;
}
public static int getNumberOfObjects() {
return Z.i;
}
public int getObjectNumber() {
return j;
}
}

Somit könntest Du Deine Methode so aufrufen:

mainframe.listenfuellen();

 

[RealHAZZARD]

Ich glaube er meint die Performance!
Also was ist optimaler für Speicherplatz und CPU?

 

[dadom110]

Was willst Du eigentlich bezwecken?

Das Was is oben beschrieben habe Eine Klasse schreiben aus der ich nicht explizit ein Objekt mit "new" erzeuge , sondern in der ich nur static funktionen und variablen verwende (erzeugt er trotzdem ein Objekt? oder verwendet er die Klasse als "Klasse"?)

Somit könntest Du Deine Methode so aufrufen:

mainframe.listenfuellen();

..wie ich oben in meinen beiden Code-Beispielen schon deutlich gemacht habe, ist mir das klar, aber wenn ich in einer Klasse komplett nur static deklariere (jede Funktion und jede Variable, dann könnte ich die Funktion auch mit "listenfuellen();" aufrufen, weil die Funktion static wäre und ich aus diesem Grund kein extra Objekt erzeugen muss!) weil ich mir sicher bin (ganz sicher, wirklich!) das ich nicht mehrere Objekte aus dieser Klasser erzeugen will. Deswegen meine Frage: ob das speichertechnisch besser/schlechter ist (Objekt aus Klasse erzeugen und mit dem Objekt arbeiten, oder direkt mit den static Funktionen/Variablen der Klasse), ob in komplexeren Anwendungen probleme in der Handhabung auftauchen können oder "man das einfach nicht macht"? (wobei letztere Frage eher nebensächlich ist )

Mfg
Dom

 

[takidoso]

Hallo und Halli,
also wenn man ein Objekt erzeugt weden natürlich diverse Dinge zum erzeugen des Objectes gemacht. Wenn man statische Methoden verwendet ist zum Aufrufen der selben kein Objekt notwendig, bedeutet also es ist gewissermaßen schneller, weil man halt kein Objekt erzeugen hat müssen und dies dann vielleicht auch nicht getan hat.
Das bedeutet aber nicht, dass man grundsätzlich statische Methoden und statische Variablen (Klassen-Vatiablen ) verwenden sollte!
Die Entscheidung ob etwas statisch (also direkt ohne instanziiertes Objekt) aufrufbar gemacht werden sollte oder nicht, sollte immer der Frage nach Diskretion/Kapselung unterworfen sein.
Wenn man Performanceprobleme bekommen sollte, und vermutet wegen "zu vieler" Objekte die instanziiert werden (was eigetnlich nur selten der Fall sein sollte), sollte man seine Anwenung daraufhin untersuchen, ob vielleicht bestimmte Objekte nach kurzem Gebrauch wieder weggeworfen werden, und im nächsten Zug wieder neu entstehen.
Typisches Beispiel wäre eine Schleife in der ein und das selbe Objekt seinen Dienst tun könnte, stattdessen es aber wieder neu erzeugt wird. Das setzt natürlich voraus, dass das Objekt für die Aufge innerhalb besagter Schleife ausreichend reinitialisierbar ist, oder eh die selben Konfigurationsinformationen zum Verarbeiten der ihm vorgegebenen Daten inne hat.
Aus meiner Sicht sollte man innerhalb einer Anwendung sich auch darüber Gedanken machen, ob gewisse Objekte tatsächlich nur einmal vorkommen, sogenannte Singletons.
Bei diesen hätte es also keinen Sinn sie mehr als einmal zu ins Leben zu rufen, man sollte also daüber wachen, das dies auch nur einmal passiert. Ich selbst habe bei den meisten meiner Anwenungen einen sogenannten Singletonmanager angewöhnt, der im Grunde eine Art Fabrik ist, die mit statichen Methoden arbeitet, um leichten Zugriff zu den Singletonobjekten zu haben, die aber auch gleichzeitig sicherstellt, dass nur jeweils eine Objekt-Instanz während eines Anwendungslaufs generiert und gegeben wird.
banales Beispiel:

package ...
import ...
public class SingletonManager
{
    static private KlasseA   singletonA = null;
    static private KlasseB   singletonB = null;

     static public KlasseA getSingletonA()
     {
        if (singletonA==null)
        {
           singletonA = new KlasseA();
        }
        return singletonA;
     }

     static public KlasseB getSingletonB()
     {
        if (singletonB==null)
        {
           singletonB = new KlasseB();
        }
        return singletonB;
     }
...
}

Die Klassen-, Membervariablen- sowie Methodennamen sind hierbei natürlich nur Schall und Rauch
Nehmen wir also z.B.an, wir hätten eine typsche Klasse, die wir mal DataHolder nenenen wollen, die auf jeden Fall nur einmal in der Anwendung sinnvoll sei, würden wir mit SingletonManager.getDataHolder() diese bequem bekommen ohne uns Gedanken weiter darüber machen zu müssen, ob sie nun extra instanziiert wurde oder nicht.

in diesem Sinne
Takidoso

 

[dadom110]

Ich selbst habe bei den meisten meiner Anwenungen einen sogenannten Singletonmanager angewöhnt, der im Grunde eine Art Fabrik ist, die mit statichen Methoden arbeitet, um leichten Zugriff zu den Singletonobjekten zu haben

Sehr schöne Idee, damit erübrigt sich auch die Übergabe der Objekte, falls es mal mehr sein sollten, da würde es ja reichen den "SingletonManager" zu übergeben, und schon hat die Klasse zugriff auf alle anderen Objekte... sehr schöne Idee.

Mfg
Dom

 

[takidoso]

grüß Dich,
also den SingletonManager braucht man nicht übergegen, denn seine Funktionen ein Singleton zu holen sind static, also überall ohne Instanziierung abrufbar. der SingletonManager iset somit kein echtes Object sondern eine Art prozeduraler Ansatz.
Ich würde mit dem SingletonManager jedoch nur wirklich zentral verwendete Objecte verwalten, bzw abgreifbar machen. Gui-Komponenten auch se es ein MainFrame würde ich mit anderen Gui-Komponenten nicht über diesen Mechanismus ansrepchen wollen, da eignen sich Listener-Prinzipien erheblich besser, da man in Guis meist Event-gesteuert arbeitet. Also wenn sich etwas im MainFrame oder einem anderen Gui-Teil ereignet so informiere die anderen Gui-Elemente, die diese Information mitgeteilt haben müssen, und sich für diesen Zweck bei dem informierenden Object (kann durch aus auch ein Nicht-Gui sein) angemeldet haben. Allerdings ist dies natürlich reine Architekturfrage.

in diesem Sinne

Takidoso

PS: Ein Fenster kann auch seinen Frame auch abfragen, z.B. (s. getRoot() und getParrent())