Block 08 · Objektorientierung & Entwurfsmuster – Lösungen

a) Klasse und Objekt (2 P)

Die Klasse Paketfach ist der Bauplan (Datentyp): Sie legt fest, welche Attribute (Fachnummer, Größe, Inhalt, Abholcode) und welche Methoden (einlegen, entnehmen, istFrei …) jedes Paketfach hat. Ein Objekt ist ein konkretes Paketfach, das zur Laufzeit mit new erzeugt wird und eigene Attributwerte hat, z. B. Fach 7 der Station Hafenstraße, Größe "M", belegt mit Sendung KT-1001. Für die Station gibt es also eine Klasse, aber 24 Paketfach-Objekte.

b) Datenkapselung (3 P)

Die Attribute eines Paketfachs (fachNr, groesse, inhalt, abholcode) werden nach außen verborgen (Sichtbarkeit private). Andere Objekte, z. B. die Steuerung der Paketstation, können den Zustand nur über die öffentlichen Methoden lesen oder ändern (getGroesse(), istFrei(), einlegen, entnehmen). Niemand kann von außen direkt inhalt überschreiben oder den Abholcode auslesen.

Vorteile (zwei davon):

• Gültige Daten: Die Methoden prüfen jede Änderung – eine Sendung kann z. B. nur in ein freies, ausreichend großes Fach gelegt werden.
• Wartbarkeit: Die interne Darstellung (z. B. Größe als Zahl statt Text) kann geändert werden, ohne dass andere Klassen angepasst werden müssen.
• Geringe Kopplung: Andere Klassen hängen nur von der öffentlichen Schnittstelle ab.
• Fehlersuche: Nur die Klasse selbst ändert ihre Attribute; Fehler lassen sich leichter eingrenzen.

c) Aufgabe eines Konstruktors (1 P)

Der Konstruktor wird beim Erzeugen eines Objekts (new) automatisch aufgerufen und initialisiert das neue Objekt, d. h. er setzt die Anfangswerte der Attribute.

a) Ausgaben (6 P)

Ausgabe · Aufgabe_OOP_01_2.java

1000 | Ahrens | 4.0 kg
1001 | Bode | 1.0 kg
true
false
true
4

b) == gegenüber equals (2 P)

== vergleicht bei Objekten die Referenzen (Identität): e1 und e4 sind zwei verschiedene Objekte im Speicher, daher false. Die Klasse Etikett überschreibt equals so, dass inhaltlich verglichen wird (Empfänger und Gewicht) – beide Objekte haben gleiche Werte, daher true.

c) static (2 P)

naechsteNr gehört als statisches Attribut zur Klasse und existiert nur einmal für alle Etiketten. Jeder Konstruktoraufruf liest und erhöht denselben Zähler – so entstehen fortlaufende, eindeutige Nummern, und die statische Methode getAnzahl() kann ohne Objekt aufgerufen werden.

Als normales Attribut hätte jedes Objekt eine eigene Kopie mit dem Startwert 1000: Alle Etiketten bekämen die Nummer 1000, die Nummern wären nicht mehr eindeutig. Außerdem dürfte die statische Methode getAnzahl() nicht mehr auf das Attribut zugreifen (Compilerfehler).

Datei: java\08_OOP_Entwurfsmuster\Aufgabe_OOP_01_2.java (enthält zusätzlich ein Beispiel für die NullPointerException)

a) Klassendiagramm (7 P)

Erklärung: Die Anzahl aller Fächer soll ohne Paketfach-Objekt abrufbar sein – das verlangt ein statisches Attribut und eine statische Methode. Fachnummer und Größe sind nach der Erzeugung unveränderlich, also gibt es nur Getter und keine Setter. rang ist eine interne Hilfsmethode und deshalb privat.

b) Konstruktoren (3 P)

konstruktor Paketfach(fachNr : integer, groesse : string)
  this.fachNr := fachNr
  this.groesse := groesse
  inhalt := null
  abholcode := null
  anzahlFaecher := anzahlFaecher + 1
Ende konstruktor

konstruktor Paketfach(fachNr : integer)
  this(fachNr, "M")
Ende konstruktor

c) einlegen (3 P)

methode einlegen(s : Sendung, code : string) : boolean
  wenn istFrei() und rang(s.getGroesse()) <= rang(groesse) dann
    inhalt := s
    abholcode := code
    rückgabe true
  Ende wenn
  rückgabe false
Ende methode

d) entnehmen (3 P)

methode entnehmen(code : string) : Sendung
  wenn nicht istFrei() und abholcode = code dann
    s : Sendung := inhalt
    inhalt := null
    abholcode := null
    rückgabe s
  Ende wenn
  rückgabe null
Ende methode

Typischer Fehler: erst inhalt := null und danach rückgabe inhalt – dann wird immer null zurückgegeben. Deshalb die Sendung vorher in einer lokalen Variablen merken. Ohne die Prüfung „Fach belegt“ würde bei leerem Fach null = code verglichen; in Java wäre abholcode.equals(code) dann sogar eine NullPointerException.

