Bessere Schnittstellen

Letztens hatte ich in einer Klasse eine Methode überschrieben, um zu verhindern, das ein bestimmter Wert unterschritten wird.

public class FontPreviewPanel extends JPanel {
 ...
  @Override
  public void setSize(Dimension d)
  {
    if (d.width <= 0)
      d.width = 1;
    if (d.height <= 0)
      d.height = 1;
    super.setSize(d);
  }
}

Die Maßnahme zeigte auch seine gewollte Wirkung. Doch dann fiel mir noch ein, dass die Super-Klassen ein weiteres setSize besitzen:

public void setSize(int width, int height);

Muss ich mir da jetzt Sorgen machen? Weiterlesen

Objekte anstatt Null-Referenzen

Können Sie sich noch an den Milliarden-Dollar-Fehler von Tony Hoare erinnern?

Jedenfalls bringt die Null-Referenz (in C++ der Null-Zeiger) viele Programmierer zur Verzweiflung. Denn man tappt immer wieder in die Falle, das eine Referenz Null sein kann. Wenn man diese nicht vor der Benutzung prüft, gibt es einen Absturz. Und dieser Fehler führte weltweit seit seiner Erfindung zusammen gerechnet wohl zu eine Milliarde-Dollar Kosten.

Sie erleben den Fehler und umgehen diesen deshalb so oder ähnlich:

void bar(Type r) {
   if(r != null)
      r.foo();
}
TypeList r = search();
if(r != null)
   r.foo();

Die if-Abfragen sind doch unnötiger Ballast und haben nichts mit der eigentlich zu lösenden Aufgabe (Algorithmus) zu tun. Diese if-Abfragen machen nur deutlich, dass die API oder Programmiersprache anscheinend nicht vertrauenswürdig genug ist. Überall sind diese „Stützräder“ und machen den Code unleserlicher und lenken vom eigentlichen Code ab. Weiterlesen

Der Milliarden-Dollar-Fehler

Kennen Sie Prof. Antony Hoare? Nein? Aber Sie kennen sicherlich Null Pointer Exceptions bzw. Null Reference Exceptions? Jeder von uns hat Angst vor diesem Fehler, denn jedem ist schon mehrmals dieser Fehler unterlaufen und passiert immer wieder. Oder hat einen in anderen Programmen in den Wahnsinn getrieben. Es dürfte der Fehler Nr. 1 in der Software-Entwicklung sein. Weiterlesen

Java – immutable Objects

Wenn wir Software entwickeln, ist eines unserer Ziele unvorhersehbare Seiteneffekte zu vermeiden. Ich war mal vor knapp zehn Jahren in einem Projekt, in dem ein Kollege bei aufgetauchten Fehlern im System zum Auftraggeber sagte „Oh! Das ist leider ein Seiteneffekt.“. Irgendwann meinte der Auftraggeber genervt „Ich will das Wort Seiteneffekt nicht mehr hören!“.

Wie kann man solche Fälle minimieren? Ein Punkt ist die richtige Datenkapselung, wie ich hier bereits zeigte. Ein weiterer Punkt ist, Daten einfach unveränderlich zu machen. Denn wodurch entstehen mysteriöse Seiteneffekte? Wenn sich Objekte im Wert ändern, ohne das man es selbst veranlasst oder mitbekommen hat! Weiterlesen

Javas kaputte Datenkapselung

Meiner Erfahrung nach werden in Objekt-Orientierungs-Diskussionen folgende drei Punkte genannt, auch in dieser Priorität, die die Objektorientierung ausmachen sollen:

  1. Vererbung von Klassen
  2. Schnittstellen
  3. Kapselung

Ist Vererbung wirklich das was Objektorientierung ausmacht? Immerhin ist Vererbung nicht bei jeder Klasse notwendig, sondern nur von Fall zu Fall nötig. Streichen wir also den ersten Punkt von unserer Liste!

Die Schnittstellen, also Funktionen einer Klasse, ermöglichen die Kommunikation mit dem Objekt. Die Klasse kapselt ihre Eigenschaften (Daten) und ermöglicht nur über die Schnittstellen den Zugriff auf die Eigenschaften. Die Daten sollen vor direkter Manipulation geschützt werden, um eine Blackbox zu simulieren.

Ich sehe regelmäßig Java-Code, in dem die Blackbox-Regel gebrochen wird. Viele Programmierer meinen, wenn sie die Daten einer Klasse als Privat deklarieren, ist alles gut.

Weiterlesen