Workshop "Das Projekt Datum"

1. Die Methode getDateString()

Beginnen wir mit dem ersten Modul unserer Anwendung, einer Klasse Date. Die Objekte dieser Klasse sollen ein Datum der Form TT.MM.JJJJ nicht einfach nur speichern können, sondern auch die Korrektheit dieses Datums überprüfen können. Daten wie der 31.02.2025 würden dann nicht akzeptiert werden, weil der Februar in einem Nicht-Schaltjahr nur 28 Tage hat. Ein Datum wie der 13.13.2013 würde natürlich auch nicht akzeptiert werden, da es nur 12 Monate im Jahr gibt.

Version 1:
Instanzvariablen, Konstruktor, Setter-Methoden

Dieser Quelltext zeigt eine erste Version der Klasse Date. Die Objekte dieser Klasse besitzen drei Instanzvariablen, die die Attribute Tag, Monat und Jahr repräsentieren: day, month und year, alle drei vom Typ int. Bei der Erzeugung eines neuen Date-Objektes werden die drei Attributwerte in Form von int-Parametern übergeben. Die Zuweisung der Parameter-Werte an die Instanzvariablen wird dann aber nicht vom Konstruktor selbst übernommen, sondern an die drei Setter-Methoden delegiert.

Wir haben jetzt also eine ganz einfache Klasse Datum erstellt, mit der neue Objekte erzeugt werden können. Allerdings führt der Konstruktor beim Erzeugen neuer Datums-Objekte noch keinerlei Überprüfungen durch. Er übergibt den Parameter tag einfach an die Setter-Methode setTag(). Es ist also durchaus möglich, ein Datum wie den -13.14.5000 zu erzeugen. Mit getTag() würden Sie dann den Wert -13 erhalten.

Version 2

Die drei Setter-Methoden liegen in der Version 1 erst in einer Art "Rohfassung" vor. Ihre Aufgabe ist es nun, die Setter-Methoden so zu ändern, dass sie eine erste Überprüfung der Daten vornehmen und ungültige Werte entweder abweisen (Fehlermeldung und Abbruch) oder "passend machen".

Mit "passend machen" ist gemeint: Wenn jemand eine negative Tageszahl oder Monatszahl eingibt, wird der Wert auf 1 gesetzt, und wenn jemand eine zu große Zahl eingibt, wird der Wert auf die größte Tageszahl (31) oder auf die größte Monatszahl (12) gesetzt. Es erfolgt dann keine Fehlermeldung, und das Programm bricht nicht ab, sondern arbeitet mit dem passend gemachten Wert weiter. Aus dem falschen Datum -13.14.5000 würden die Setter-Methoden also das korrigierte Datum 1.12.2500 erzeugen, falls Sie festgelegt haben, dass 2500 die maximale Jahreszahl ist.

public class TesteDatum
{
    DatumsAusgabe konsole;
    
    public TesteDatum()
    {
        konsole = new DatumsAusgabe();
        konsole.ausgeben(new Datum(17,10,2025));
        konsole.ausgeben(new Datum(17,13,2025));
        konsole.ausgeben(new Datum(34,13,2025));
        konsole.ausgeben(new Datum(-5, 0,2025));
    }
}						

Exkurs: Das Prinzip der alleinigen Verantwortung

Das sogenannte Single Responsibility Principle (SRP) besagt ungefähr Folgendes: Ein Modul (also in Java eine Klasse) sollte eine einzige Verantwortung haben. Umgekehrt sollte jede Verantwortung nur durch ein Modul implementiert werden.

Die Ausgabe des Datums hatten wir bereits in die Klasse DatumsAusgabe ausgelagert. Aber die Klasse Datum hat noch mehrere Verantwortungen: Sie verwaltet einmal die Instanzvariablen tag, monat und jahr mit den entsprechenden Setter-Methoden. Statt normaler Getter-Methoden hatten wir dann eine sondierende Methode getDatumString() implementiert. Das ist auch noch in Ordnung, solange es bei der Ausgabe TT.MM.JJJJ bleibt. Wenn aber auch andere Datums-Formate gewünscht sind, müssten wir die Klasse Datum um entsprechende weitere Methoden ergänzen, was aber nicht im Sinne des SRP ist.

Daher die nächste Aufgabe:

Version 3

Damit das Ganze funktioniert, müssen Sie die Klasse Datum noch mit drei Getter-Methoden für den Tag, den Monat und das Jahr ausstatten. Die alte sondierende Methode getDatumString() kann dagegen gelöscht werden, weil das jetzt ja die Aufgabe der neuen Klasse DatumFormatierer ist.