Java · Aufgabe_OOP_01_3.java (Klasse Paketfach)

class Paketfach {
    private static int anzahlFaecher = 0;
    private final int fachNr;
    private final String groesse;
    private Sendung inhalt;
    private String abholcode;

    public Paketfach(int fachNr, String groesse) {
        this.fachNr = fachNr;
        this.groesse = groesse;
        this.inhalt = null;
        this.abholcode = null;
        anzahlFaecher = anzahlFaecher + 1;
    }

    public Paketfach(int fachNr) {
        this(fachNr, "M");
    }

    public static int getAnzahlFaecher() {
        return anzahlFaecher;
    }

    public int getFachNr() {
        return fachNr;
    }

    public String getGroesse() {
        return groesse;
    }

    public boolean istFrei() {
        return inhalt == null;
    }

    public boolean einlegen(Sendung s, String code) {
        if (s != null && istFrei() && rang(s.getGroesse()) <= rang(groesse)) {
            inhalt = s;
            abholcode = code;
            return true;
        }
        return false;
    }

    public Sendung entnehmen(String code) {
        if (!istFrei() && abholcode.equals(code)) {
            Sendung s = inhalt;
            inhalt = null;
            abholcode = null;
            return s;
        }
        return null;
    }

    private int rang(String groesse) {
        if (groesse.equals("S")) {
            return 1;
        } else if (groesse.equals("M")) {
            return 2;
        } else if (groesse.equals("L")) {
            return 3;
        }
        return 0;
    }
}

Ausgabe des Testprogramms

Erzeugte Fächer: 3
Fach 2 hat die Größe M
f1.einlegen(KT-1001 [M]) -> false  (Sendung zu groß für S)
f2.einlegen(KT-1001 [M]) -> true
f2.einlegen(KT-1003 [S]) -> false  (Fach belegt)
f3.einlegen(KT-1002 [L]) -> true
f1.einlegen(KT-1003 [S]) -> true
f2.entnehmen("000000") -> null  (falscher Code)
f2.entnehmen("482913") -> KT-1001
f2.istFrei() -> true
f2.entnehmen("482913") -> null  (Fach leer)

a) Zuordnung (3 P)

b) Abstrakte Klasse oder Interface? (3 P)

Entscheidung: Interface Druckbar.

• Abholschein erbt bereits von Dokument. Java erlaubt nur eine Oberklasse – eine abstrakte Klasse Druckbar könnte Abholschein nicht zusätzlich erweitern. Interfaces kann eine Klasse dagegen beliebig viele implementieren.
• Die Klassen haben keine gemeinsamen Attribute und keinen gemeinsamen Code; es wird nur eine gemeinsame Fähigkeit („kann gedruckt werden“) vereinbart. Genau dafür ist ein Interface gedacht; eine ist-ein-Beziehung zu einem gemeinsamen Oberbegriff besteht nicht.
• (weiteres mögliches Argument) Ein Druckdienst kann mit einer List<Druckbar> arbeiten und kennt die konkreten Klassen nicht (lose Kopplung).

a) Ausgaben (4 P)

Fahrzeug LR-07 angelegt
Lastenrad LR-07 bereit
Fahrzeug KT-02 angelegt
Kuehlung auf 20 Grad

Erklärung: Jeder Unterklassen-Konstruktor ruft als erste Anweisung super(…) auf. Der Konstruktor von Fahrzeug läuft deshalb vollständig durch (erste Zeile), erst danach der Rest des Unterklassen-Konstruktors. Beim Kühltransporter wird temperatur erst nach dem super-Aufruf auf 20 gesetzt.

b) Fehler in der Klasse EScooter (5 P)

Meldungen von javac 21 für die fehlerhafte Fassung (gekürzt)

Fehler: Fahrzeug ist abstrakt, kann nicht instanziiert werden
Fehler: EScooter ist nicht abstrakt und setzt die abstrakte Methode kostenProKm() in Fahrzeug nicht außer Kraft
Fehler: Konstruktor Fahrzeug in Klasse Fahrzeug kann nicht auf die angegebenen Typen angewendet werden.
        Erforderlich: String,int  Ermittelt: keine Argumente
Fehler: info() in EScooter kann nicht info() in Fahrzeug außer Kraft setzen. Außer Kraft gesetzte Methode ist final
Fehler: kennung hat private-Zugriff in Fahrzeug
5 Fehler

Java · korrigierte Klasse (Aufgabe_OOP_02_2.java)

class EScooter extends Fahrzeug {
    public EScooter(String kennung) {
        super(kennung, 35);                       // Fehler 1 behoben
        System.out.println("E-Scooter bereit");
    }

    @Override
    public double kostenProKm() {                 // Fehler 2 behoben
        return 0.03;
    }

    public String beschreibung() {                // Fehler 3 behoben (info() ist final)
        return "E-Scooter " + getKennung();       // Fehler 4 behoben (kennung ist private)
    }
}
// Fehler 5: new Fahrzeug(...) ist nicht erlaubt -> konkrete Unterklasse instanziieren

c) Ein Objekt, zwei Typen (1 P)

