Abituraufgaben: Objekte, die Objekte kennen

Die Klasse Zug besitzt ein privates Attribut lok vom Typ Lok. Es speichert eine Referenz auf ein Lok-Objekt; der Konstruktor setzt es auf null, ein neuer Zug kennt also noch keine Lok. Die Beziehung wird mit dem Auftrag ankuppeln hergestellt: Die übergebene Referenz wird mit this.lok = lok; im Attribut gespeichert (this unterscheidet Attribut und gleichnamigen Parameter). getHoechsttempo berechnet nichts selbst, sondern ruft über die gespeicherte Referenz die Anfrage getHoechstgeschwindigkeit() der Lok auf und gibt deren Ergebnis zurück (Delegation).

Die Referenzen können auch als Pfeile von re zu l2 und von rb zu l1 gezeichnet werden. Zwischenzeitlich kannten re und rb beide l1; nach dem dritten Aufruf verweist re auf l2. re.getHoechsttempo() liefert 140, rb.getHoechsttempo() liefert 160.

Für ic wurde ankuppeln nie aufgerufen, das Attribut lok hat daher noch den Wert null aus dem Konstruktor. null verweist auf kein Objekt; der Aufruf lok.getHoechstgeschwindigkeit() kann an kein Objekt gerichtet werden und löst eine NullPointerException aus, das Programm bricht ab.

public int getHoechsttempo() {
    if (lok == null) {
        return 0;
    }
    return lok.getHoechstgeschwindigkeit();
}

Ein Kunde leiht höchstens einen Scooter, ein Scooter ist höchstens an einen Kunden verliehen: auf beiden Seiten 0..1. Das Attribut scooter darf entfallen, wenn die Beziehung nur als Linie dargestellt wird. ausleihen muss einen Wahrheitswert liefern, da „die Methode meldet den Erfolg“.

public class Kunde {
    private String name;
    private int guthaben;
    private EScooter scooter;

    public Kunde(String name, int guthaben) {
        this.name = name;
        this.guthaben = guthaben;
        scooter = null;
    }

    public String getName() {
        return name;
    }

    public int getGuthaben() {
        return guthaben;
    }

    public EScooter getScooter() {
        return scooter;
    }

    public boolean ausleihen(EScooter s) {
        if (s == null || scooter != null || !s.istFrei()
                || guthaben < 100 || s.getAkku() < 20) {
            return false;
        }
        scooter = s;
        s.setFrei(false);
        return true;
    }

    public void zurueckgeben(int minuten) {
        if (scooter != null) {
            scooter.fahren(minuten);
            guthaben = guthaben - (100 + 25 * minuten);
            scooter.setFrei(true);
            scooter = null;
        }
    }
}

Bewertungsrelevant: Beziehung erst nach vollständiger Prüfung herstellen; null-Prüfung des Parameters vor dessen Nutzung; Zustand des Scooters über dessen Methoden ändern (Delegation), nicht über seine Attribute; beim Zurückgeben zuerst den Scooter bedienen, dann die Referenz lösen.

(1) true: s1 ist frei, Akku 100 %, Jonas hat 450 Cent und keinen Scooter. Jonas kennt nun s1, s1 ist belegt.

(2) false: Maries Guthaben von 80 Cent liegt unter 100 Cent.

(3) false: Jonas hat bereits einen Scooter (scooter != null), obwohl s2 frei ist.

(4) Akku: 100 − 2 · 12 = 76; Guthaben: 450 − (100 + 25 · 12) = 50; s1 ist wieder frei, Jonas kennt keinen Scooter mehr.

(5) false: s1 ist zwar frei und hat genug Akku, aber das Guthaben von 50 Cent reicht nicht.

Dafür: Mit einem Attribut kunde: Kunde in EScooter kann man vom Scooter aus direkt den Nutzer erfragen (s.getKunde().getName()), ohne alle Kunden durchsuchen zu müssen. Das beschleunigt die Suche nach dem Verursacher und erlaubt weitere Funktionen, etwa eine Nachricht an den aktuellen Nutzer.

Dagegen: Die Beziehung muss nun an zwei Stellen gepflegt werden. ausleihen und zurueckgeben müssen beide Referenzen setzen bzw. auf null setzen; wird eine vergessen, entstehen widersprüchliche Zustände (der Scooter „kennt“ einen Kunden, der ihn nicht mehr hat). Außerdem kennt der Scooter nach der Rückgabe den Kunden nicht mehr – für einen erst später entdeckten, falsch abgestellten Scooter hilft die Beziehung also gar nicht; dafür bräuchte man eine gespeicherte Ausleihhistorie. Aus Sicht des Datenschutzes sollten personenbezogene Daten nur so lange wie nötig verknüpft sein.

Mögliches Fazit: Die zweiseitige Beziehung löst das genannte Problem nur während der laufenden Fahrt und erhöht die Fehleranfälligkeit. Sinnvoller ist ein eigenes Objekt, das jede abgeschlossene Ausleihe mit Scooter, Kunde und Zeit festhält. Wer die zweiseitige Beziehung dennoch befürwortet, muss begründen, wie die Konsistenz in beiden Klassen sichergestellt wird.