Alle Variablen final setzen ?

[delphiking1980]

Hallo,

diesmal eine Allgemeine Frage, ich arbeite jetzt in einer Firma wo Sie wirklich alle Variablen final setzen wo sie nur können aber keiner kann mir sagen was der sinn ist nur halt "Das machen wir schon immer so" und solche floskeln.

Gibt es einen größeren Sinn dahinter ??


Mfg

Delphiking1980

 

[irgendjemand]

"FINAL" wird verwendet wenn eine variable einmal initialisiert aber nicht mehr geändert werden darf ...

wird meist in methoden-signaturen verwendet ... aber an sich hat das keinen größeren sinn und zeugt davon das das mal wer eingebracht hat der sich in solch lustigen büchern die sich "code-optimierungen" und so schimpfen etwas missverstanden hat ...

allgemein hin könnte man aber sagen das man FINAL nur in konstanten und spezielle "variablen" einsetzen sollte welche vor änderung geschützt werden sollen ... was aber auch wiederum gegen OOP spricht und vermutlich aus der C/C++ ecke stammt

 

[delphiking1980]

so sehe ich das auch nur es wunderte mich halt das wirklich alle möglichen Variablen final gesetzt werden ohne das Sie aber auch großgeschrieben werden denn das ist jawohl auch ein teil der Java Beans konvention oder ?

 

[ARadauer]

Grundsätzlich machen das einige Teams bei uns auch so. Ich finde es aber übertrieben.

 

[bygones]

allgemein hin könnte man aber sagen das man FINAL nur in konstanten und spezielle "variablen" einsetzen sollte welche vor änderung geschützt werden sollen

nein - final fuer Methoden bei Vererbungen ist ein maechtiges und sehr sinnvolles Instrument. Man kann somit genau steuern, welche methoden subklassen ueberschreiben duerfen und welche sie die Finger von lassen sollen.

fuer Variablen nehm ich sie nur wenn ich vom compiler gezwungen werde.

EDIT: ausser bei Instanzvariablen, da sollte man soweit wie moeglich final nutzen

 

[delphiking1980]

es geht nicht um Methoden sondern Variablen !!

 

[tfa]

es geht nicht um Methoden sondern Variablen !!

Welcher Art?
Methoden-Parameter, Member-Variablen, lokale Variablen?

 

[delphiking1980]

Methoden Parameter, Member Variablen und lokale Variablen quasi alles was möglich ist.
Meine Meinung ist da hat wirklich jemand nicht weitgenug gedacht und der Rest des Teams ist nicht fähig genug dieses der Person schonend bei zu bringen..... Aber es gibt noch viele mehr Punkte die wirklich ungereimt sind.

 

[bygones]

Methoden Parameter, Member Variablen und lokale Variablen quasi alles was möglich ist.
Meine Meinung ist da hat wirklich jemand nicht weitgenug gedacht und der Rest des Teams ist nicht fähig genug dieses der Person schonend bei zu bringen..... Aber es gibt noch viele mehr Punkte die wirklich ungereimt sind.

das klingt nun etwas sehr ausladend... das final stoert niemanden und hat einen Sinn, dass sichergestellt wird, dass diese Variable sich nicht mehr aendert. Fuer Instanzvariablen ist dies ein Vorteil (siehe immutable). Fuer lokale vielleicht nicht so, aber es ist bei weitem nicht "nicht weitgenug gedacht".

 

[tfa]

Man kann darüber streiten, ob es für Methoden-Parameter sinnvoll ist.
Bei Membern hat ein final einige (teilw. theoretische) Vorteile, wie bessere Optimiermöglichkeiten für Compiler bzw. JIT, Threadsicherheit (Stichwort immutable) etc.

Aber es gibt noch viele mehr Punkte die wirklich ungereimt sind.

Welche sind das, bzw. was spricht alles dagegen? Mal abgesehen davon, dass man das [c]final[/c] eintippen muss und es den Code aufbläht?

 

[delphiking1980]

nagut dann nennen es wir da wollte einer auf nummer sicher gehen und vertraut sich und den anderen nicht.... :lol:

 

[Tomate_Salat]

Welche sind da, bzw. was spricht alles dagegen? Mal abgesehen davon, dass man das final eintippen muss und es den Code aufbläht?

Nope nichtmal, dass müsste man alles Eclipse überlassen können. Bei mir ist es aber lediglich so eingestellt, dass Parameter final sind (ist das einzige, wo ich mir 100% sicher bin, dass ich das final da stehen haben möchte). Den Rest mache ich händisch (aber auch nur wenn nötig). Wenn es Betriebskonvention ist, überall ein final zu setzen wo es möglich ist, würde ich es über die Save-Actions von Eclipse lösen.

 

[tfa]

Save-Actions

Richtig. die gibt's ja auch noch. Bleibt also nur der geringfügig aufgeblähte Quelltext als Nachteil.

 

[Beni]

Ich bin ja vielleicht altmodisch... aber wenn man aus Versehen die falschen Variablen überschreibt, sollte man vielleicht einfach etwas [STRIKE]sorgfältiger[/STRIKE] sauberer programmieren. Das behebt dann auch gleich all die anderen Probleme die der sonst erzeugte Spaghetticode mit sich bringt. ueh:

 

[maki]

Richtig. die gibt's ja auch noch. Bleibt also nur der geringfügig aufgeblähte Quelltext als Nachteil.

