Konstanten

[Fret]

Hallo ihr alle!

Ich bin neu hier im Forum und ebenfalls ein Neuling was Java angeht. Ich lerne die Sprache momentan mit der "Insel".
Ich plane nun ein Programm, dass physikalsiche Konstanten für Berechnungen benötigt. Ich frage mich momentan, ob ich diese Konstanten typsicher mit

enum

und dem Wert der Konstanten als Attribut des entsprechenden Objekts oder einfach als

public static final

deklarieren soll. Ich verstehe denke ich den Unterschied zwischen den beiden und auch den Sinn von enum, aber das hilft mir irgendwie hier nicht. Also, erschlagt mich! :wink:

Der FRET

 

[Marco13]

Abgesehen davon, dass ich die Java-Enums ganz subjektiv total toll finde: Ich sehe (objektiv, soweit mir das möglich ist) keinen Nachteil von enums gegeüber finals, und keinen Vorteil von finals gegenüber enums, und würde daher zu letzteren tendieren.

 

[ms]

Hier kann man auch nochmal was dazu nachlesen:
http://java.sun.com/javase/6/docs/technotes/guides/language/enums.html

ms

 

[maki]

Es wäre ein vorteil, wenn man ganzzahlen verwenden würde um static final zu unterscheiden:

public static final int SYMBOL1= 1;
public static final int SYMBOL2= 2;
public static final int SYMBOL3= 3;
..

Sind viele davon vorhanden, könnte jemand aus vesehen denselben wert zweimal zuweisen:

..
public static final int SYMBOL98= 98;
public static final int SYMBOL99= 1;

Das wäre ein Problem, da SYMBOL1 und SYMBOL99 nicht unterscheidbär wären, schwer zu finden.

Das passiert mit enums nicht.

Wenn du allerdings Zahlenwerte brauchst (zB phys. Konstanten) die sowieso unterschiedlich sind, ist es fast egal, ausser dass enums moderner sind.

 

[ms]

Ich finde es macht schon einen Unterschied. Vielleicht ist das eh jedem klar, ich erwähne es hier nochmal.

Enums sind Aufzählungstypen, also Konstanten, die den Zustand eines Typs beschreiben. Montag, Dienstag, Mittwoch ... ist ein klarer Fall für Enums.
PI hingegen ist eine konstante Zahl und sollte, wie ich finde, nicht als Enum deklariert werden.

Da es eine Weile gedauert hat, bis Enums auch in Java vorhanden waren hatte man keine andere Wahl und musste Konstanten als Enums missbrauchen.

ms

 

[Fret]

Wenn ich nun aber nicht nur dem Namen der Konstanten einen Wert, sondern auch noch die Einheit zuordnen möchte, dann würden sich enums auf jeden Fall anbieten, oder? Ich würde das dann als Eigenschaften des Objektes "Bla-Konstante" interpretieren. Oder? Oder nicht? Oder wie jetzt? ;-)

 

[Jango]

Oder? Oder nicht? Oder wie jetzt? ;-)

Nein. Du kannst einer Konstanten nur einen Wert zuweisen. Das nennt sich Aufzählungstyp. Was willst du an einer Einheit aufzählen? Oder verstehe ich das falsch...

 

[byte]

Du kannst einer Konstanten gar keinen Wert zuweisen, sonst wäre es keine Konstante. Eine (Enum-)Konstante kann aber endlich viele (konstante) Eigenschaften haben.

 

[Jango]

Du kannst einer Konstanten gar keinen Wert zuweisen...

Doch, natürlich. Man kann doch einer Konstanten in einer Enumeration einen vom Standardwert abweichenden Wert zuweisen? Ist das keine Zuweisung? Weist man keinen Wert zu, beginnt das erste Element mit 0. Die Konstanten sind doch die Elemente der Enumeration.

 

[byte]

Puh, jetzt kann ich Dir nicht mehr folgen, was genau Du meinst.

 

[tfa]

Du kannst einer Konstanten gar keinen Wert zuweisen...

Doch, natürlich. Man kann doch einer Konstanten in einer Enumeration einen vom Standardwert abweichenden Wert zuweisen? Ist das keine Zuweisung? Weist man keinen Wert zu, beginnt das erste Element mit 0. Die Konstanten sind doch die Elemente der Enumeration.

Das verwechselst Du mit C#. Java-Enums (bzw. die interne Darstellung) beginnen immer mit 0. Davon abgesehen wäre es keine Zuweisung im weiten Sinne, sondern eher eine Definition, die sich nicht mehr überschreiben lässt.

tfa

 

[Jango]

Das verwechselst Du mit C#...

Kann sein...

 

[maki]

In Java gibt es keine echten Konstanten

 

[Jango]

In Java gibt es keine echten Konstanten

Auf der Insel nicht - nein... :autsch:

 

[Leroy42]

In Java gibt es keine echten Konstanten

