Übung — AFB III (Verallgemeinern und Reflektieren)

public class Zimmer {
    private int nummer;
    private Gast[] gaeste;
    private int belegung;

    public Zimmer(int nummer, int betten) {
        this.nummer = nummer;
        gaeste = new Gast[betten];
        belegung = 0;
    }

    public int getNummer() {
        return nummer;
    }

    public boolean einchecken(Gast g) {
        if (g == null || belegung == gaeste.length) {
            return false;
        }
        gaeste[belegung] = g;
        belegung = belegung + 1;
        return true;
    }

    public void auschecken() {
        for (int i = 0; i < belegung; i++) {
            gaeste[i] = null;
        }
        belegung = 0;
    }

    public boolean istFrei() {
        return belegung == 0;
    }

    public int getBelegung() {
        return belegung;
    }

    public boolean wohntHier(String name) {
        for (int i = 0; i < belegung; i++) {
            if (gaeste[i].getName().equals(name)) {
                return true;
            }
        }
        return false;
    }
}

public int findeZimmerVon(String name) {
    for (int i = 0; i < zimmer.length; i++) {
        if (zimmer[i] != null && zimmer[i].wohntHier(name)) {
            return zimmer[i].getNummer();
        }
    }
    return -1;
}

Die öffentliche Schnittstelle von Zimmer bleibt bis auf zwei neue Methoden gleich — Programmteile, die nur einchecken und istFrei nutzen, müssen nicht geändert werden. Das Attribut betten entfällt, weil gaeste.length dieselbe Information enthält (keine doppelte Datenhaltung).

Gast kennt Zimmer? Nicht nötig: Die einzige Anfrage „Wo wohnt X?“ beantwortet Hotel durch Suchen. Eine zweite Referenz müsste bei jedem Ein- und Auschecken mitgepflegt werden und könnte inkonsistent werden. Erst wenn sehr häufig vom Gast aus gefragt wird (z. B. Zimmerrechnung vom Gastprofil aus), wäre die Gegenrichtung sinnvoll.

Ablauf: Wegen dynamischer Bindung laufen die Setter des Quadrats: setBreite(4) setzt beide Seiten auf 4, setHoehe(5) beide auf 5. Die Fläche ist 25, pruefe liefert false — obwohl die Methode für jedes „echte“ Rechteck true liefert.

Bewertung: Mathematisch ist ein Quadrat ein Rechteck, im Programm aber nicht: Ein Rechteck-Objekt verspricht, dass Breite und Höhe unabhängig veränderbar sind. Das Quadrat bricht dieses Versprechen. Jede Methode, die mit Rechteck arbeitet, kann durch ein Quadrat überrascht werden — Polymorphie wird zur Fehlerquelle. Der ist-ein-Test reicht also nicht, wenn die Unterklasse das Verhalten der Oberklasse einschränkt.

Alternative: gemeinsame Oberklasse Form mit flaeche(); Rechteck (zwei Seiten) und Quadrat (eine Seite) als Geschwister. Oder unveränderliche Objekte ohne Setter — dann ist ein Quadrat gefahrlos ein Rechteck.

Urteil: Der Entwurf ist nur scheinbar gekapselt. Private Attribute mit ungeprüften Settern für alles verhalten sich praktisch wie öffentliche Attribute: setGuthaben(5000) erzeugt Geld aus dem Nichts, setBestand(-3) oder setBestand(99) einen unmöglichen Bestand, setEinnahmen(0) lässt Geld verschwinden. Außerdem gehen fachliche Zusammenhänge verloren: Ein Kauf muss Bestand, Guthaben und Einnahmen gemeinsam ändern — mit einzelnen Settern ist das Sache des Aufrufers und damit fehleranfällig.

public class Getraenkeautomat {
    private int preis;
    private int bestand;
    private int guthaben;
    private int einnahmen;
    private int kapazitaet;

    public Getraenkeautomat(int preis, int kapazitaet) {
        this.preis = 150;
        setPreis(preis);
        this.kapazitaet = kapazitaet;
        bestand = 0;
        guthaben = 0;
        einnahmen = 0;
    }

    public void setPreis(int preis) {
        if (preis > 0 && preis % 10 == 0) {
            this.preis = preis;
        }
    }

    public int nachfuellen(int flaschen) {
        int passt = kapazitaet - bestand;
        if (flaschen > passt) {
            flaschen = passt;
        }
        if (flaschen > 0) {
            bestand = bestand + flaschen;
            return flaschen;
        }
        return 0;
    }

