THE FINAL COUNTDOWN – DER FINAL-MODIFIER IN JAVA

Das final Keyword hat eine Reihe von Bedeutungen in Java und fristet leider zu oft ein „Außenseiterdasein“ bei vielen ProgrammiererInnen. Dabei ist es sehr nützlich, um Fehler zur Compile-Zeit auszuschließen, die sonst erst zur Laufzeit auffallen würden (also erst bei Tests oder schlimmer – beim User). Man kann sowohl viele NullPointerExceptions als auch eine ganze Reihe von logischen Fehlern, die durch nicht berücksichtigte Programmpfade entstehen frühzeitig entdecken.

Außerdem forciert die umfassende Verwendung von final einen sauberen Programmierstil, da mutable state, also sich über die Zeit verändernde Zustände von Variablen und Objekten minimiert wird. Dadurch wird es schwerer „Spaghetticode“ zu schreiben.

final als Modifier für Klassen

Diese Verwendung soll hier nur der Vollständigkeit halber aufgeführt werden. Deklariert man eine Klasse final, kann von ihr nicht mehr abgeleitet werden. In 14 Jahren Java Entwicklung habe ich hierfür noch keinen wirklich nützlichen Anwendungsfall erlebt. Nützlich nur für aussagelose Einstellungs-Quizfragen.

public final class ICannotBeExtended { 
//... 
}

public class UnwantedChild extends ICannotBeExtended { 
  // won't compile 
}

final als Modifier für Member

Nun aber zu den wirklich nützlichen Anwendungsfällen für final. Deklariere ich einen Member als final, kann sich sein Wert nach der Zuweisung nicht mehr ändern. Meistens findet man dies aber leider nur, um Konstanten zu definieren:

public static final int MAGIC_NUMBER = 42;

Man kann aber auch nicht-statische member als final deklarieren. Auch muss man nicht bei der Deklaration sofort einen Wert angeben:

private final int importantId;

Was hat man dadurch gewonnen? Nun, der Compiler passt von nun an für uns auf, dass in jedem Constructor wirklich alle final Member gesetzt werden. So kann es nicht passieren, dass jemand (meistens man selbst) zu einem späteren Zeitpunkt einen Konstruktor hinzufügt, der vergisst, einen wichtigen Wert zu setzen:

public class MyImportantClass { 

  private final int importantId; 
  private final String foo; 
  private final String bar; 

  /** Proper Constructor that leaves the constructed object  
  * in a valid state. 
  */ 
  public MyImportantClass (final int importantId, final String foo, final String bar) {

    this.importantId = importantId; 
    this.foo = foo; 
    this.bar = bar; 
  } 

  /** 
  * I read somewhere that every Java class needs an 
  * empty constructor because Beans are a pattern. DERP! */ 
  public MyImportantClass() { 
    //won't compile, the day is saved! 
  } 
}

Man kann also bei der Deklaration der member sicher stellen, dass ein für das korrekte Funktionieren des Objekts notwendiger Wert einfach unter den Tisch gekehrt wird.

final als Modifier für Funktionsparameter und lokale Variablen

Benutzt man final als Modifier für Funktionsparameter und lokale Variablen, ist der Effekt ähnlich wie bei Membern: Der Compiler achtet nun für uns darauf, dass eine Variable nicht benutzt wird, ohne dass sie initialisiert wurde.

final String foo; 
if (magicBool) { 
  foo = getVitalString(); 
} 
if (foo.length > 5) { 
  // won't compile, foo might not be initialized 
}

Bei so einem trivialen Beispiel mag das noch nicht nützlich sein, wird der Workflow aber komplizierter, kann final einem viele Stunden nerviger Fehlersuche ersparen. Zwar helfen einem die NullPointer-Warnings moderner IDEs heutzutage auch oft gegen diesen Fall. Nur müssen die auch aktiviert sein und gelesen werden. Nicht jede(r) EntwicklerIn sorgt dafür, dass der Code warning-free ist. Oft geht die wichtige NPE-Warnung in der Kakophonie der Warnings still und leise unter. Das folgende ist leider ein häufiges Idiom:

List foo;
// or worse: List foo = null;
if (someValue > 10) { 
  foo = new ArrayList<>(); 
} else if (someValue < 10) { 
  foo = new LinkedList<>(); 
} 
// will happily compile & crash your App if someValue == 10 
foo.size();

Setzt man nun foo auf final, ist man gezwungen, foo für alle Wege durch den Code zu initialisieren.

final List foo;
if (someValue > 10) { 
  foo = new ArrayList<>(); 
} else if (someValue < 10) { 
  foo = new LinkedList<>();
} 
// will not compile, you need an else clause 
foo.size();

Zwar kann man nun foo auch im else – Zweig auf null initialisieren, aber dann grenzt es schon an mutwillige Zerstörung.

Vermeiden von NullPointerExceptions mit final

Mit zwei Änderungen des Programmierstils kann man nun einen sehr großen Teil der möglichen NullPointerExceptions in seinem Code vermeiden:

• gewohnheitsmäßig erstmal alles final deklarieren, nur weglassen wenn es wirklich notwendig ist
• Wenn irgend möglich nie null zuweisen oder zurückgeben