Schlüsselworte static Methoden und Imports

[RolandK]

Hallo Leute,

ich habe mal eine generelle Frage zu static Methoden und static Imports.

Mein Projekt besteht aus 17 Klassen und ca. 3400 Zeilen Netto-Code.

Es gibt eine Klasse (A), die eine Art Hauptprogramm darstellt und auch die main()-Methode enthält. In dieser Klasse werden Konstanten und Objekte definiert und instanziiert. Andere Klassen müssen auf diese Elemente zugreifen können.

Bisher ist diese Klasse A (850 Zeilen Code) so implementiert, dass alle Konstanten, Objekte und Methoden als static deklariert sind. Andere Klassen, die auf diese Elemente zugreifen müssen benutzen als import-Statement "import static Package-Name.A.*;" Die meisten Methoden der Klasse A sind private.

Ist das ok so, oder gibt es eine bessere Art, das zu implementieren? Soll / muss man von dieser Klasse ein Objekt erzeugen (das dann nur einmal existiert)? Und wie sähe dann das import-Statement aus?

Danke, Roland

 

[Int42]

Du kannst die Klasse auch ohne "static" importieren, dann musst du aber die statischen Eigenschaften mit dem Klassennamen ansprechen:

A.eigenschaft;

Wenn du aber die statischen Eigenschaften der Klasse oft verwendest, ist es vielleicht mühselig, immer den Klassennamen voranzustellen. Dann ist es z.B. besser, einen static import zu verwenden:

import static PackageName.A.*;

 

[Schandro]

Ist das ok so, oder gibt es eine bessere Art, das zu implementieren? Soll / muss man von dieser Klasse ein Objekt erzeugen (das dann nur einmal existiert)? Und wie sähe dann das import-Statement aus?

Eventuell ist es schöner aus

A

ein Singleton zu machen, dass musst du aber selber entscheiden.

Generell gesehen würde ich mir um

import

keine Gedanken machen, imports sind immer der unwichtigste Teil eines Quellcodes. Ich persönlich halte nichts von static imports, da es auf dem ersten Blick eher verwirrend aussieht und eine Technick ist die sehr selten genutzt wird. Außerdem bereitet es später eventuell Arbeit wenn man die static imports aus irgendeinen Grund wieder entfernen will.

 

[timbeau]

Eventuell ist es auch schöner aus A ein Objekt zu machen und eben nicht alles static....

 

[RolandK]

@ Schandro: Die static Imports hat mir IntelliJ IDEA automatisch eingebaut, nachdem es gesehen hat, dass ich auf statische Konstanten/Variablen zugreife. Fand ich ganz praktisch, die Konstanten/Variablen direkt nutzen zu können.

Also evtl. ein Singleton mit non-static Methoden und static Konstanten/Variablen?

 

[timbeau]

Muss es unbedingt ein Singleton sein? Was spricht gegen die Übergabe des Objekts?

Auf die Werte kann man dann auch zugreifen

 

[Spacerat]

Eine weitere Möglichkeit besteht darin, gemeinsam genutzte Konstanten in einem Interface zu vereinen bzw. in mehreren zu gruppieren. Klassen, die diese Konstanten benötigen, können diese Intefaces dann einfach implementieren. Das war eine gängige Technik, bevor mit Java 5 (oder war es bereits in 4? :bahnhof die static imports kamen. Leider funktioniert das nicht bei Methoden, aber dazu kann man dann eben Singletons als Konstanten deklarieren, die dann diese Methoden anbieten. Static imports sind aber sauberer.

 

[RolandK]

Auf die Werte kann man dann auch zugreifen

Ja klar, dann muss man halt immer den Objektnamen voranstellen, was bei einfachen Variablen etwas kompliziert aussieht.

Muss kein Singleton sein, habe mal irgendwo gelesen, dass das sogar zuweilen als Anti-Design-Pattern bezeichnet wird.

 

[maki]

Ja klar, dann muss man halt immer den Objektnamen voranstellen, was bei einfachen Variablen etwas kompliziert aussieht.

Grundsätzlich muss man wissen, was man denn konkret vorhat, denn davon hängt auch die passende Lösung ab..

Auf "statische Variablen" per static imports zuzugreifen klingt 3-fach falsch.

Bisher ist diese Klasse A (850 Zeilen Code) so implementiert, dass alle Konstanten, Objekte und Methoden als static deklariert sind. Andere Klassen, die auf diese Elemente zugreifen müssen benutzen als import-Statement "import static Package-Name.A.*;" Die meisten Methoden der Klasse A sind private.

Das wiederum klingt als ob da kein objektorientierter Code vorliegt.

 

[RolandK]

Das wiederum klingt als ob da kein objektorientierter Code vorliegt.

Ich weiß, dass Klasse A nicht besonders objektorientiert ist. Das liegt daran, dass das Programm ursprünglich nur per Kommandozeile gestartet wurde.

Mittlerweile kann der Benutzer wählen, ob er die Kommandozeilenversion (Start des JAR mit Parametern) oder die GUI-Version benutzen will. Die Kommandozeilenversion ist in einer Methode der Klasse A enthalten und die GUI gibt ihre Befehle (Reaktion auf Button-Klicks) teilweise wieder an Klasse A zurück.

Z.B. gibt es eine Methode saveReport() (enthalten in A) die sowohl von der Kommandozeilen-Methode als auch von der GUI aufgerufen wird. Ausserdem gibt es einige Konstanten in A z.B.

    final static String PROGRAMMNAME = "Programmname";
    final static String VERSION = "Version 0.6.1";

auf die ich wirklich von allen Klassen zugreifen will, statt sie über die Klassen zu verteilen.
Sowohl die Kommandozeilenversion als auch die GUI brauchen Zugriff auf diese beiden Beispiele.

Ich denke, ich werde A noch etwas aufräumen und dann ihre Methoden entweder static lassen oder ein Singleton draus machen.

Danke für den Hinweis, Problem gelöst denke ich.

 

[timbeau]

Ich halte die Möglichkeiten die dir vorschweben für die eher schlechteren.

Nochmal, Objektorientiert erreichst du mit Objekten. Und nicht mit einer Monsterklasse, die alle möglichen Daten beinhaltet. Du kannst auch dein Objekt mit den finalen Werten initialiseren und ja, dann müssen andere Klassen mit

a.getValueXY()

darauf zugreifen und nicht mit

a.valuexy

Das nennt man Kapselung und sollte mE immer wenn möglich verwendet werden.