    public boolean einwerfen(int muenze) {
        if (muenze == 10 || muenze == 20 || muenze == 50 || muenze == 100 || muenze == 200) {
            guthaben = guthaben + muenze;
            return true;
        }
        return false;
    }

    public boolean kaufen() {
        if (bestand > 0 && guthaben >= preis) {
            bestand = bestand - 1;
            guthaben = guthaben - preis;
            einnahmen = einnahmen + preis;
            return true;
        }
        return false;
    }

    public int rueckgabe() {
        int betrag = guthaben;
        guthaben = 0;
        return betrag;
    }

    public int kassieren() {
        int betrag = einnahmen;
        einnahmen = 0;
        return betrag;
    }

    public int getPreis() {
        return preis;
    }

    public int getBestand() {
        return bestand;
    }

    public int getGuthaben() {
        return guthaben;
    }
}

Nur setPreis bleibt als Setter — mit Prüfung. Kein Getter für einnahmen: Der Betrag wird nur beim Leeren durch kassieren() herausgegeben. Dass nur der Hausmeister kassieren darf, lässt sich mit Sichtbarkeiten nicht ausdrücken — das muss die Bedienoberfläche regeln (z. B. Schlüsselschalter). Im Konstruktor wird zuerst ein Standardpreis gesetzt, damit ein ungültiger Startpreis nicht zu 0 führt.

Dazu Ladevorgang ——saeule——> 1 Saeule (Nummer, Preis pro kWh) und Firmenkunde (- rabatt: Ganzzahl, überschreibt preisfaktor()) als Unterklasse von Kunde.

public class Firmenkunde extends Kunde {
    private int rabatt;                       // in Prozent
    public Firmenkunde(String name, int rabatt) {
        super(name);
        this.rabatt = rabatt;
    }
    @Override
    public double preisfaktor() { return 1 - rabatt / 100.0; }
}
public class Ladevorgang {
    private Saeule saeule;
    private Kunde kunde;
    private double kwh;
    // Konstruktor setzt alle drei Attribute
    public double kosten() {
        return kwh * saeule.getPreisProKwh() * kunde.preisfaktor();
    }
}

umsatz() summiert kosten() über alle Ladevorgänge: 20 · 0,50 = 10,00 € und 40 · 0,40 · 0,8 = 12,80 €, zusammen 22,80 €. Ladevorgang kennt nur den Typ Kunde; welcher Faktor gilt, entscheidet das Objekt. Achtung: rabatt / 100 wäre bei int ganzzahlig 0 — deshalb 100.0.

Verhalten (Teil des Vertrags): radEntnehmen() liefert null, wenn die Station leer ist. radAbstellen liefert false bei 12 Rädern. beenden(minute) liefert die Leihdauer in Minuten. ausleihen scheitert, wenn die Kundin schon ein Rad hat oder die Station leer ist; zurueckgeben berechnet die Kosten mit 200 Cent pro angefangener Stunde.

Aufteilung: Person A Station, Person B Leihrad, Person C Kundin (sie nutzt die Methoden der beiden anderen und trägt die Ablauflogik).

Testfälle (vorher vereinbart): Station: leere Station, radEntnehmen() → null; Station mit 12 Rädern, radAbstellen(r) → false. Leihrad: starten(600), beenden(661) → 61. Kundin: Ausleihe um Minute 600, Rückgabe um 661 → getKostenCent() = 400 (zwei angefangene Stunden); zweites ausleihen ohne Rückgabe → false.

Begründung: Alle drei programmieren gleichzeitig. Person C ruft radEntnehmen() auf, bevor Person A es fertig hat — das geht nur, wenn Name, Parameter, Rückgabe und Fehlerverhalten verbindlich festgelegt sind. Ändert jemand eigenmächtig eine Signatur, passt der Quelltext beim Zusammenführen nicht mehr. Die vorher vereinbarten Tests prüfen, ob sich jede Klasse an den Vertrag hält.

public class Dreieck extends Form {
    private double g;
    private double h;
    public Dreieck(double g, double h) {
        this.g = g;
        this.h = h;
    }
    @Override
    public double flaeche() {
        return g * h / 2;
    }
}
public double gesamtflaeche() {          // in Zeichnung
    double summe = 0;
    for (int i = 0; i < formen.size(); i++) {
        summe = summe + formen.get(i).flaeche();
    }
    return summe;
}

12 + π · 1² + 6 · 2 / 2 = 12 + 3,14 + 6 ≈ 21,14. Entscheidend: gesamtflaeche() musste für das Dreieck nicht geändert werden — die neue Klasse fügt sich über die überschriebene Methode ein.