Kuehltransporter erbt von Fahrzeug (ein Kühltransporter ist ein Fahrzeug) und realisiert Kuehlbar. Ein Objekt einer Klasse ist mit allen Oberklassen und allen implementierten Interfaces typkompatibel (Upcast). Über die Fahrzeug-Variable sind dann nur die Fahrzeug-Methoden aufrufbar, über die Kuehlbar-Variable nur kuehlen.

Ausgabe des gesamten Testprogramms

--- a) Konstruktorverkettung ---
Fahrzeug LR-07 angelegt
Lastenrad LR-07 bereit
Fahrzeug KT-02 angelegt
Kuehlung auf 20 Grad
--- b) korrigierte Klasse EScooter ---
Fahrzeug ES-11 angelegt
E-Scooter bereit
ES-11 (35 km), Kosten/km: 0.03
E-Scooter ES-11
Fahrzeug RES-1 angelegt
Lastenrad RES-1 bereit
RES-1 (60 km)
--- c) ein Objekt, zwei Typen ---
Fahrzeug KT-03 angelegt
Kuehlung auf 20 Grad
KT-03 (220 km) / kuehlen(-18): true
f1 instanceof Kuehlbar: false, f2 instanceof Kuehlbar: true

a) Nachteile der bisherigen Umsetzung (4 P)

• Schlechte Erweiterbarkeit: Für eine neue Sendungsart (z. B. Sperrgut) muss die bestehende, bereits getestete Klasse an vier Stellen geändert werden – in jeder Fallunterscheidung. Wird eine Stelle vergessen, entsteht ein Fehler (z. B. Porto 0 im Sonst-Zweig). Hoher Änderungs- und Testaufwand.
• Redundanz und Unübersichtlichkeit: Dieselbe Fallunterscheidung wiederholt sich in jeder Methode, die Methoden werden lang, und die Regeln einer Sendungsart sind über die ganze Klasse verstreut.
• (weitere mögliche Antworten) Fehleranfälliger Typ als freier Text ("Paket", "PAKET", Tippfehler fallen erst zur Laufzeit auf); unpassendes Verhalten (ein Brief hat eine Versicherungsmethode, die nur 0 liefert).

b) Klassendiagramm (9 P)

c) Klasse Paket (5 P)

klasse Paket erbt von Postsendung implementiert Versicherbar

  konstruktor Paket(sendungsNr : string, gewicht : double)
    super(sendungsNr, gewicht)
  Ende konstruktor

  methode berechnePorto() : double
    wenn getGewicht() <= 5.0 dann
      rückgabe 5.49
    Ende wenn
    rückgabe 8.99
  Ende methode

  methode maxGewicht() : double
    rückgabe 31.5
  Ende methode

  methode istStationsfaehig() : boolean
    rückgabe true
  Ende methode

  methode berechneVersicherung(warenwert : double) : double
    betrag : double := warenwert * 0.01
    wenn betrag < 2.00 dann
      betrag := 2.00
    Ende wenn
    rückgabe betrag
  Ende methode
Ende klasse

Java · Aufgabe_OOP_02_3.java (Klasse Paket)

class Paket extends Postsendung implements Versicherbar {
    public Paket(String sendungsNr, double gewicht) {
        super(sendungsNr, gewicht);
    }

    @Override
    public double berechnePorto() {
        if (getGewicht() <= 5.0) {
            return 5.49;
        }
        return 8.99;
    }

    @Override
    public double maxGewicht() {
        return 31.5;
    }

    @Override
    public boolean istStationsfaehig() {
        return true;
    }

    @Override
    public double berechneVersicherung(double warenwert) {
        double betrag = warenwert * 0.01;
        if (betrag < 2.00) {
            betrag = 2.00;
        }
        return betrag;
    }
}

Ausgabe des Testprogramms (alle Sendungsarten, polymorph über List<Postsendung>)

Nr    Art             Gewicht  Porto   max.kg  Station
B-1   Brief            0,02    0,95     1,0  nein
B-2   Brief            0,40    1,80     1,0  nein
P-1   Paket            3,00    5,49    31,5  ja
P-2   Paket           12,00    8,99    31,5  ja
E-1   Expresssendung   2,50   14,90    20,0  nein
Versicherung (nur Objekte, die Versicherbar realisieren):
  P-1  Warenwert  150,00 -> Versicherung  2,00
  P-2  Warenwert  600,00 -> Versicherung  6,00
  E-1  Warenwert  400,00 -> Versicherung  2,00
Gegenprobe mit der bisherigen Klasse (Fallunterscheidung nach typ):
  E-1 alt: Porto 14,90, Versicherung(400) 2,00

d) Eine Oberklasse, aber mehrere Interfaces (4 P)

Java erlaubt bei Klassen nur Einfachvererbung. Würde eine Klasse von zwei Klassen erben, die beide eine Methode mit gleicher Signatur implementieren oder gleichnamige Attribute haben, wäre nicht eindeutig, welche Implementierung bzw. welches Attribut gilt; erben beide Klassen außerdem von einer gemeinsamen Oberklasse, wären deren Attribute doppelt vorhanden (Diamond-Problem).