Dieser Nachteil wiegt imho recht schwer, ist aber auch Gewohnheitssache, wenn das immer so gemacht wird ist das kein Problem.

Die Vorteile sind recht offentsichtlich, zumindest wenn man final verstanden hat.

 

[tfa]

aber wenn man aus Versehen die falschen Variablen überschreibt, sollte man vielleicht einfach etwas sorgfältiger sauberer programmieren.

Das ist ein Totschlagargument (ob nun sorgfältiger oder sauberer). Dann kannst du auch sagen, man braucht keine Unittests, wenn man sauber programmiert.

 

[Marco13]

Auf die Performance hat das final in der Praxis wohl kaum Einfluß. Bei Members verwende ich es üblicherweise auch. Es ist dann einfach ein klares, designtechnisches Statement:
private final List<String> names;
Die Liste wird im Konstruktor erstellt, und dann NIE mehr verändert. (Eine Ausprägung des Bloch'schen Mantras "Minimize Mutability"). Bei Methodenparametern wäre es eigentlich "stilistisch gut", aber subjektiv fände ich es "stilistisch besser" Methodenparameter nicht explizit final zu machen, sondern sie aus Prinzip einfach nicht zu verändern (man kann dafür Ecplise sogar eine Warnung generieren lassen, und das ist wohl nicht verkehrt). Aber bei lokalen Variablen noch final dazu ... hm... Das ist weder ein designtechnischer Aspekt, noch ein stilistischer, und ob's übersichtlicher wird... naja... :bahnhof:

 

[x22]

Hmm.. final das ist immer so eine Sache. Ich würde sagen, manchmal muss es sein, da man sonst etwas weiter gibt und irgendein Dep* meint eine Variable umdefinieren zu müssen... grade in größeren Projekten..andernfalls ist es gewohnheitssache.. ich mag es auch nicht, finde das ein unnötiges Wort.. aber muss jeder selber wissen.

Fazit: Manchmal ein muss, häufig Spielerei..

Best regards,
x22

 

[Andgalf]

In Verbindung mit OR-Mappern kann final vor Member-Variablen sogar Probleme verursachen.

 

[bygones]

In Verbindung mit OR-Mappern kann final vor Member-Variablen sogar Probleme verursachen.

was kein gegenargument ist wenn man kein OR mapper hat....

 

[mvitz]

was kein gegenargument ist wenn man kein OR mapper hat....

Und selbst, wenn man einen ORM Mapper nimmt, kann man immer noch, wann immer es geht die Variablen mit final deklarieren (bei den Entities geht das dann halt einfach nicht ;-) )

 

[maki]

In Verbindung mit OR-Mappern kann final vor Member-Variablen sogar Probleme verursachen.

Nicht nur mit ORM, auch mit DI Frameworks, wenn zB. in felder injiziert wird, dann kann zwar final dabeistehen, ist es aber effektiv nicht.

final gibt ein paar Garantien, u.a. dass jeder Thread den "gleichen final Wert sieht", das ist schlicht nicht gegeben in solchen Fällen.
Das Problerm ist nicht final, sondern schlicht dass es "gelogen" ist in solchen Situationen, muss man aber Wissen als Entwickler und die Framework Hersteller verheimlichen das auch nicht.

Injections - google-guice - How Guice initializes your objects - Guice (pronounced 'juice') is a lightweight dependency injection framework for Java 5 and above, brought to you by Google. - Google Project Hosting

..
Avoid using field injection with final fields, which has weak semantics.

 

[reNur]

Naja, das was Bloch über Klassen sagt:

Classes should be immutable unless there's a very good reason to make them mutable....If a class cannot be made immutable, limit its mutability as much as possible

sollte doch auch für Variablen gelten oder? Also erstmal alle Variablen von Haus aus final setzen, und nur wenn ich mir sicher bin, dass ich sie noch verändern muss, mache ich sie mutable. Ich mach das zwar auch nicht immer so, aber ich glaube es wäre kein schlechter Weg. Besonders Probleme mit Threadsicherheit geht man so schon von Anfang an aus dem Weg (auch wenn man bei Beginn nie daran gedacht hätte, dass der Code mal in einem Multuthreaded-Programm genutzt wird...).

 

[maki]

Blochs Aussage ist mir persönlich zu allgemein, Eric Evans ist da spezifischer.
ValueObjects, also Objekte deren Identität nur von ihrem Wert abhängen (String, Money, etc. pp.) sollten immutable sein.
Entites, also Objekte die eine Identität unabhängig von ihrem Wert haben (wie zB. Person, etc. pp.) müssen natürlich mutable sein, aber nicht komplett.
Entites kann man ja zum Teil aus ValueObjects zusammensetzen, zB. der Name einer Person kann/soll ein Immutable String sein.

 

[Andgalf]

Und selbst, wenn man einen ORM Mapper nimmt, kann man immer noch, wann immer es geht die Variablen mit final deklarieren (bei den Entities geht das dann halt einfach nicht ;-) )

Das ist natürlich korrekt !

Allerdings heißt der Thread ja alle Variablen final setzen. Deshalb dachte ich, ich werf das mal ein

 

[delphiking1980]

aber dann müsste doch jede Variable Groß geschrieben werden oder ??

 

[bygones]

aber dann müsste doch jede Variable Groß geschrieben werden oder ??

Konstanten schreibt man gross, eine rein finale Variable (nicht statisch) ist keine Konstante