Variablen Konstantensammlung vs. Enum

[kaoZ]

Aloha, ich steh grade im Zwiespalt,

zzt. nutze ich zum handhaben von Festen Werten eine Konstantensammlung welche ich über einen Statischen Import anspreche

Spoiler: Konstantensammlung.Bsp

public class Constants {

	public final static String APP_TITLE = "Rechnungs Editor v1.0";
	
	public final static String MENUBAR_FILE 	= " Datei ";
	public final static String MENUBAR_EDIT 	= " Bearbeiten ";
	public final static String MENUBAR_OPTION 	= " Einstellungen ";
	public final static String MENUBAR_SEARCH 	= " Suchen ";
	public final static String MENUBAR_WINDOW 	= " Fenster ";
	public final static String MENUBAR_HELP 	= " Hilfe ";
	
	
	
	public final static int SCREEN_WIDTH = (int) Toolkit.getDefaultToolkit().getScreenSize().getWidth();
	public final static int SCREEN_HEIGHT = (int) Toolkit.getDefaultToolkit().getScreenSize().getHeight();
	
}

Jetzt habe ich allerdings gelesen ( Der Weg zum Java Profi - M.Inden ) das dies als unsauber bzw. weniger elegant ist, als ein Enum für Konstanten zu verwenden.

Spoiler: Enum.Bsp

public enum Constant {
	
	APP_TITLE("Beispiel Applikation");
	
	private Constant(final String value){
		this.value = value;
	}
	
	final String value;

	public String getValue(){
		return this.value;
	}
	
}

einerseits könnte ich auf die Statischen Importe verzichten , andererseits muss ich dann folgendes in der Verwendung beachten

mit Konstanten :

JFrame frame = new JFrame(APP_TITLE);

mit Enum :

JFrame frame = new JFrame(Constant.APP_TITLE.getValue());

Schöner find ich vom Aufbau her aber irgendwie die Konstantensammlung , wie seht ihr das ?

 

[Natac]

Wenn es um Beschriftungen geht, würde ich die ResourceBundle-Api mit entsprechendem Aufruf verwenden. Das mit den Enums (+ ResourceBundle) habe ich mal in einem Projekt gemacht und fühlte sich für mich als Overhead an, da man immer nochmal die Enum-Konstante schreiben (anlegen + schlüssel mitgeben) und dann eben kompliziert aufrufen muss. Da finde ich ein

Resources.get("save");

irgendwie schöner.

Wenn es prinzipiell um Konstanten geht, dann nimm auf jeden fall die Klassen-Variante. Denn was ist, wenn du mal etwas anderes als einen String abspeichern willst? Gibts beim enum dann ein getInt()? Und wenn ja, was liefert getValue()? Und woher weißt du, bei welcher Enum-Konstante du das nehmen "darfst"? Da bist du mit der Constants-Klasse viel flexibler und typsicherer.

Ist aber nur meine Meinung. Vielleicht findet sich hier noch jemand mit mehr Erfahrung der dir das ganze besser als mit "fühlt sich für mich so und so an" begründen kann.

 

[turtle]

Du kannst die Enum-Variante so benutzen:

JFrame frame = new JFrame(APP_TITLE.value);

Und das finde ich aussagekräftig und würde es einer Konstantensammlung vorziehen.

 

[kaoZ]

Zuerst einmal Danke,

Natac, das mit dem API werde ich mir mal anschauen .

Wie du auch schon sagtest halt ich eben den aufruf über Constants.APP_TITLE.getValue(); für ziemlichen Overkill, und stand dann gestern genau vor dem Problem wenn ich z.B die Werte für die Bildschirmgröße ermitteln wollte, dort wird nämlich als Wert ein Integer geliefert und kein String, so müsste ich dann wieder mehrere Sammlungen ( enums ) anlegen die jeweils die richtigen Werte liefern...

turtle, dein Beispiel gefällt mir vom Aufbau her sehr, das sieht Aussagekräftig und sinnvoll aus, allerdings komm ich grade nicht dahinter wie du das Umgesetzt hast das du den Klassennamen nicht angeben musst, wie soll der Compiler wissen in welcher Aufzählung er dann suchen soll ?

und wie müsste ich die Sammlung implementieren um diesen Aufruf zu ermöglichen ?

da ich ja den Qualifizierten Namen bisher immer angeben musst

sprich :

Constants.APP_TITLE

für die Sammlung und eben die öffentliche Methode

.getValue()

um an den zugewiesenen Wert zu gelangen .

Wenn du mir ein Beispiel geben könntest wäre ich sehr dankbar .

 

[turtle]

import javax.swing.JFrame;

import static constant.ConstantEnum.*;

public class Turtle {

    public static void main(String[] args) {
	JFrame frame = new JFrame(APP_TITLE.value);
	frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
	frame.setVisible(true);

    }
}

package constant;


public enum ConstantEnum {
    APP_TITLE("Beispiel Applikation");

    private ConstantEnum(final String value) {
	this.value = value;
    }

    public final String value;

}

 

[kaoZ]

Ok funktioniert, allerdings auch nur in Verbindung mit einem Statischem Import,

die Frage ist , wenn ich wie oben schon beschrieben jetzt Anstelle eines Strings einen Integer benötige müsste ich dafür ja eine Separate Sammlung anlegen, oder ?

Und vorallem :

Warum soll das

JFrame frame = new JFrame(APP_TITLE.value);

sauberer Programmierstil sein als

JFrame frame = new JFrame(APP_TITLE);

