final und Variablen

[Guest]

Gerade eben habe ich einen Artikel zu "Lucene with OJB" gelesen und dabei fallen mir
im Code des Authors ziemlich viele Variablen (innerhalb von Methoden) auf, die mit
final deklariert sind.
z.B.

public void add(final Student student) throws ServiceException {
  final Document doc = new Document();
  doc.add(Field.Text(NAME, student.getName()));
  doc.add(Field.Text(ID_NUMBER, student.getIdNumber()));
  doc.add(Field.Text(ADDRESS, student.getAddress()));
  doc.add(Field.Text(PHONE, student.getPhone()));
  doc.add(Field.UnIndexed(IDENTITY, student.getId().toString()));
  try {
    synchronized (mutex) {
      final IndexWriter writer = new IndexWriter(index, analyzer, false);
      writer.addDocument(doc);
      writer.optimize();
      writer.close();
    }
  }
  catch (IOException e) {
    throw new ServiceException("Unable to index student", e);
  }
}

In C++ war dieses Attribut immer dazu gedacht, Variablen bzw. Methodenargumente,
die "nicht verändert" werden, explizit zu kennzeichnen.
Dadurch war an manchen Stellen Pass-By-Reference unkritisch (statt Pass-By-Value).
Im obigen Code wird das Document-Objekt verändert, trotzdem ist es syntaktisch korrekt.

Was bringt dann "final" bei Methodenparametern bzw. lokalen Variablen innerhalb einer
Methode überhaupt, wenn diese trotzdem verändert werden?

Nur mal so ein Gedanke... :bahnhof:

 

[semi]

Mist, habe mich wieder nicht eingeloggt, bevor ich was geschrieben habe. :roll:

 

[Kaan]

Final kannst du an mehreren Stellen verwenden:

1. Du kannst explizit vorschreiben, dass eine Methode nicht abgeleitet werden kann.

2. Du kannst auch Variablen um Objekt mit final kennzeichnen, damit sie als Konstanten angesehen werden und man ihnen nur EIN EINZIGES MAL in ihrer gesamten Lebensdauer einen Wert zuweisen kann.

Wenn du ein Objekt mit final versiehst kannst du es nur allgemein vor Zuweisungen schützen, aber nicht die einzelnen Elemente des Objekts. z.B. du kannst einem als final deklarierten Array-Objekt nur einmal eine neue Instanz zuweisen, aber du kannst jederzeit einzelne Array-Elemente verändern.

Bei deinem Beispiel wurde das Document Objekt als final deklariert, trotzdem kannst du einzelne Werte durch add verändern/ hinzufügen. (denke ich zumindest)

 

[Beni]

Öhm, bei dieser Methode? Nö, praktisch kein Unterschied ob mit oder ohne.

"final" kann man vorallem für Konstante Zahlenwerte brauchen (oder auch einfach Variablen, die nicht auf andere Referenzen zeigen dürfen).

Und dann gibts noch den Trick, Methodenvariablen anonymen Klassen sichtbar zu machen.

Aber mehr fällt mir auch nicht ein (in Bezug auf Variablen).

 

[semi]

@Kaan & Beni
Klar, ich kenne die "typischen" Anwendungssfälle. Nur der Code des Authors machte mich etwas
nachdenklich. Irgendwie "Hab' ich was verpasst?" :wink:
Ich sehe eigentlich nur die folgende Anwendungen dafür.

Konstanten

public static final int CENTER = 1;

Methoden (entweder um das Überschreiben zu verhindern oder bestimmte Abläufe zu erzwingen; Typisch für Frameworks)

public final void doSomething() {
  preProcessing();
  reallyDoSomething();
  postProcessing();
}

protected abstract void reallyDoSomething();

Klasse (Klasse nicht mehr überschreibbar)

public final class Foo

Anonyme Klassen (hier wohl die häufigste Anwendung)

final JFrame frame = ....;
frame.addWindowListener(
  new WindowAdapter() {
    public void windowClosing(WindowEvent e) {
      frame...
    }
  }
);

Strings als Parameter an Methoden (Keine Kopie sondern Referenz; nur bei String sinnvoll?)

public void doSomething(final String s)