Ein Interface enthält dagegen keine Instanzattribute und (in der klassischen Form) nur Methodensignaturen ohne Implementierung. Paket implementiert berechneVersicherung selbst – es gibt genau eine Implementierung und damit keinen Konflikt. Deshalb darf eine Klasse eine Oberklasse haben (Postsendung, „ist ein“) und zusätzlich beliebig viele Interfaces realisieren (Versicherbar, „kann versichert werden“).

a) Polymorphie (3 P)

Polymorphie (Vielgestaltigkeit) bedeutet, dass eine Variable vom Typ einer Oberklasse oder eines Interfaces auf Objekte verschiedener Unterklassen verweisen kann. Derselbe Methodenaufruf führt je nach Objekt zu unterschiedlichem Verhalten, weil die Unterklassen die Methode überschreiben. Welche Implementierung ausgeführt wird, wird erst zur Laufzeit anhand der tatsächlichen Klasse des Objekts entschieden (dynamische bzw. späte Bindung). Beispiel: Zustellung z := new Expresszustellung() – der Aufruf z.gebuehr() führt die Methode von Expresszustellung aus.

b) Überladen oder Überschreiben? (3 P)

a) Ausgaben (6 P)

Ausgabe · Aufgabe_OOP_03_2.java

Express
Express: 10.0 EUR
Nacht-Express: 10.0 EUR
Zustellung: 4.0 EUR
Standardbuchung
Expressbuchung

b) Aufruf von zeitfenster() über b (2 P)

Der Compiler prüft anhand des statischen Typs, welche Methoden aufgerufen werden dürfen. b ist als Zustellung deklariert, und Zustellung hat keine Methode zeitfenster() – dass das Objekt zur Laufzeit eine Expresszustellung ist, spielt für den Compiler keine Rolle. Lösung: Typ prüfen und explizit umwandeln (Downcast):

if (b instanceof Expresszustellung) {
    Expresszustellung e = (Expresszustellung) b;
    System.out.println(e.zeitfenster());
}

c) Downcast auf ein Objekt der Oberklasse (2 P)

Übersetzen: Der Compiler akzeptiert die Anweisung, weil Expresszustellung eine Unterklasse von Zustellung ist und ein Downcast grundsätzlich möglich ist. Ausführen: a verweist auf ein reines Zustellung-Objekt, das keine Expresszustellung ist. Die Umwandlung schlägt fehl, es wird eine ClassCastException ausgelöst (ohne Behandlung bricht das Programm ab). Vermeiden lässt sich das mit einer Prüfung durch instanceof.

ClassCastException: class Zustellung cannot be cast to class Expresszustellung (Zustellung and Expresszustellung are in unnamed module of loader 'app')
a instanceof Expresszustellung: false

Datei: java\08_OOP_Entwurfsmuster\Aufgabe_OOP_03_2.java – Die Datei enthält die Klassen aus Anlage 7, den Programmausschnitt der Aufgabe sowie b) und c) zum Ausprobieren.

a) Generische Klasse (3 P)

Eine generische Klasse hat einen Typparameter (hier T), der als Platzhalter für den Datentyp der Elemente steht. Der konkrete Typ wird erst bei der Verwendung festgelegt, z. B. Ablage<Lagerposten> oder später Ablage<Rollcontainer>; die Klasse wird nur einmal programmiert.

Vorteil gegenüber Object: Typsicherheit beim Übersetzen – in eine Ablage<Lagerposten> lässt der Compiler nur Lagerposten hinein, beim Herauslesen ist kein Cast nötig, und Typfehler fallen nicht erst zur Laufzeit (ClassCastException) auf. (Auch akzeptiert: Wiederverwendbarkeit ohne Codekopie, bessere Lesbarkeit.)

b) Konstruktor und ablegen (4 P)

konstruktor Ablage(bezeichnung : string, kapazitaet : integer)
  this.bezeichnung := bezeichnung
  this.kapazitaet := kapazitaet
  elemente := new List<T>()
Ende konstruktor

methode ablegen(element : T) : boolean
  wenn elemente.size() < kapazitaet und nicht elemente.contains(element) dann
    elemente.add(element)
    rückgabe true
  Ende wenn
  rückgabe false
Ende methode

c) faelligePosten (4 P)

methode faelligePosten(ablage : Ablage<Lagerposten>, heute : Datum) : List<Lagerposten>
  ergebnis : List<Lagerposten> := new List<Lagerposten>()
  posten : List<Lagerposten> := ablage.getElemente()
  zähle i von 0 bis posten.size() - 1
    p : Lagerposten := posten.get(i)
    wenn p.istFaellig(heute) dann
      ergebnis.add(p)
    Ende wenn
  Ende zähle
  rückgabe ergebnis
Ende methode

Testdaten: R-101 (Eingang 20.09. + 14 Tage = 04.10. ≤ 10.10.), Z-201 (freigegeben) und L-301 (Abholtermin = heute) sind fällig; R-102 erst ab 15.10., Z-202 nicht freigegeben, L-302 erst am 12.10.

