Abituraufgaben: Datenkapselung mit get und set

Bei der Datenkapselung sind alle Attribute private; andere Klassen können sie weder lesen noch verändern. Der Zugriff erfolgt ausschließlich über öffentliche Methoden: Getter liefern den Wert (getStunde()), Setter ändern ihn, prüfen dabei aber, ob der neue Wert gültig ist (setStunde akzeptiert nur 0 bis 23).

Beispiel: Wäre stunde öffentlich, könnte die App t.stunde = 25; ausführen. Der Termin läge dann auf einer nicht existierenden Uhrzeit, die Tagesansicht würde ihn nicht oder falsch anzeigen. Durch die Kapselung bleibt jedes Termin-Objekt stets in einem gültigen Zustand; die Verantwortung dafür liegt an einer einzigen Stelle, der Klasse selbst. Zudem kann die interne Speicherung später geändert werden (z. B. Beginn in Minuten seit Mitternacht), ohne dass andere Klassen angepasst werden müssen.

public Termin(String titel, int tag, int monat, int stunde) {
    this.titel = titel;
    this.tag = 1;
    this.monat = 1;
    this.stunde = 8;
    this.dauer = 60;
    setTag(tag);
    setMonat(monat);
    setStunde(stunde);
}

public void setStunde(int stunde) {
    if (stunde >= 0 && stunde <= 23) {
        this.stunde = stunde;
    }
}

public int getDauer() {
    return dauer;
}

public void setDauer(int dauer) {
    if (dauer >= 15 && dauer <= 480 && dauer % 15 == 0) {
        this.dauer = dauer;
    }
}

Bewertet werden: Konstruktor ohne Rückgabetyp, Standardwerte vor den Setter-Aufrufen, Nutzung der Setter statt direkter Zuweisung ungeprüfter Werte, this bei gleichnamigen Parametern, vollständige Prüfung der drei Bedingungen für die Dauer, return im Getter.

Begründung der Werte: Tag 31 ist gültig; Monat 13 ist ungültig, daher bleibt der Standardwert 1. setDauer(50) scheitert (kein Vielfaches von 15), setStunde(24) scheitert (größer als 23), setDauer(90) gelingt, setTag(0) scheitert – der Tag bleibt 31.

Ablauf: stand = 1800.0 → 1200.0 (direkte Zuweisung) → 1150.0 (negativer Verbrauch). Preis = 0.0. Ausgabe: 0.0, denn (1150,0 − 0,0) · 0,0 = 0.

Ungültige Zustände: Der Zählerstand sinkt zweimal, obwohl er real nur steigen kann (600 kWh werden durch direkte Zuweisung, 50 kWh durch einen negativen Verbrauch „verschenkt“). Der Preis 0,00 Euro ist nicht plausibel; die Kosten sind falsch. Würde stand unter letzteAblesung gesetzt, entstünden sogar negative Kosten.

Ursachen in der Klasse: Alle Attribute sind public und können von jedem Programmteil ohne Prüfung überschrieben werden (auch zaehlernummer). verbrauchen prüft den Parameter nicht, und der Konstruktor übernimmt jeden Preis ungeprüft. Die Klasse kann so nicht sicherstellen, dass ihr Zustand gültig bleibt.

zaehlernummer: nur Getter – die Nummer ist fest. stand: nur Getter; verändert wird er ausschließlich über verbrauchen (nur positive Werte), der Anfangsstand kommt über den Konstruktor. letzteAblesung: kein Zugriff von außen; gesetzt nur durch ablesen(), genutzt über getVerbrauchSeitAblesung(). preisProKWh: Getter und Setter mit Plausibilitätsprüfung, weil sich Tarife ändern. Ein Getter für letzteAblesung ist ebenfalls vertretbar.

public class Stromzaehler {
    private String zaehlernummer;
    private double stand;
    private double letzteAblesung;
    private double preisProKWh;

    public Stromzaehler(String zaehlernummer, double anfangsstand, double preisProKWh) {
        this.zaehlernummer = zaehlernummer;
        this.stand = 0.0;
        if (anfangsstand > 0) {
            this.stand = anfangsstand;
        }
        this.letzteAblesung = this.stand;
        this.preisProKWh = 0.30;
        setPreisProKWh(preisProKWh);
    }

    public String getZaehlernummer() {
        return zaehlernummer;
    }

    public double getStand() {
        return stand;
    }

    public double getPreisProKWh() {
        return preisProKWh;
    }

    public void setPreisProKWh(double preis) {
        if (preis > 0 && preis < 2.0) {
            preisProKWh = preis;
        }
    }

    public void verbrauchen(double kwh) {
        if (kwh > 0) {
            stand = stand + kwh;
        }
    }

    public double getVerbrauchSeitAblesung() {
        return stand - letzteAblesung;
    }

    public double getKosten() {
        return getVerbrauchSeitAblesung() * preisProKWh;
    }

    public void ablesen() {
        letzteAblesung = stand;
    }
}

Wesentlich: private Attribute, Prüfung in verbrauchen und setPreisProKWh, gültiger Startpreis vor dem Setter-Aufruf (hier 0,30 Euro als Standardwert; andere Lösungen, die einen ungültigen Preis sicher abfangen, sind zu akzeptieren), letzteAblesung startet beim Anfangsstand, damit der Altverbrauch nicht abgerechnet wird. Mit dieser Klasse wären die Zeilen 3 und 5 aus Material 4 nicht übersetzbar, Zeile 4 bliebe wirkungslos; der Konstruktoraufruf in Zeile 1 erhält zusätzlich den Anfangsstand.

Für die Forderung: Ablesefehler oder Übertragungsfehler kommen vor und müssen korrigiert werden können; ohne Setter bliebe ein falscher Stand dauerhaft im System.

Gegen die Forderung: Ein öffentlicher, ungeprüfter setStand hebt die Kapselung praktisch auf: Genau die Manipulation aus Material 4 wäre wieder möglich, und der Zählerstand könnte sinken, was dem realen Gerät widerspricht. Der Zählertausch – der wichtigste Anlass – ist bereits über den Konstruktor mit Anfangsstand gelöst: Ein neuer Zähler ist ein neues Objekt.

Mögliches Urteil: Die Forderung ist in dieser Form abzulehnen. Falls Korrekturen nötig sind, sollte es höchstens eine eingeschränkte Methode geben (z. B. korrigieren(neuerStand), die nur Werte ≥ letzteAblesung akzeptiert und den Vorgang protokolliert). Ein begründetes Urteil für einen Setter mit strenger Prüfung ist ebenfalls vollständig, wenn die Gefahren benannt und abgewogen werden.