Gerade der letzte Fall ist die einzige mir bekannte Anwendung von final bei
Methodenparametern, die Sinn macht. Ohne final wird der String kopiert.
Mit final wird die Referenz übergeben. Alle anderen Objekte werden sowieso By-Reference
übergeben, daher macht es keinen Sinn.

Was meint Ihr?

 

[stev.glasow]

Nicht zu vergessen sind die 'privaten' Instanzvariablen die keinen Setter haben, die kann man eigentlich immer final setzen.
[edit] und natürlich soetwas:

public static final int TOP = 1;
public static final int BUTTOM = 2;

[edit]
achja

final FooBar fb = ...;
AClass ac = new AClass(){
    public void foo(){
          fb.bla();
    }
}

 

[bygones]

In C++ war dieses Attribut immer dazu gedacht, Variablen bzw. Methodenargumente,
die "nicht verändert" werden, explizit zu kennzeichnen.

Wenn die Variable nicht explizit für den Zugriff auf einen innere / anonyme Klasse benötigt wird halte ich das in Java für den Gleichen Zweck wie in C++ !

 

[semi]

@deathbyaclown
Am besten zeige ich an einem Beispiel, was ich meine.

C++

class A {
  private:
    int value;
  public:
    A():value(0) {
    }
    void setValue(int v) {
      value=v;
    }
};

void test(const A a) {
  a.setValue(1);
}

int main() {
  A a;
  test(a);
  return 0;
}

Java

public class Final {
  static class A {
    private int value;
    public A() {
      value = 0;
    }
    public void setValue(int v) {
      value = v;
    }
  }

  private static void test(final A a) {
    a.setValue(1);
  }

  public static void main(String argv[]) {
    A a = new A();
    test(a);
  }
}

In C++ kriegst Du es wegen dem "const" nicht mal compiliert.
In Java wird's akzeptiert, ohne dass das "final" etwas bewirken würde.

Gruß,
Michael

 

[bygones]

danke semi, mir ist C++ mittlerweilen auch ein Begriff *g

ich weiß dass die beiden "final" unterschiedlich gewichten (siehe dein Bsp) - final Objekte in Java heißen nicht gleich das Objekt ist immer gleich (siee dein Bsp *g).... dennoch weißt du dass das Objekt "a" in deinem Bsp nie ein anderes Objekt der Klasse "A" sein kann, das neue zuweisen nämlcih geht nicht....

PS: ist gutes Bsp - ähnliches prinzip tritt auf bei final arrays... (habe mal nen FAQ beitrag dazu geschrieben)... wenns dir recht ist würde ich dein bsp da mitaufnehmen ?!

 

[semi]

ich weiß dass die beiden "final" unterschiedlich gewichten (siehe dein Bsp) - final Objekte in Java heißen nicht gleich das Objekt ist immer gleich (siee dein Bsp *g).... dennoch weißt du dass das Objekt "a" in deinem Bsp nie ein anderes Objekt der Klasse "A" sein kann, das neue zuweisen nämlcih geht nicht....

Mit const in C++ sagt man, dass das Objekt nicht verändert wird. Ich meine nicht, dass man die Referenz des Objektes ändert. Dies wäre etwas ganz anderes (Referenzpointer) und ist in Java nicht möglich.
z.B.

#include <iostream.h>

class A {
  private:
    int value;
  public:
    A():value(0) {
    }
    void setValue(int v) {
      value=v;
    }
    int getValue() {
      return value;
    }
};

typedef A* PtrA;

void test(PtrA &a) { // & bedeutet Referenz eines Zeigers auf A
  a->setValue(2); // ursprüngliches Objekt ändern
  a = new A();      // der Referenz ein anderes Objekt zuweisen
}

int main() {

  PtrA a = new A(); // Eine Instanz von A erstellen
  PtrA b = a;       // diese auh dem anderen Zeiger zuweisen

  test(a); // Die Referenz! ändern

  // Die Zeiger zeigen auf unterschiedliche Objekte
  cout << a->getValue() << endl; // Ausgabe 0;
  cout << b->getValue() << endl; // Ausgabe 2; Dies ist das ursprüngliche Objekt

  return 0;
}