d) Mechanismus (3 P)

Polymorphie durch dynamische (späte) Bindung. Lagerposten deklariert istFaellig als abstrakte Methode, und jede Unterklasse (Retoure, Zollposten, Lagerauftrag) überschreibt sie mit ihrer eigenen Regel. Die Variable p hat den statischen Typ Lagerposten; welche Implementierung ausgeführt wird, entscheidet die Laufzeitumgebung erst beim Aufruf anhand der tatsächlichen Klasse des Objekts (dynamischer Typ).

e) maximum (4 P)

methode maximum(v : Vergleicher<T>) : T
  wenn elemente.size() = 0 dann
    rückgabe null
  Ende wenn
  max : T := elemente.get(0)
  zähle i von 1 bis elemente.size() - 1
    wenn v.vergleiche(elemente.get(i), max) > 0 dann
      max := elemente.get(i)
    Ende wenn
  Ende zähle
  rückgabe max
Ende methode

Java · Aufgabe_OOP_03_3.java (Ablage<T>, Vergleicher<T>, Lagerverwaltung)

class Ablage<T> {
    private String bezeichnung;
    private int kapazitaet;
    private List<T> elemente;

    public Ablage(String bezeichnung, int kapazitaet) {
        this.bezeichnung = bezeichnung;
        this.kapazitaet = kapazitaet;
        this.elemente = new ArrayList<>();
    }

    public boolean ablegen(T element) {
        if (elemente.size() < kapazitaet && !elemente.contains(element)) {
            elemente.add(element);
            return true;
        }
        return false;
    }

    public int anzahl() {
        return elemente.size();
    }

    public List<T> getElemente() {
        return elemente;
    }

    public T maximum(Vergleicher<T> v) {
        if (elemente.size() == 0) {
            return null;
        }
        T max = elemente.get(0);
        for (int i = 1; i < elemente.size(); i++) {
            if (v.vergleiche(elemente.get(i), max) > 0) {
                max = elemente.get(i);
            }
        }
        return max;
    }
}

interface Vergleicher<T> {
    int vergleiche(T a, T b);
}

class Lagerverwaltung {
    public List<Lagerposten> faelligePosten(Ablage<Lagerposten> ablage, Datum heute) {
        List<Lagerposten> ergebnis = new ArrayList<>();
        List<Lagerposten> posten = ablage.getElemente();
        for (int i = 0; i < posten.size(); i++) {
            Lagerposten p = posten.get(i);
            if (p.istFaellig(heute)) {          // dynamische Bindung
                ergebnis.add(p);
            }
        }
        return ergebnis;
    }
}

Ausgabe des Testprogramms (Testdaten aus Anlage 8, heute = 10.10.2026)

ablegen(R-101) -> true
ablegen(R-102) -> true
ablegen(Z-201) -> true
ablegen(Z-202) -> true
ablegen(L-301) -> true
ablegen(L-302) -> true
ablegen(R-101) erneut -> false  (schon enthalten)
ablegen(R-103) -> false  (Kapazität 6 erreicht)
anzahl() = 6
c) faelligePosten(regalA, 10.10.2026): R-101 Z-201 L-301 
e) maximum(GewichtVergleicher) = L-301 (18.0 kg)
Ablage<String>.maximum(nach Länge) = "Zoll ruft zurück"
maximum einer leeren Ablage = null

Die letzten Zeilen zeigen die Wiederverwendung: dieselbe Klasse als Ablage<String>, der Vergleicher als Lambda-Ausdruck, und null bei leerer Ablage.

a) Vorteile von Entwurfsmustern (4 P)

• Bewährte Lösungen: Entwurfsmuster sind vielfach erprobte Lösungen für wiederkehrende Entwurfsprobleme. Das Team muss die Lösung nicht neu erfinden und vermeidet typische Entwurfsfehler – die Qualität von KraniTrack steigt, die Entwicklung geht schneller.
• Gemeinsames Vokabular: Ein Mustername („hier ein Observer“) beschreibt eine ganze Struktur. Das erleichtert die Kommunikation im Team, die Dokumentation und die Einarbeitung neuer Entwickler.
• (weitere mögliche Antworten) Wartbarkeit und Erweiterbarkeit durch lose Kopplung (z. B. neue Anzeigen ohne Änderung bestehender Klassen); Wiederverwendbarkeit des Entwurfs in anderen Projekten.

b) Kategorien (2 P)

a) Zweck des Singleton-Musters (2 P)

Das Singleton-Muster stellt sicher, dass es von der Klasse Tarifkonfiguration genau ein Objekt gibt, und bietet über die statische Methode getInstanz() einen globalen Zugriffspunkt darauf. So wird die Datei tarife.properties nur einmal gelesen, und alle Programmteile verwenden garantiert dieselben Tarifwerte.

b) Vier Fehler (6 P)

Java · Aufgabe_OOP_04_2.java (korrigierte Klasse, threadsicher)

class Tarifkonfiguration {
    private static Tarifkonfiguration instanz = null;      // Fehler 1: static
    private double grundpreisPaket;
    private double kgZuschlag;

