Konstanten in Java
Marcel
- java
0 Arnim0 Daniel Thoma0 Arnim
0 Daniel Thoma0 Slyh0 Martin Jung0 Slyh
0 Marcel
Hallo,
ich möchte in einer Klasse alles Konstanten definieren:
z.B public static final int PORT = 9999;
Diese habe ich in einer Klasse ProjectProperties. Der Zugriff jedesmal über ProjectProperties.PORT ist mir aber ein bisschen zu umständlich. Gibts eine einfachere Methode?
z.B. sowas wie p.PORT ?
Die Klasse aber einfach p zu benennen ist meiner Meinung nach aber nicht sinnvoll...
Gruss Marcel
Moin!
z.B public static final int PORT = 9999;
Diese habe ich in einer Klasse ProjectProperties. Der Zugriff jedesmal über ProjectProperties.PORT ist mir aber ein bisschen zu umständlich. Gibts eine einfachere Methode?
z.B. sowas wie p.PORT ?
Wenns nur darum geht, Schreibaufwand zu reduzieren, solltest Du dich näher mit Deinem Editor auseinandersetzen, da in größeren Projekten lange aber dafür sehr genaue Klassennamen durchaus sinnvoll werden. Manche Editoren haben ausgezeichnete AutoComplete Funktionen.
Wenn es Dir aber zu läßtig ist, schreib doch explizite Methoden wie z.B.
private static int getPort()
in denen Du dann zwar immer noch einmal das Elendige Wort ProjectProperties benutzen mußt, aber die huindertfünfundzwanzig mal danach sparst Du's dann...
Gruß
Arnim
Hallo Arnim,
Wenn es Dir aber zu läßtig ist, schreib doch explizite Methoden wie
Die Codekomplexität zu erhöhen um einen Klassennamen nicht Tippen zu müssen, halte ich für eine wenig gute Idee. Das verschleiert nur, wo die Information eigentlich her kommt und macht das Programm unübersichtlich.
Man kann natürlich auch Konstanten in Interfaces ohne Methoden definieren und diese dann implementieren. Das wird zwar öffters gemacht, ist aber auch kein besonders guter Stil.
Grüße
Daniel
Moin!
Die Codekomplexität zu erhöhen um einen Klassennamen nicht Tippen zu müssen, halte ich für eine wenig gute Idee. Das verschleiert nur, wo die Information eigentlich her kommt und macht das Programm unübersichtlich.
Würd ich selbst auch nicht machen, da mich lange Klassennamen nicht stören. Für die Programmeffizienz dürfte die Methode bei einem guten compiler allerdings kaum Auswirkungen haben. Und manchmal ist ja sogar eine "Verschleierung", ich nenne das dann Transparenz, erwünscht und kann in bestimmten Fällen zu mehr Übersichtlichkeit führen. Allerdings wird sowas erst ab einigen tausend Code-Zeilen interessant, denke ich.
Arnim
Hallo Marcel,
In der aktuellen Version von Java geht es nicht einfacher. Wenn Du eine IDE verwendest, die so etwas automatisch vervollständigen kann, ist das eigentlich auch nicht störend.
Ab Java 1.5beta gibt es ein import static paket.Plasse.* oder import static paket.Klasse.NAME um statische Felder und Methoden zu importieren.
Grüße
Daniel
Hallo,
z.B public static final int PORT = 9999;
Diese habe ich in einer Klasse ProjectProperties.
Mach aus der Klasse ein Interface.
(Dann kannst du auch "public static final" wegmachen, weil in einem
Interface eh alle Variablen public static final sind.)
Dieses Interface kannst du ganz einfach in der Klasse, in der du die
Konstanten verwenden möchtest, implementieren. Sie stehen dann im
Kontext der Klasse zur Verfügung.
Da das Interface keine Methoden hat, brauchst du dafür nichts implemtieren
oder dergleichen.
Eine sehr gute Lösung ist das zwar nicht, weil damit die Klasse, die
das Interface implementiert, größer wird. Gehen tut es aber. :-)
Ansonsten gilt die Lösung von Daniel.
Gruß
Slyh
Hi Slyh,
Eine sehr gute Lösung ist das zwar nicht, weil damit die Klasse, die
das Interface implementiert, größer wird. Gehen tut es aber. :-)
Oder weil man sich auch auf den Standpunkt stellen könnte, dass Konstanten nicht unbedingt ein Teil einer öffentlichen API sind (im Sinne eines Versprechens bzgl. eines bestimmten _Verhaltens_). Ich verwende daher meistens abstrakte Klassen für "shared" Konstanten.
Viele Grüße,
Martin Jung
Hallo,
Oder weil man sich auch auf den Standpunkt stellen könnte, dass Konstanten nicht unbedingt ein Teil einer öffentlichen API sind (im Sinne eines Versprechens bzgl. eines bestimmten _Verhaltens_).
Was meinst du damit? (Dir gefällt nicht, daß die Konstanten im Interface
alle public sind?)
Ich verwende daher meistens abstrakte Klassen für "shared" Konstanten.
Wie sieht das dann genau aus?
Gruß
Slyh
Hi,
Was meinst du damit? (Dir gefällt nicht, daß die Konstanten im Interface
alle public sind?)
Ja, und zwar dann, wenn die Konstanten offensichtlich ein Teil der Implementierung des Interfaces sind - und dadurch eben die eigentlich beabsichtigte Trennung zwischen Abstraktion und Implementierung wieder aufgehoben wird.
Ich verwende daher meistens abstrakte Klassen für "shared" Konstanten.
Wie sieht das dann genau aus?
Bei:
public interface IBLZs {
static final int BLZ_MUSTER_SPARKASSE_X = 111111111;
static final int BLZ_MUSTER_SPARKASSE_Y = 222222222;
static final int BLZ_MUSTER_BANK_X = 111111111;
static final int BLZ_MUSTER_BANK_Y = 222222222;
}
public interface Konto extends IBLZs {
void setBLZ(int neueBLZ);
int getBLZ();
}
public class KontoSparkassen implements Konto {
public void setBLZ(int neueBLZ) {
if (BLZ_SPARKASSE_X == neueBLZ) {
// tue was
}
}
// code...
}
...sehe ich Folgendes als geeignetere Lösung:
public interface Konto {
// Methoden wie oben
}
public abstract class BLZSparkassen {
public static final int BLZ_SPARKASSE_X = 111111111;
public static final int BLZ_SPARKASSE_Y = 222222222;
}
public abstract class BLZBanken {
public static final int BLZ_MUSTER_BANK_X = 111111111;
public static final int BLZ_MUSTER_BANK_Y = 222222222;
}
public class KontoSparkassen implements Konto {
public void setBLZ(int neueBLZ) {
if (BLZSparkassen.BLZ_SPARKASSE_X == neueBLZ) {
// tue was
}
}
// code...
}
Manche halten das für eine "rein formale" (also in der Praxis nicht hilfreiche) Diskussion. Das kann man so sehen. Ich denke aber, dass man dadurch in der Praxis Code ohne relevanten Mehraufwand besser strukturieren kann (der von dir bereits angesprochene Verbrauch an Speicherresourcen würde dadurch potentiell auch - zumindest theoretisch - profitieren..).
Natürlich macht es auch einen Unterschied, wieviele Entwickler an der Implementierung teilhaben. Wenn ich weiß, meine Sourcen werden sowieso niemals der Öffentlichkeit zugänglich gemacht, dann.... ;-)
Viele Grüße,
Martin Jung
Hallo,
Danke euch für die Vorschläge!
Gruss Marcel