API-Design. Kai SpichaleЧитать онлайн книгу.

       2.2.6Schwer falsch zu benutzen

      Eine API sollte nicht nur einfach zu benutzen, sie sollte sogar schwer falsch zu benutzen sein. Daher sollte man nicht offensichtliche Seiteneffekte vermeiden und Fehler zeitnah mit hilfreichen Fehlermeldungen anzeigen. Benutzer sollten nicht gezwungen sein, die Methoden einer API in einer fest definierten Reihenfolge aufzurufen.

       Unerwartetes Verhalten

      Die ursprüngliche Datums- und Zeit-API von Java sieht auf den ersten Blick einfach und intuitiv aus. Doch schon bei einfachen Beispielen stolpert man über ein Verhalten, das man vermutlich nicht erwartet. Was das bedeutet, wollen wir uns an einem Beispiel anschauen:

      Die ursprüngliche Datums- und Zeit-API von Java lädt geradezu dazu ein, Fehler zu machen. Den 20. Januar 1983 würde man vermutlich so definieren wollen:

      Date date = new Date(1983, 1, 20);

      Leider enthält diese Codezeile gleich zwei Fehler. Denn die Zeitrechnung dieser API beginnt unerwarteterweise im Jahre 1900. Außerdem sind die Monate beginnend mit 0 durchnummeriert. Die Tage werden beginnend mit 1 angegeben. Deswegen muss der 20. Januar 1983 folgendermaßen erzeugt werden:

      int year = 1983 – 1900;

      int month = 1 - 1;

      Date date = new Date(year, month, 20);

      Im nächsten Schritt geben wir zusätzlich noch die Uhrzeit 10:17 mit der Zeitzone von Bukarest an. Die Uhrzeit soll schließlich in einen formatierten String umgewandelt werden. Weil die Klasse Date keine Zeitzonen unterstützt, müssen wir ein Calendar-Objekt erzeugen. Die erwartete Ausgabe ist »20.01.1983 10:17 +0200«.

      Date date = new Date(year, month, 20, 10, 17);

      TimeZone zone = TimeZone.getInstance("Europe/Bucharest");

      Calendar cal = new GregorianCalendar(date, zone);

      DateFormat fm = new SimpleDateFormat("dd.MM.yyyy HH:mm Z");

      String str = fm.format(cal);

      Auch hier verstecken sich mehrere Fehler: Der Konstruktor der Klasse GregorianCalendar akzeptiert eine Zeitzone, aber kein Date-Objekt. Der Calendar kann nicht von SimpleDateFormat formatiert werden. Auch SimpleDateFormat muss die Zeitzone übergeben werden. Durch Angabe der Zeitzone wird die Uhrzeit verändert. Der korrigierte Clientcode sieht so aus:

      int year = 1983 - 1900;

      int month = 1 - 1;

      // weil 1 Stunde Zeitunterschied zwischen Berlin und Bukarest

      int hour = 10 - 1;

      Date date = new Date(year, month, 20, hour, 17);

      TimeZone zone = TimeZone.getInstance("Europe/Bucharest");

      Calendar cal = new GregorianCalendar(zone);

      cal.setTime(date);

      DateFormat fm = new SimpleDateFormat("dd.MM.yyyy HH:mm Z");

      fm.setTimeZone(zone);

      Date calDate = cal.getTime();

      String str = fm.format(calDate);

      Aufgrund dieser Fallstricke entstand in der Java-Community die Bibliothek Joda-Time. Der Clientcode könnte folgendermaßen aussehen:

      DateTime dt = new DateTime(1983, 1, 20, 10, 17,

      DateTimeZone.forID("Europe/Bucharest"));

      DateTimeFormatter formatter

      = DateTimeFormat.forPattern("dd.MM.yyyy HH:mm Z");

      String str = dt.toString(formatter);

      Ein anderes nicht unbedingt intuitives Feature ist die Möglichkeit, mehr als 60 Sekunden, mehr als 24 Stunden usw. bei der Erzeugung eines Date-Objektes anzugeben. Statt einer Fehlermeldung wird der Überhang korrekt berechnet. Durch eine Angabe von beispielsweise 25 Stunden wird der nächste Tag 1 Uhr ausgewählt. Dieses Verhalten ist nicht offensichtlich und könnte deswegen zu Fehlern führen.