    private Tarifkonfiguration() {                         // Fehler 2: private
        grundpreisPaket = ladeWert("paket.grundpreis");
        kgZuschlag = ladeWert("paket.kgzuschlag");
    }

    public static synchronized Tarifkonfiguration getInstanz() {   // Fehler 3: static
        if (instanz == null) {                                     // Fehler 4: nur einmal erzeugen
            instanz = new Tarifkonfiguration();
        }
        return instanz;
    }

    public double getGrundpreisPaket() {
        return grundpreisPaket;
    }

    public double getKgZuschlag() {
        return kgZuschlag;
    }

    // ladeWert(...) wie bisher
}

c) Mehrere Threads (2 P)

Problem: Rufen zwei Threads getInstanz() gleichzeitig zum ersten Mal auf, können beide die Bedingung instanz == null als erfüllt sehen, bevor einer von ihnen das neue Objekt zugewiesen hat (Race Condition). Dann werden zwei Objekte erzeugt, die Datei wird zweimal gelesen, und Programmteile arbeiten eventuell mit unterschiedlichen Instanzen – das Singleton ist verletzt.

Lösung (eine genügt): getInstanz() als synchronized deklarieren (nur ein Thread gleichzeitig in der Methode); oder die Instanz gleich beim Laden der Klasse erzeugen (private static final Tarifkonfiguration INSTANZ = new Tarifkonfiguration();); oder in Java ein enum mit genau einem Wert verwenden.

Ausgabe des Testprogramms (10 Threads rufen gleichzeitig getInstanz() auf)

t1 == t2: true
Grundpreis Paket: 4,20 EUR, Zuschlag je kg: 0,35 EUR
Verschiedene Instanzen bei 10 Threads: 1
Anzahl Ladevorgänge der Datei: 1

a) Vorteile der Fabrikmethode (3 P)

• Erzeugung an einer Stelle: Kommt ein neuer Kanal hinzu (z. B. Messenger), werden nur die neue Unterklasse und die Fabrikmethode angepasst – nicht fünf verstreute Stellen. Keine Stelle kann vergessen werden.
• Lose Kopplung: Der Zustellservice und andere Aufrufer kennen nur die abstrakte Klasse Benachrichtigung, nicht die konkreten Unterklassen. Sie bleiben bei Erweiterungen unverändert und sind leichter testbar.
• (weitere mögliche Antwort) Weniger redundanter Code; einheitliche Behandlung unbekannter Kanäle.

b) Klassendiagramm (7 P)

c) Fabrikmethode (4 P)

methode erzeuge(kanal : string, ziel : string) : Benachrichtigung   {static}
  wenn kanal = "EMAIL" dann
    rückgabe new EmailBenachrichtigung(ziel)
  sonst wenn kanal = "SMS" dann
    rückgabe new SmsBenachrichtigung(ziel)
  sonst wenn kanal = "PUSH" dann
    rückgabe new PushBenachrichtigung(ziel)
  Ende wenn
  rückgabe null      // unbekannter Kanal
Ende methode

// Verwendung im Zustellservice – keine Fallunterscheidung mehr:
methode informiereEmpfaenger(k : Kunde, text : string) : double
  b : Benachrichtigung := Benachrichtigung.erzeuge(k.getKanal(), k.getKontakt())
  wenn b = null dann
    rückgabe 0.0
  Ende wenn
  b.senden(text)
  rückgabe b.kostenProNachricht()
Ende methode

Java · Aufgabe_OOP_04_3.java

abstract class Benachrichtigung {
    protected String ziel;

    public Benachrichtigung(String ziel) {
        this.ziel = ziel;
    }

    public abstract boolean senden(String text);

    public abstract double kostenProNachricht();

    public static Benachrichtigung erzeuge(String kanal, String ziel) {
        if (kanal.equals("EMAIL")) {
            return new EmailBenachrichtigung(ziel);
        } else if (kanal.equals("SMS")) {
            return new SmsBenachrichtigung(ziel);
        } else if (kanal.equals("PUSH")) {
            return new PushBenachrichtigung(ziel);
        }
        return null;
    }
}

class Zustellservice {
    /** Liefert die Kosten der Benachrichtigung (0, wenn keine gesendet wurde). */
    public double informiereEmpfaenger(Kunde k, String text) {
        Benachrichtigung b = Benachrichtigung.erzeuge(k.getKanal(), k.getKontakt());
        if (b == null) {
            System.out.println("  Kanal " + k.getKanal() + " von " + k.getName() + " unbekannt - keine Nachricht");
            return 0.0;
        }
        b.senden(text);
        return b.kostenProNachricht();
    }
}

Ausgabe (vier Kunden, der Kanal "FAX" ist unbekannt)

  E-Mail an ahrens@example.org: 183 Zeichen
  SMS an +49 151 0000001: 160 Zeichen (gekürzt auf max. 160)
  Push an Gerät geraet-7f3a: 183 Zeichen
  Kanal FAX von Dahl unbekannt - keine Nachricht
Kosten der Benachrichtigungen: 0,07 EUR

d) Builder (2 P)

