Übung — AFB III (Verallgemeinern und Reflektieren)

public class Mensaplan {
    public static void main(String[] args) {
        String[] tage = {"Mo", "Di", "Mi", "Do", "Fr"};
        for (int i = 0; i <= tage.length; i++) {
            System.out.println(tage[i]);
        }
    }
}

Musterlösung: Das Programm lässt sich ohne Meldung übersetzen, denn Syntax und Typen stimmen. Beim Ausführen gibt es zuerst Mo bis Fr aus und bricht dann ab: Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 5 out of bounds for length 5. Welcher Index tatsächlich benutzt wird, steht erst zur Laufzeit fest — das kann javac nicht wissen. Toms Aussage ist also falsch.

Richtig ist: Java findet eine ganze Fehlergruppe schon vor dem Start, etwa int x = "drei"; oder ein fehlendes Semikolon. In Python fällt so etwas oft erst auf, wenn die betreffende Zeile läuft. Laufzeitfehler (Index zu groß, null-Zugriff) und Logikfehler bleiben aber in beiden Sprachen möglich — deshalb muss man auch in Java testen.

Preis: int preisCent (z. B. 70 statt 0,70). Die Testausgabe zeigt: double speichert 0,1 und 0,2 nur ungefähr, die Summe ist nicht exakt 0,3 und der Vergleich mit == scheitert. Bei Geld stört das spätestens beim Kassenabschluss. Mit ganzen Cent rechnet int exakt (10 + 20 == 30 ist true).

Anzahl Brezeln: int — es gibt nur ganze Brezeln. Pfand: boolean — nur ja oder nein. Größe: char — genau ein Zeichen ('S', 'M', 'L'); String ginge auch, erlaubt aber beliebig lange Texte.

Artikelcode: String code = "0042"; Mit dem Code wird nicht gerechnet, und die führenden Nullen gehören dazu. Als int gingen sie verloren — schlimmer noch: 0042 wird als Oktalzahl gelesen und ergibt 34.

Beweis: Der Startwert 15 ist ungerade. Zieht man von einer ungeraden Zahl 2 ab, ist das Ergebnis wieder ungerade. Also ist feld nach jedem Durchlauf ungerade: 15, 13, …, 1, −1, −3, … Die 0 ist gerade und wird daher nie angenommen. Die Bedingung feld != 0 bleibt immer wahr — die Schleife endet nie.

Verallgemeinerung: Die Schleife endet genau dann, wenn der Startwert gerade und nicht negativ ist; dann läuft sie Startwert / 2 Mal. Von 1 bis 30 sind das die 15 geraden Zahlen 2, 4, …, 30.

Der Trick: Die Schleife sieht aus wie ein harmloser Countdown. Robuster ist feld > 0 statt feld != 0 — dann endet sie für jeden Startwert. Übrigens gilt der Beweis sogar, wenn int irgendwann überläuft: Der Wertebereich hat eine gerade Anzahl von Zahlen, die Ungeradheit bleibt erhalten.

Weiterrechnen: Variante A gibt den Preis nur aus. Weil sie void ist, kommt kein Wert zurück — eine Summe ist unmöglich, double s = zeigeRabatt(40.0); übersetzt nicht. Variante B liefert den Preis mit return: rabattPreis(40.0, 25) + rabattPreis(18.0, 10) ergibt 30,0 + 16,2 = 46,2.

Änderbarkeit: In A ist 25 % fest eingebaut; für 40 % müsste man die Methode ändern oder kopieren. B bekommt den Prozentsatz als Parameter und deckt jede Aktion ab.

Wiederverwendbarkeit: B trennt Rechnen und Ausgeben: Das Ergebnis kann auf dem Bildschirm, auf dem Kassenbon oder in einer weiteren Rechnung landen. A ist nur für genau eine Ausgabe brauchbar.

Urteil: Variante B ist klar besser. A ist höchstens als kleine Hilfsmethode sinnvoll, die ihrerseits rabattPreis aufruft.

public class Route {
    private String name;
    private int grad;
    private int begehungen;
    private boolean gesperrt;

    public Route(String name, int grad) {
        this.name = name;
        setGrad(grad);
        begehungen = 0;
        gesperrt = false;
    }