A erfüllt (1) direkt; für (2) müsste die Haltestelle alle Linien des Verbunds durchsuchen — dazu braucht es eine zentrale Verwaltung aller Linien, und die Anzeige wird bei vielen Linien langsam. B erfüllt (2) direkt, aber (1) nicht: Die Reihenfolge der Halte einer Linie ist nirgends gespeichert. C erfüllt beide Anforderungen direkt, erkauft das aber mit doppelter Datenhaltung: Beide Seiten müssen immer zusammen geändert werden.

Entscheidung: C, weil beide Anforderungen häufig und zeitkritisch sind (Anzeigetafel). Das Konsistenzproblem wird gelöst, indem es nur einen öffentlichen Weg gibt, einen Halt einzutragen: haltHinzufuegen in Buslinie trägt automatisch auch die Gegenrichtung ein.

public class Buslinie {
    private String nummer;
    private Haltestelle[] halte;
    private int anzahlHalte;

    public Buslinie(String nummer, int maxHalte) {
        this.nummer = nummer;
        halte = new Haltestelle[maxHalte];
        anzahlHalte = 0;
    }

    public String getNummer() {
        return nummer;
    }

    public boolean haltHinzufuegen(Haltestelle h) {
        if (h == null || anzahlHalte == halte.length) {
            return false;
        }
        halte[anzahlHalte] = h;
        anzahlHalte = anzahlHalte + 1;
        h.linieEintragen(this);
        return true;
    }
}

public void linieEintragen(Buslinie b) {
    for (int i = 0; i < anzahlLinien; i++) {
        if (linien[i] == b) {
            return;
        }
    }
    if (anzahlLinien < linien.length) {
        linien[anzahlLinien] = b;
        anzahlLinien = anzahlLinien + 1;
    }
}

Die Doppelprüfung in linieEintragen verhindert, dass Linie 4 zweimal an der Tafel steht, wenn sie (z. B. als Ringlinie) eine Haltestelle zweimal anfährt. Eine Schwäche bleibt: linieEintragen ist öffentlich und könnte auch allein aufgerufen werden — das muss im Team als Regel vereinbart werden.

Vorschlag A: Die Mitgliederliste ist direkt verfügbar. Für den Stundenplan müsste man alle AGs durchsuchen, ob der Schüler darin vorkommt — bei vielen AGs aufwendig, aber machbar, sofern es eine Klasse gibt, die alle AGs kennt. Vorteil: Jede Information steht nur an einer Stelle, Widersprüche sind ausgeschlossen.

Vorschlag B: Beide Funktionen sind direkt möglich. Nachteil: Jede Beziehung ist doppelt gespeichert. eintreten und austreten müssen beide Listen gemeinsam ändern; vergisst eine Methode eine Seite, zeigt der Stundenplan AGs, in denen der Schüler gar nicht mehr ist.

Ergebnis: Wird der Stundenplan häufig gebraucht, ist B sinnvoll — dann mit genau einer Methode, z. B. ag.aufnehmen(s), die intern auch s.ags ergänzt. Wird er selten gebraucht, genügt A mit Suche.

Der Entwurf spart kurzfristig Code, ist aber abzulehnen. Durch die Vererbung erbt die Warteschlange alle öffentlichen Methoden der Liste, z. B. add(0, p) (vordrängeln), remove(3) (jemanden aus der Mitte entfernen) oder set(i, p). Die Regeln der Praxis lassen sich damit von außen umgehen; die Warteschlange kann ihren Zustand nicht schützen (Datenkapselung). Der ist-ein-Test scheitert: Eine Warteschlange ist keine beliebige Liste, sie hat eine Liste.

Besser: Assoziation bzw. Attribut private ArrayList<Patient> wartende; und nur die erlaubten Methoden anstellen(p) (add), aufrufen() (remove(0)) und getAnzahl(). So entspricht die Klasse der Datenstruktur Schlange aus Kapitel 5.

Gegenbeispiel: * bedeutet „beliebig viele“. Beim 101. Mitglied gibt es keinen Platz mehr; mitglieder[100] = m führt zu einer ArrayIndexOutOfBoundsException, oder das Mitglied wird abgewiesen — die Anforderung ist verletzt. Damit ist die Behauptung widerlegt.

Außerdem ist die Reihung auch vorher nicht gleichwertig: Die Anzahl muss in einem zusätzlichen Attribut mitgezählt werden, bei 7 Mitgliedern sind 93 Plätze null, jede Schleife muss sie überspringen, und beim Austreten entstehen Lücken, die man durch Verschieben schließen muss. Eine ArrayList (im Abitur DynArray) übernimmt genau das. Eine Reihung ist nur bei einer festen Obergrenze wie 0..20 die passende Umsetzung.