Ein Konstruktor mit allen Angaben hätte viele, überwiegend optionale Parameter: Aufrufe wie new Etikett("KT-1", null, 0.0, null, "Garage", null) sind unlesbar und fehleranfällig (Reihenfolge, viele null-Werte), oder man bräuchte sehr viele überladene Konstruktoren. Ein Builder setzt nur die benötigten Angaben Schritt für Schritt über sprechende Methoden (.ablageort("Garage").wunschtag(…)) und erzeugt mit build() ein vollständiges, geprüftes Etikett. Der Code wird lesbarer, flexibler, und die Prüfung der Angaben steht an einer Stelle.

a) Passende Entwurfsmuster (3 P)

b) MVC im Kundenportal (3 P)

• Model: Daten und Geschäftslogik des Portals (Sendungen, Sendungsstatus, Tarife, Datenbankzugriff), unabhängig von der Darstellung. Es informiert die Views über Änderungen.
• View: Darstellung der Daten für den Kunden (z. B. Seite mit Sendungsliste und Statusanzeige); sie nimmt Eingaben entgegen und leitet sie an den Controller weiter.
• Controller: Steuerung – verarbeitet Benutzeraktionen (z. B. „Sendung verfolgen“ mit eingegebener Sendungsnummer), prüft sie, ruft die passenden Methoden des Models auf und wählt die anzuzeigende View.

a) Ergänztes Klassendiagramm (4 P)

b) Methoden preis und berechnePreis (4 P)

// Klasse Privattarif
methode preis(gewicht : double) : double
  wenn gewicht <= 2.0 dann
    rückgabe 4.99
  sonst wenn gewicht <= 10.0 dann
    rückgabe 7.49
  Ende wenn
  rückgabe 11.99
Ende methode

// Klasse Paketauftrag
methode berechnePreis() : double
  rückgabe strategie.preis(gewicht)
Ende methode

Java · Aufgabe_OOP_05_2.java

interface Preisstrategie {
    double preis(double gewicht);
}

class Privattarif implements Preisstrategie {
    @Override
    public double preis(double gewicht) {
        if (gewicht <= 2.0) {
            return 4.99;
        } else if (gewicht <= 10.0) {
            return 7.49;
        }
        return 11.99;
    }
}

class Geschaeftstarif implements Preisstrategie {
    @Override
    public double preis(double gewicht) {
        return 3.20 + 0.25 * gewicht;
    }
}

class Aktionstarif implements Preisstrategie {
    @Override
    public double preis(double gewicht) {
        return 3.99;
    }
}

class Paketauftrag {
    private double gewicht;
    private Preisstrategie strategie;

    public Paketauftrag(double gewicht, Preisstrategie strategie) {
        this.gewicht = gewicht;
        this.strategie = strategie;
    }

    public void setStrategie(Preisstrategie strategie) {
        this.strategie = strategie;
    }

    public double berechnePreis() {
        return strategie.preis(gewicht);
    }
}

Ausgabe (Preise je Tarif, Wechsel zur Laufzeit)

Gewicht      Privattarif Geschaeftstarif    Aktionstarif
  1,5 kg            4,99            3,58            3,99
  2,0 kg            4,99            3,70            3,99
  6,0 kg            7,49            4,70            3,99
 14,0 kg           11,99            6,70            3,99
Strategie zur Laufzeit wechseln:
  6 kg, Privattarif:  7,49 EUR
  6 kg, Aktionstarif: 3,99 EUR

c) Vorteil gegenüber Unterklassen je Tarif (2 P)

Mit dem Strategie-Muster kann der Tarif eines bestehenden Auftrags zur Laufzeit gewechselt werden (setStrategie), z. B. wenn ein Kunde ein Geschäftskonto eröffnet. Bei Unterklassen müsste ein neues Objekt einer anderen Klasse erzeugt und alle Daten müssten übertragen werden. Außerdem bleiben die Tarife unabhängig von Paketauftrag: Neue Tarife erfordern keine Änderung am Auftrag, und es entsteht keine „Klassenexplosion“, wenn weitere Merkmale (z. B. Expressaufträge) mit allen Tarifen kombiniert werden müssen.

a) Funktionsweise und Begründung (4 P)

Funktionsweise: Ein Subject (hier Sendungsstatus) verwaltet eine Liste angemeldeter Observer. Interessierte Objekte (KundenApp, Hallenanzeige) melden sich mit addObserver an. Ändert sich der Zustand des Subjects, ruft es notifyObservers() auf; diese Methode ruft bei jedem angemeldeten Observer update() auf, und jeder Observer aktualisiert sich daraufhin selbst.

Begründung: Eine Statusänderung muss sofort und automatisch an mehrere, unterschiedliche Anzeigen weitergegeben werden. Weil das Subject nur das Interface Observer kennt, können später weitere Anzeigen (Kundenportal) ergänzt werden, ohne Sendungsstatus zu ändern – genau das fordert Anlage 12. Anzeigen müssen den Status nicht ständig abfragen (kein Polling).

b) Ergänztes Klassendiagramm (5 P)