    public void setGrad(int grad) {
        if (grad >= 1 && grad <= 11) {
            this.grad = grad;
        }
    }

    public int getGrad() {
        return grad;
    }

    public boolean begehen() {
        if (gesperrt) {
            return false;
        }
        begehungen = begehungen + 1;
        return true;
    }

    public void sperren() {
        gesperrt = true;
    }

    public void freigeben() {
        gesperrt = false;
    }

    public int getBegehungen() {
        return begehungen;
    }

    public boolean istSchwer() {
        return grad >= 7;
    }
}

Begründung: Alle Attribute sind privat. Der Konstruktor nutzt den Setter, damit auch schon beim Erzeugen die Grenzen gelten (bei ungültigem Grad bleibt 0 stehen — eine Variante wäre ein Ersatzwert wie 1). Für begehungen gibt es bewusst keinen Setter: Der Zähler kann nur durch echtes Klettern wachsen. „Schwer“ wird aus grad berechnet statt gespeichert — so können die beiden Angaben nie widersprüchlich werden.

Entwurf A bietet keinen Schutz: karte.stempel = 99; ist erlaubt. Jede Stelle im Programm müsste die Café-Regeln selbst kennen.

Entwurf B wirkt gekapselt, ist es aber kaum: karte.setStempel(99); oder setStempel(-3) gehen genauso durch. Getter und Setter allein sind noch keine Kapselung — entscheidend ist, dass die Methoden die Regeln durchsetzen.

Entwurf C bildet die Regeln des Cafés ab: Stempel wachsen nur um 1, höchstens bis 10; das Einlösen klappt nur bei voller Karte und setzt sie zurück. Einen ungültigen Zustand kann man von außen nicht herstellen.

public void stempeln() {
    if (stempel < 10) {
        stempel = stempel + 1;
    }
}

public boolean einloesen() {
    if (stempel == 10) {
        stempel = 0;
        return true;
    }
    return false;
}

Urteil: C ist die beste Lösung, B nur scheinbar besser als A.

Kursplätze: Für ein Array spricht, dass es genau 12 Plätze mit fester Nummer gibt: String[] plaetze = new String[12]; Ein freier Platz ist null, und niemand „rutscht“ auf einen anderen Platz, wenn jemand abspringt. Eine ArrayList würde beim Entfernen nachrücken — die Platznummern würden sich ändern. → Array.

Warteliste: Die Länge ist unbekannt und ändert sich ständig; neue Personen kommen hinten dazu (add), die erste rückt nach (get(0), remove(0)). Mit einem Array müsste man die Größe raten und alles von Hand verschieben. → ArrayList<String>.

Altersangaben: Die Anzahl wächst mit jeder Anmeldung, also ArrayList. Der erste Versuch übersetzt aber nicht: error: unexpected type … required: reference, found: int. Richtig ist ArrayList<Integer>; Java wandelt int beim add automatisch um.

Ergebnis: Es gibt nicht „die“ bessere Struktur. Feste Anzahl mit fester Bedeutung der Plätze → Array; veränderliche Anzahl → ArrayList.

1. Vogel extends Tier: „Ein Vogel ist ein Tier“ stimmt. Vogel erbt beschreibung() und kannFliegen() und kann Eigenes ergänzen. Sinnvoll.

2. Pinguin extends Vogel: „Ein Pinguin ist ein Vogel“ stimmt biologisch. Nachteil: Er erbt ein kannFliegen(), das für Vögel true liefert; darum muss er es überschreiben. Das ist genau der Zweck des Überschreibens — vertretbar.

3. Gehege extends Tier: „Ein Gehege ist ein Tier“ ist falsch. Das Gehege würde kannFliegen() erben, bekäme aber keine Möglichkeit, mehrere Tiere zu speichern. Richtig ist eine Beziehung „hat“: private ArrayList<Tier> tiere; in Gehege. Abgelehnt.

@Override: Für das Weglassen spricht nur, dass der Code auch ohne läuft. Dagegen spricht der Test: Ohne Annotation wäre beschreibug() einfach eine neue Methode, und der Pinguin würde still die Beschreibung von Tier liefern. Mit @Override meldet javac sofort method does not override or implement a method from a supertype. Die Annotation ist also eine geprüfte Absichtserklärung — beibehalten.