Hier könnte man nun argumentieren, dass ja doch mehrere Klassen geändert werden müssen, wenn sich die Anforderungen ändern. Hätte man aber die Klasse Datum von vorne herein mit den Getter-Methoden ausgestattet, wie es sich eigentlich gehört, wäre das nicht notwendig gewesen.

Auch die Klasse DatumsAusgabe muss modifiziert werden, damit alles funktioniert. Die Testklasse muss dagegen nicht verändert werden.

/*
 * Diese Klasse ist ausschließlich für die Ausgabe eines Datum-Strings zuständig 
 * (Single Responsibility Principle)
 */

public class DatumsAusgabe
{
    private DatumFormatierer daform = new DatumFormatierer();

    public void ausgeben(Datum d)
    {
        System.out.println("Datum = " + daform.getDDMMYYYY(d));
    }
}

Diese nachträglichen Änderungen der Klassen Datum und DatumsAusgabe wären nicht nötig gewesen, wenn man das ganze Projekt vorher nach dem Top-Down-Prinzip gut durchgeplant hätte.

2. Auslagerung der Regeln

Version 4

Die Klasse Datum hat immer noch zwei Verantwortungen, nämlich einmal die Verwaltung der Daten und zum anderen das Überprüfen von Tag, Monat und Jahr. Natürlich könnte man beide Verantwortungen in dieser Klasse belassen, viele Entwickler würden das sogar ohne mit der Wimper zu zucken machen. Ich selbst hätte damit auch kein Problem. Sie sollen sich aber hier mit dem wichtigsten Prinzip der OOP beschäftigen, dem SRP. Ob Sie es dann später immer streng anwenden, ist Ihre Sache, aber zumindest muss man es einmal durchgespielt haben.

Also werden wir jetzt die Überprüfungen von Tag, Monat und Jahr aus der Klasse Datum herausnehmen und in eine neue Klasse Datumsregeln übernehmen.

Hier ein Ausschnitt aus dem Quelltext zum Kopieren in die Zwischenablage:

/*
 * Diese Klasse ist ausschließlich für die Datums-Regeln zuständig 
 * (Single Responsibility Principle)
 * 
 * Wenn diese Regeln erweitert werden (Monate mit unterschiedlicher Tageszahl,
 * Berücksichtigung von Schaltjahren), dann muss nur diese Klasse
 * angepasst werden, und sonst keine andere.
 */
public class Datumsregeln
{
    public int korrigiereMonat(int monat)
    {
        if (monat < 1)  return 1;
        if (monat > 12) return 12;
        return monat;
    }

    // und so ähnlich für Tag und Jahr ...
}

public class Datum
{
    int tag, monat, jahr;
    DatumsRegeln  regeln;

    public Datum(int tag, int monat, int jahr)
    {
        regeln = new DatumsRegeln();
        setTag(tag);
        setMonat(monat);
        setJahr(jahr);
    }

    public void setTag(int tag)
    {
        this.tag = regeln.korrigiereTag(tag);
    }

Wir haben jetzt nur die Regeln für Tag, Monat und Jahr ausgelagert, und die Klasse Datum musste angepasst werden. Die anderen Klassen, DatumFormatierer, DatumsAusgabe und TesteDatum mussten nicht verändert werden.

Falls sich jetzt die Regeln für die Tage, Monate und Jahre einmal ändern sollten, müssen wir nur die neue Klasse DatumsRegeln modifizieren, keine andere Klasse.

Gut, man könnte nun natürlich kritisch einwenden: Wenn wir den gesamten Quelltext in der Klasse Datum gelassen hätten, müssten wir auch nur diese eine Klasse verändern. Das ist völlig richtig, aber wenn man alle möglichen Aufgaben in dieser Klasse Datum bestehen lässt, wird die Klasse immer länger und unübersichtlicher.

Robert C. Martin vergleicht in seinem Buch "Clean Code" das Ganze mit einem Werkzeugkasten. Stellen Sie sich vor, Sie sind Handwerker und besitzen 150 verschiedene Werkzeuge aus 15 unterschiedlichen Kategorien. Wann finden Sie den gesuchten Schraubendreher mit bestimmten Eigenschaften schneller wieder? Wenn Sie alle 150 Werkzeuge in eine große Kiste mit nur einem Fach packen, oder wenn Sie eine spezielle Werkzeugtasche mit 15 Fächern (für jede Kategorie eins) haben, die vielleicht sogar noch weiter unterteilt sind?

3. Neue Regeln

Version 5-1

Wir wollen die Regeln zur Überprüfung des Datums nun verfeinern. Nicht jeder Monat hat 31 Tage. Ein Monat hat sogar nur 28 Tage, und das auch nur in drei von vier Jahren.

        regeln = new DatumRegeln();
        setJahr(jahr);
        setMonat(monat);
        setTag(tag);

Version 5-2