OK, Zeiger aus C++ vermisse ich aber nicht :bae::wink:

wenns dir recht ist würde ich dein bsp da mitaufnehmen ?!

Klar, mach' nur. :wink:

Gruß,
Michael

 

[Bleiglanz]

Gerade der letzte Fall ist die einzige mir bekannte Anwendung von final bei
Methodenparametern, die Sinn macht. Ohne final wird der String kopiert.
Mit final wird die Referenz übergeben. Alle anderen Objekte werden sowieso By-Reference
übergeben, daher macht es keinen Sinn.

Das ist falsch, es wird immer die Referenz übergeben. Der Sinn von final bei Methodenparametern ist nur, dass man sich beim programmieren selbst davor schützen möchte, übergebene Referenzen versehentlich zu ändern.

 

[Isaac]

checkstle, ein Plugin für Eclipse, zeigt dir Variablen an wenn diese nur initialisiert aber nie geändert werden und nicht final sind.

Final bringt in diesem Fall rein garnichts (also keine Performance oder sowas in der Art). Der Code liest sich einfacher wenn man weiss das diese Variable ihren Wert nie ändert.

 

[Guest]

@Bleiglanz
Stimmt nicht ganz. Strings werden immer kopiert, wenn man dies nicht mit final unterbindet.
Lass mal einen Debugger drüberlaufen, der die Adressen der Strings anzeigt, dann siehst
Du, was passiert.

Gruß,
Michael (semi)

 

[Bleiglanz]

@Gast

Versteh ich nicht??

Die Semantik von Objekten ist so, dass bei Funktionsaufrufen immer "die Referenz" übergeben wird (da braucht man gar nicht weiter drüber nachdenken)

Aber: es gibt sog. "immutable Objekte" (und da gehören Strings dazu, die werden noch dazu von der JVM besonders behandelt), die werden nicht "kopiert ", sondern bei jeder Änderung neu erzeugt [das ist was ganz anderes]

Frage: kannst du mir einen Aufruf konstruierenm in dem "false" rauskommt, wenn die Funktion mit identischen Argumenten foo(x,x) aufgerufen wird?

    public static void foo(String a, final String b)
    {
        System.out.println("a ist b: "+(a==b));
    }

 

[semi]

@Bleiglanz
OK, meine letzte Antwort war Quatsch. Ich muss im Debugger irgendwie die Adressen
zweier Variablen verwechselt haben.

Das C++ Beispiel von mir ist ebenfalls nicht das gleiche wie in Java.
Vergleich Java-C++

void test(A a)       entspricht       void test(A* a)
void test(final A a) entspricht       void test(A* const a)
void test(final A a) entspricht NICHT void test(const A* a)

A a = new A(); entspricht       A *a = new A(); in C++
A a = new A(); entspricht NICHT A a; in C++

A a;
test(a);  // Ein Objekt A über den Stack übergeben
test(&a); // Referenz von A über den Stack übergeben

A *a = new A() ;
test(a);  // Referenz bzw. Zeiger auf A über den Stack übergeben (so passiert's in Java)
test(&a); // Referenz eines Zeigers auf A über den Stack übergeben

Kurz gesagt, Objekt auf Heap oder über den Stack, das war der Unterschied. :roll:

Eines bleibt aber ungeklärt. Was bringt final bei Methodenparametern?
(Much quack about nothing)

 

[Bleiglanz]

Eines bleibt aber ungeklärt. Was bringt final bei Methodenparametern?

Der Sinn von final bei Methodenparametern ist nur, dass man sich beim programmieren selbst davor schützen möchte, übergebene Referenzen versehentlich zu ändern.

Viele Leute haben Methoden mit tausenden Zeilen (leider) und da ist es ganz praktisch, wenn man nicht irgendwo versehentlich ein übergebenes Argument überschreibt - das ist IMHO eine reine Complile-time Geschichte?

 

[semi]

Yepp so ist es. Ich habe nicht daran gedacht, da ich grundsätzlich
nie einem Methodenparameter irgendwelche neuen Instanzen von
Objekten zugeweise.

Thema erledigt. :roll:

Gruß,
Michael