c) Vorteil der Kopplung über das Interface (3 P)

• Lose Kopplung: Sendungsstatus hängt nur vom Interface ab, nicht von den konkreten Anzeigeklassen. Änderungen an KundenApp oder Hallenanzeige wirken sich nicht auf Sendungsstatus aus.
• Erweiterbarkeit: Neue Anzeigen (Kundenportal, Kunden-Mail) implementieren nur Observer und melden sich an – Sendungsstatus muss weder geändert noch neu getestet werden.
• Flexibilität/Polymorphie: Die Liste List<Observer> kann beliebige, verschiedene Observer enthalten; sie lassen sich zur Laufzeit an- und abmelden. Sendungsstatus ist ohne die Anzeigen test- und wiederverwendbar.

d) Sequenzdiagramm (8 P)

e) setStatus, notifyObservers und update (4 P)

// Klasse Sendungsstatus
methode setStatus(status : string) : void
  this.status := status
  notifyObservers()
Ende methode

methode notifyObservers() : void
  zähle i von 0 bis observers.size() - 1
    observers.get(i).update()
  Ende zähle
Ende methode

// Klasse KundenApp
methode update() : void
  letzteMeldung := quelle.getStatus()
  anzeigen()
Ende methode

Java · Aufgabe_OOP_05_3.java (Interfaces, Subject, Observer)

interface Subject {
    void addObserver(Observer o);
    void removeObserver(Observer o);
    void notifyObservers();
}

interface Observer {
    void update();
}

class Sendungsstatus implements Subject {
    private String sendungsNr;
    private String status;
    private List<Observer> observers;

    public Sendungsstatus(String sendungsNr) {
        this.sendungsNr = sendungsNr;
        this.status = "Angekündigt";
        this.observers = new ArrayList<>();
    }

    public String getSendungsNr() {
        return sendungsNr;
    }

    public String getStatus() {
        return status;
    }

    public void setStatus(String status) {
        this.status = status;
        notifyObservers();
    }

    @Override
    public void addObserver(Observer o) {
        observers.add(o);
    }

    @Override
    public void removeObserver(Observer o) {
        observers.remove(o);
    }

    @Override
    public void notifyObservers() {
        for (int i = 0; i < observers.size(); i++) {
            observers.get(i).update();
        }
    }
}

class KundenApp implements Observer {
    private Sendungsstatus quelle;
    private String letzteMeldung;

    public KundenApp(Sendungsstatus quelle) {
        this.quelle = quelle;
        quelle.addObserver(this);
    }

    @Override
    public void update() {
        letzteMeldung = quelle.getStatus();     // Pull: Daten selbst abholen
        anzeigen();
    }

    public void anzeigen() {
        System.out.println("  KundenApp:       " + letzteMeldung);
    }

    public String getLetzteMeldung() {
        return letzteMeldung;
    }
}

class Hallenanzeige implements Observer {
    private Sendungsstatus quelle;
    private int hallenNr;
    private String zeile;

    public Hallenanzeige(Sendungsstatus quelle, int hallenNr) {
        this.quelle = quelle;
        this.hallenNr = hallenNr;
        quelle.addObserver(this);
    }

    @Override
    public void update() {
        zeile = quelle.getStatus();             // Pull
        anzeigen();
    }

    public void anzeigen() {
        System.out.println("  Hallenanzeige " + hallenNr + ": " + zeile);
    }
}

Ausgabe (zwei Statusänderungen, Abmelden der Hallenanzeige, dritte Änderung, Push-Vergleich)

  KundenApp:       In Zustellung
  Hallenanzeige 3: In Zustellung
  KundenApp:       In Paketstation eingelegt
  Hallenanzeige 3: In Paketstation eingelegt
-- Hallenanzeige meldet sich ab --
  KundenApp:       Abgeholt
Letzte Meldung in der App: Abgeholt
-- f) Push-Variante zum Vergleich --
  Push-Observer erhält: KT-4712 -> Im Sortierzentrum

f) Push-Variante (2 P)

Bei der Push-Variante schickt das Subject die geänderten Daten gleich mit: Die Methode erhält Parameter, z. B. update(sendungsNr : string, status : string), und notifyObservers() ruft observers.get(i).update(sendungsNr, status) auf. Der Observer muss den Status nicht mehr mit getStatus() abholen (der Rückaufruf im Sequenzdiagramm entfällt) und braucht keine Referenz quelle mehr. Nachteil: Alle Observer erhalten alle Daten, und bei zusätzlichen Daten ändert sich die Schnittstelle.

interface PushObserver {
    void update(String sendungsNr, String status);   // Daten werden mitgeschickt
}

class StatusQuellePush {
    private String sendungsNr;
    private String status;
    private List<PushObserver> observers = new ArrayList<>();

    public StatusQuellePush(String sendungsNr) {
        this.sendungsNr = sendungsNr;
    }

    public void addObserver(PushObserver o) {
        observers.add(o);
    }

    public void setStatus(String status) {
        this.status = status;
        for (int i = 0; i < observers.size(); i++) {
            observers.get(i).update(sendungsNr, status);
        }
    }
}