enum final Methoden

[MrChance]

Hi !
Wieso kann man in enums final-Methoden deklarieren, wenn enums eh nicht weitervererbt werden ?
Man könnte zwar damit das Überschreiben in der enum selbst unterbinden - aber wieso sollte ein
Entwickler eine Methode als final deklarieren, um dann gleich darauf in der gleichen enum zu überschreiben ?
Frage: Welchen Anwendungsfall gibt es denn für eine final-Methode in einer enum ???

 

[SlaterB]

genauso kannst du in jeder Klasse private-Operation als final deklarieren, obwohl dort das gleiche gilt,
wozu mühsam den Compiler solche Regeln prüfen lassen?
stört doch niemanden

was meinst du eigentlich mit 'in der gleichen Klasse überschreiben'? geht nicht

 

[MrChance]

enum myEnum{
K1,
K2,
K3 { int met() { return 1; };
int meth() { return 0; }
}

wenn man meth() als final deklariert, kann man es nicht bei K3 überschreiben.

Also: Welchen Anwendungsfall gibt es für eine final-Methode in einer enum ???

 

[Gast]

met() ...sollte meth() sein ;-)

 

[SlaterB]

bezieht sich das return 1; auf eine Operation nur für K3?

nun dann ist das doch eine ganz normale Vererbung, die zufällig innerhalb einer Klasse steht,
Vererbung macht allgemein Sinn,
Vererbung muss dann aber (wie überall sonst in Java auch) immer geprüft werden,

bei jedem Aufruf von meth() schaut der Interpreter, ob das aktuelle Enum-Objekt die Operation überschrieben hat oder ob die allgemeine Operation verwendet werden soll,
mit final kann man die Überprüfung sparen, dann ist klar dass es nur eine Operation gibt

 

[MrChance]

K3.meth() gibt dann 1, während die anderen 0 zurückgeben.

Vererbt wird mit dem Schlüsselwort "extend".
Bei einer Klasse macht das final ja auch Sinn.

Es gibt aber kein enum A extends B !

 

[MrChance]

Haaaa.. mir ist eine "mögliche" Erklärung eingefallen:
Final Methoden werden vom Compiler optimiert - und wenn
man ihm zu verstehen gibt, dass eine Methode nicht wie im
obigem Beispiel überschrieben werden kann, so kann er die
Optimierung durchführen.

Aber eigentlich müsste der Compiler ja selbst sehen, dass die
Methode nicht überschrieben wird und auch nicht durch Vererbung
überschrieben werden kann und automatisch eine Optimierung
durchführen !!!???

 

[SlaterB]

> mir ist eine "mögliche" Erklärung eingefallen

menno, das habe ich doch schon geschrieben

aber ich stimme dir zu, dass das ein schlauer Compiler sich selber erarbeiten könnte

 

[MrChance]

na ja, OK Ich habs aber schöner formuliert ;-)

Dennoch könnte es einen Anwendungsfall geben !!!!

 

[Roar]

*doofguck*
wenn meth final wäre, würde dein beispiel:

enum myEnum{
K1,
K2,
K3 { int meth() { return 1; };
(final) int meth() { return 0; }
}

nicht funktionieren, da meth() nicht in K3 üebrschrieben werden könnte, also hat hier final genauso seinen zweck wie bei normalen klassen, auch wenn eh niemand anderes, außer den enum konstanten, die methode überschreiben könnten.

 

[MrChance]

Hab ich ja weiter oben geschrieben: Wieso sollte ein Entwickler eine Methode final machen, wenn er sie überschreiben will ?

 

[Roar]

er will sie final machen, damit er sie nicht mehr überschreiben kann...

 

[MrChance]

...ah, das final ist gegen schizophrene Entwickler gedacht ? ;-)

Im Ernst: Wer oder wieso sollte jemand dies machen ???

 

[Roar]

wenn du nen paar hundert klassen hast, weißt du nach 1 jahr nicht mehr, dass du dir mal ganz fest vorgenommen hast die methode nicht zu überschreiben.
final darf man nicht nur in öffentlicher api verwenden.

 

[Guest]

Ich schätze mal, dass es eingebaut wurde, um zu verhindern, dass ein Programmteil ab einem bestimmten Zeitpunkt es nicht mehr verändert...

 

[MrChance]

mmm... das haben sich also die Sun-Leute dabei gedacht, als sie final für enums erlaubten ????

 

[MrChance]

sorry - final für enums ist natürlich nicht erlaubt, auch wenn sie per Definition schon nicht erweiterbar sind. Gemeint war natürlich final für Methoden in enums ! ;-)

 