Willst du jetzt auf den Datentyp unreal constness aus der
J(ava L(anguage S(pecification raus??

Da geb ich dir Recht!

 

[Jango]

In Java gibt es keine echten Konstanten

Willst du jetzt auf den Datentyp unreal constness aus der
J(ava L(anguage S(pecification raus??

Da geb ich dir Recht!

Ach so - die constness - ja die... hab ich vergessen. Stimmt.

 

[byte]

Wat für'n Ding?

 

[Leroy42]

Wat für'n Ding?

Kennste nicht?

Hier mal ein link auf unreal constness

 

[maki]

const correctness wäre der richtige Begriff:

package test;

import java.util.Date;

public class Test {
  
    final static int foo = 42;
    final static String fooObject = "konstant?";
    final static Date fooMutable= new Date( 1 );

	public static void main(String[] args) {
		
	        foo= 1; // fehler
			
	        fooObject= "variabel?"; // fehler
		
		fooMutable.setTime( System.currentTimeMillis() );   //geht!
			
		System.out.print( fooMutable );	
	}

}

Wenn das Objekt ein mutabale (veränderbares) ist, kann man dessen Wert ändern, trotz final.
Man kann allerdings kein neues Objekt der als final deklarierten Referenz zuweisen.

const ist ein Schlüsselwort in Java, allerdings sieht es nicht so aus, als ob es bald (überhaupt?) belegt wird, so dass es sich wie const in C/C++ verhält.

Gruß,

maki

 

[Leroy42]

...
Gruß,

maki

Sag mal: Merkst du eigentlich überhaupt noch was?

(Wenn nicht, ist es auch egal...)

 

[maki]

...
Gruß,

maki

Sag mal: Merkst du eigentlich überhaupt noch was?

(Wenn nicht, ist es auch egal...)

Meinst du deinen Versuch Humor zu zeigen?

 

[Leroy42]

Meinst du deinen Versuch Humor zu zeigen?

Aha, hast es ja schlussendlich doch noch bemerkt...

 

[maki]

Schlussendlich?

Du überschätzt deine Fähigkeit Humor zu zeigen masslos, manche "Witze" sind so schlecht das man sie als offensiv empfinden könnte und lieber drüberhinwegliest.

Vielleicht wärst du lieber Komiker geworden anstatt Java Entwickler?

 

[Leroy42]

Immer noch besser als überhaupt keinen zu haben.

Bevor das hier jetzt zu persönlich wird, empfehle ich
dir lieber, spielen zu gehen und mit deinen Konstanten
herumzujonglieren.

==> .

 

[Marco13]

Vielleicht wollen Fret und ms noch zur Klärung der Frage beitragen. Speziell @ms: Was spricht gegen sowas

enum Constants
{
    GRAVITY(9.81, "m/(s*s)", "Gravity"),
    ELECTRON_MASS(1.234e-40, "kg", "Electron mass"),
    ...
}

wo man jeder Konstanten nicht nur den Wert, sondern auch Einheit und Namen zuweist?

Man könnte es natürlich auch anders machen. JScience http://jscience.org/ werwendet Konstanten vom Typ "Amount" http://jscience.org/api/org/jscience/physics/amount/Constants.html - auch eine Möglichkeit. Kommt wohl auf die Anforderungen an.

 

[Fret]

Genau so meinte ich das. Spricht irgendetwas gegen diese Lösung?

 

[maki]

Genau so meinte ich das. Spricht irgendetwas gegen diese Lösung?

Das kommt darauf an, brauchst du denn Einheit und Bezeichnung, oder reicht einfach nur die Konstante?

 

[Fret]

Die Einheit dazu wäre schon ganz nett. Es macht das ganze ja nicht unübersichtlicher, sondern würde für Klarheit sorgen. Und bei einer möglichen Ausgabe der Werte könnte ich auch direkt darauf zurückgreifen.

 

[Marco13]

Das kommt darauf an, brauchst du denn Einheit und Bezeichnung, oder reicht einfach nur die Konstante?

Vielleicht ist die Frage so "gefährlich" gestellt. Wie wäre es mit der Frage:
"Kann es sein, dass du irgendwann mal mehr brauchst als nur den reinen Zahlenwert?"

Im Hinblick auf Erweiterbarkeit ist eine enum (oder, alternativ aber fast gleichbedeutend) eine Klasse wie "Amount" bei JScience) auf jeden Fall sicherer.

 

[maki]

"Kann es sein, dass du irgendwann mal mehr brauchst als nur den reinen Zahlenwert?"

imho ist es etwas übertrieben, an alle möglichen Fälle der Zukunft zu denken, dass führt oft zu einem übertrieben komplexen Design und manchmal sogar zu "dead code".

Meist reicht die Frage: "Was brauchst du jetzt?"

Wenn irgendwann dann mehr verlangt wird, kommt man nicht drumherum Änderungen zu machen, allerdings hab ich in meiner Erfahrung dann soviel geändert, dass selbst ein "vorraussehendes Design" geändert werden musste und keinen Vorteil gebracht hatte.

Die Einheit dazu wäre schon ganz nett. Es macht das ganze ja nicht unübersichtlicher, sondern würde für Klarheit sorgen. Und bei einer möglichen Ausgabe der Werte könnte ich auch direkt darauf zurückgreifen.

Das hört sich doch so an, als ob Enums (oder gar Klassen) vorzuziehen wären.

 

[sliwalker]

Hoi,

eine Sache sollte man aber nicht vergessen:

Als final deklarierte Felder sind Thread-safe, weil sie nicht nachgeladen werden. In einem synchronized-Block kann einem das manchmal das Leben echt einfach machen.

greetz
SLi

 

[byte]

Das glaube ich nicht.

 

[Fret]

Abschließend nochmal meinen Dank an alle! Das war meine erste Erfahrung mit diesem Forum und sie war durchweg positiv. Ich hoffe, auch bald genug Erfahrung zu haben um anderen hier helfen zu können.
(BTW, es werden wohl enums werden :wink: )

 

[sliwalker]

Das glaube ich nicht.

Dann schau in der Java Language Spec 3.0 im Kapitel 17.5 "Final Field Semantics" nach.

greetz
SLi

 

[tfa]

Das glaube ich nicht.

Dann schau in der Java Language Spec 3.0 im Kapitel 17.5 "Final Field Semantics" nach.

greetz
SLi

Möglicherweise meinte byto folgendes:

private final Map m = new HashMap(); // nicht threadsicher

 

[byte]

Jo eben. Trifft halt auf Mutables nicht zu.

 

[sliwalker]

aso
Alles klar...