mal abgesehen davon das die Aussage schon richtig ist das es sich ja bei Konstantensammlungen , eben um Sammlungen bzw. aufzählungen handelt, allerdings wird doch durch das nutzen verschiedenen Enums ( für Integer / Strings usw. usw.) die Anzahl an zugriffspunkten auch immens erhöht , ich meine wenn ich eine Klasse haben in welcher ich alle Konstanten definiere habe ich einen Zentralen Punkt an welchem ich dies tue, nutze ich Enums hab ich zwar vielleicht alles im gleichen Package aber in unterschiedlichen Sammlungen. ( dies wäre zwar der OO Ansatz, allerdings doch auch umständlicher oder ?.

Und soweit ich weiß soll man immer alle Dinge so einfach wie möglich halten um nicht unnötige Komplexität in die Implementierung zu bringen , insofern man davon keine nutzen hat ?!

 

[turtle]

die Frage ist , wenn ich wie oben schon beschrieben jetzt Anstelle eines Strings einen Integer benötige müsste ich dafür ja eine Separate Sammlung anlegen, oder ?

Nein, das stimmt nicht. Siehe Beispiel.

Aber es ist natürlich immer eine Frage, was du eigentlich machen möchtest.

import javax.swing.JFrame;
import javax.swing.JOptionPane;

import static constant.ConstantEnum.*;

public class Turtle {

	public static void main(String[] args) {
		JFrame frame = new JFrame(APP_TITLE.value);
		JOptionPane.showConfirmDialog(null, APP_INTEGER.intValue);
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		frame.setVisible(true);

	}
}

package constant;

public enum ConstantEnum {
	APP_TITLE("Beispiel Applikation"), APP_INTEGER(234);

	private ConstantEnum(final String value) {
		this.value = value;
	}

	private ConstantEnum(int value) {
		this.intValue = value;

	}

	public String value;
	public int intValue;

}

 

[kaoZ]

Ich hatte vorhin schon versucht je einen Konstruktor für Strings und einen für Ínteger zu definieren , allerdings hat Eclipse mir sofort die Meldung ausgegeben das die Variablen nicht initialisiert wären..

ich hab eh noch nicht wirklich gecheckt warum ich in einem enum die Variablen nur nach dem Konstruktor definieren kann , und nicht wie in einer normalen klasse auch nach der Klassendeklaration, allerdings habe ich auch noch nicht sooooo oft mit enums gearbeitet, sondern mich eher auf die Implementierung mit Konstantensammlungen gestützt

Wäre super wenn du mir dies vielleicht auch fix erläutern könntest

 

[shishigami]

[...]
einerseits könnte ich auf die Statischen Importe verzichten , andererseits muss ich dann folgendes in der Verwendung beachten

mit Konstanten :

JFrame frame = new JFrame(APP_TITLE);

mit Enum :

JFrame frame = new JFrame(Constant.APP_TITLE.getValue());

Schöner find ich vom Aufbau her aber irgendwie die Konstantensammlung , wie seht ihr das ?

Statischer Import geht auch mit Enum, noch einen getter aufrufen zu müssen sehe ich nicht als allzu großes Problem.

Rein von der Struktur her halte ich Enums für sinnvoller als eine Klasse mit vielen Konstanten.

ich hab eh noch nicht wirklich gecheckt warum ich in einem enum die Variablen nur nach dem Konstruktor definieren kann , und nicht wie in einer normalen klasse auch nach der Klassendeklaration

Muss nicht nach dem Konstruktor sein:

public enum MyEnum {

    APP_TITLE("Beispiel");

    private final String value;

    private MyEnum(final String value) {
        this.value = value;
    }

    public String getValue() {
        return value;
    }

    public String toString() {
        return value;
    }

}

Die Variablen müssen nur nach den verschiedenen Enumerationen stehen. Auch das halte ich für sinnvoll.

 

[Natac]

public enum ConstantEnum {
	APP_TITLE("Beispiel Applikation"), APP_INTEGER(234);

	private ConstantEnum(final String value) {
		this.value = value;
	}

	private ConstantEnum(int value) {
		this.intValue = value;

	}

	public String value;
	public int intValue;

}

Und genau das ist der Grund, warum ich ein enum für eine schlechte Idee halte. Angenommen wir brauchen noch boolean und double, dann haben wir:

public String value;
public int intValue;
public int boolValue;
public int doubleValue;

Und woher weiß ich jetzt, bei welcher Constante ich welchen Wert verwenden muss? Weil

MY_CONST.inValue

klappt natürlich auch für eine Constante, die eigentlich einen double-Wert enthält. Und außer String werden alle Werte immer mit einem "gültigen" Wert gefüllt sein (0, 0.0, false).

Daher halte ich das Enum-Konzept in größeren Projekten für unübersichtlich und fehleranfällig. Natürlich könnte man jetzt pro Typ ein Enum definieren, die man alle statisch importieren könnte, was ich aber für Overkill halte.

Zudem emfpinde ich den Zugriff auf Attribute problematisch, weil sich die Werte evtl. zur Laufzeit ändern könnten (Sprache wird umgestellt). Würde als mindestens die Methode

val()

statt

value

einführen.

Prinzipiell gebe ich euch Recht, dass so ein enum etwas schönes ist, weil man auf Code-Ebene alle Werte fest vereinbart hat. Allerdings lassen sich damit Konstanten nur nach Typ und nicht nach Inhalt gruppieren, was ich schon als störend empfinde.

Dann lieber eine Constanten-Klasse mit statischen Methoden. Die kann ich genauso statisch importieren, bin vom Typ her aber flexibler. Enums sind zur Aufzählung von Gleichartigen Werten gedacht, was Konstanten in der Regel nun mal nicht sind (da unterschiedlichen Typs).