[Yzebär]

aber ich stimme dir zu, dass das ein schlauer Compiler sich selber erarbeiten könnte

Wie sollte er das können? Er kann ja nicht hellsehen und weiß nicht, zu welchem Zeitpunkt welche Klasse geladen wird. Die Klasse, die eine bestimmte Methode überschreibt, kann ja später noch nachgeladen werden. Nur "final", "private" oder "static" garantieren, daß die Methoden nicht überschrieben werden können.

final gibt es aus mehreren Gründen. Zum einen, final Variablen oder Methoden werden in einem anderen Speicherbereich abgelegt, als dynamische Variablen oder überschreibbare Methoden, der JIT-Compiler, muß nicht mehr prüfen, ob sich Werte geändert haben oder welche (der überschriebenen) Methoden er aufrufen muß. In früheren JVMs hatte man dadurch auch noch Geschwindigkeitsvorteile. Die neuesten JITs können aber auch ohne final sehr gut optimieren.

Zum anderen weiß jemand, der den Sourcecode liest, daß eine Variable oder Methode nur einmal initialisiert bzw. deklariert wurde. Wird dennoch versucht etwas zu überschreiben oder einer final Variablen einen neuen Wert zuzuweisen, gibt es einen Kompilierfehler.

 

[SlaterB]

es geht hier doch um den speziellen Fall der Enums,
diese können nicht vererbt werden also hat der Kompiler den kompletten Quellcode und kann nachschauen ob eine der Enum-Elemente erbt oder nicht,

--------

final um Überschreiben zu verhindern, gerade auch wenn mehrere Programmierer an der Enum werkeln,
ist als Argument zu akzeptieren, aber nicht besonders stark,

gut, final wird überall in Java ähnlich eingesetzt, aber man sollte doch eher verstehen was man so tut,
kommentieren und Kommentare lesen usw.,
ist ein Java-Programmierer in anderen OO-Sprachen aufgeschmissen oder ist das überall Standard?

 

[MrChance]

Wir reden über Methoden in enums. (nicht Klassen)
enum Methoden können nur in der enum selbst überschrieben
werden.
Wenn der Entwickler seine Methoden nicht überschreiben will,
dann überschreibt er sie halt nicht. Wieso sollte er sie dann
noch final deklarieren ? (Ausser aus Performancegründen)

Oder ?

 

[Beni]

Vielleicht weil Enums vom Compiler kurzerhand in Klassen umgeschrieben werden, und es für die Entwickler einfacher war, final einfach zuzulassen ("final erlaubt" ist einfacher als "final erlaubt aber nur wenn..." :wink: )

 

[byte]

Wenn der Entwickler seine Methoden nicht überschreiben will,
dann überschreibt er sie halt nicht. Wieso sollte er sie dann
noch final deklarieren ? (Ausser aus Performancegründen)

Was ist denn das für ein Argument? Wenns danach geht, braucht man auch Methoden in Klassen nicht final deklarieren.

Klar liegt da der Nutzen eher auf der Hand, aber ich sehe auch keinen Grund, warum man final bei Enums explizit verbieten sollte. Der Nutzen ist gering aber existent, denn manchmal arbeiten auch mehrere Personen am selben Code.

Im Übrigen ist Performance (wie schon gesagt wurde) kein Faktor bei final Deklarationen mehr bei aktuellen VMs.

 

[SlaterB]

bei normalen Klassen hat man z.T. riesige Strukturen, die auch bis in alle Ewigkeit noch erweitert werden können,
wer kann schon bei Component, JComponent, Container usw. den Überblick behalten,

bin Enum ist das aber anders, Enums erben von niemanden und werden von niemanden geerbt,
da kann man das Argument 'bessere Übersicht, final nicht nötig' nicht ganz platt abschieben,

aber auch eine Enum kann groß werden,
kann monatelang nicht mehr bearbeitet worden sein,
kann von mehreren Programmierern bearbeitet werden,
insofern ist die Gemeinsamkeit mit anderen final-Anwendungen wirklich gegeben

 

[MrChance]

..ich glaub, der Beni hat schon ein wenig recht:
Die enums werden wohl in Klassen umgewandelt.
Und werden sie nicht aus der Klasse Enum abgeleitet ?

 

[SlaterB]

Die Umwandlung ist bei der Frage irrelevant,
und jede Klasse wird von Object abgeleitet, also erbt eh jederman.

Dennoch stimme ich auch zu, dss Beni ein wenig oder gar bisschen mehr recht hat.