Block 08 · Objektorientierung & Entwurfsmuster

A · Erklärungssatz

Objektorientierung kommt in der AP2 selten als „reine Theorie“ vor, sondern fast immer als Kette in einer größeren Aufgabe: Zuerst wird ein Klassendiagramm gezeichnet oder ergänzt (oft mit abstrakter Klasse oder Interface), dann soll ein Begriff wie Polymorphie erläutert werden, und zum Schluss werden einzelne Methoden in Pseudocode implementiert. Entwurfsmuster tauchen in derselben Form auf: Muster erkennen, im Klassendiagramm umsetzen, Ablauf zeigen, Methode programmieren. Beispiele: S22 Teil 1 Aufgabe 3 (Observer, 30 P), S23 Teil 1 Aufgabe 2b (Polymorphie und Fabrikmethode, 22 P), S26 Teil 2 Aufgabe 2 (abstrakte Klasse und dynamische Bindung, 20 P), W24 Teil 1 Aufgabe 4b (Entwurfsmuster, 10 P).

Kategorien laut Themenanalyse: Der ganze Block kommt in 6 von 9 Prüfungen vor („Meistens“). Die Unterthemen OOP-01 bis OOP-03 gehören zu „OOP-Konzepte“ (5/9, Oft), OOP-04 und OOP-05 zu „Entwurfsmuster“ (3/9, Wahrscheinlich).

OOP-01 · Grundkonzepte: Klasse, Objekt, Kapselung Oft

Vorkommen: Teil von „OOP-Konzepte“ (5/9: S22, W22, S23, S24, S26) · ausdrücklich gefragt in S22 T1 A3a (Sichtbarkeiten im Klassendiagramm), S24 T1 A3bc (Objekt über überladenen Konstruktor erzeugen), S26 T2 A2a (Klassen mit vollständigen Signaturen und Sichtbarkeiten) · vorausgesetzt in jeder Algorithmusaufgabe mit Klassengerüst

Klasse und Objekt

Eine Klasse ist der Bauplan (Datentyp) für gleichartige Objekte. Sie legt fest, welche Attribute (Daten, Eigenschaften) und welche Methoden (Operationen, Verhalten) jedes Objekt hat. Ein Objekt (Instanz, Exemplar) ist ein konkretes Exemplar einer Klasse, das zur Laufzeit mit new erzeugt wird. Jedes Objekt hat eigene Attributwerte (seinen Zustand) und eine eigene Identität – zwei Objekte mit gleichen Werten sind trotzdem zwei verschiedene Objekte.

Kapselung und Sichtbarkeiten

Datenkapselung (Geheimnisprinzip, information hiding) bedeutet: Die Attribute eines Objekts sind nach außen verborgen (private). Andere Objekte greifen nur über die öffentlichen Methoden zu. Dadurch entscheidet allein die Klasse, welche Änderungen erlaubt sind – ein Konto lässt sich nur über abheben verringern, und abheben prüft das Limit.

In Prüfungsantworten genügt: protected = Zugriff in der Klasse selbst und in abgeleiteten Klassen (Unterklassen). Dass Java zusätzlich den Zugriff im selben Paket erlaubt, ist eine Java-Besonderheit.

Getter und Setter

• Getter lesen ein Attribut: getSaldo() : double, bei boolean üblich isGesperrt() : boolean.
• Setter ändern ein Attribut: setDispo(dispo : double) : void. Ein guter Setter prüft den Wert und lehnt ungültige Werte ab.
• Nicht jedes Attribut braucht einen Setter. Werte, die sich nach der Erzeugung nicht ändern dürfen (Kontonummer), werden nur im Konstruktor gesetzt; in Java zusätzlich mit final gekennzeichnet.
• In IHK-Aufgaben steht oft „Für alle Attribute existieren Get-Methoden“. Dann benutzt du in deinem Code immer die Getter (k.getSaldo()), nie das Attribut direkt (k.saldo).

Konstruktor, Überladen und this

• Der Konstruktor ist eine besondere Methode mit dem Namen der Klasse und ohne Rückgabetyp. Er wird bei new automatisch aufgerufen und bringt das neue Objekt in einen gültigen Anfangszustand (Attribute setzen, Startwerte, Zähler erhöhen).
• Schreibt man keinen Konstruktor, gibt es automatisch einen parameterlosen Standardkonstruktor. Sobald man selbst einen Konstruktor schreibt, entfällt er.
• Überladen: Mehrere Konstruktoren (oder Methoden) mit gleichem Namen, aber unterschiedlicher Parameterliste (Anzahl, Typen oder Reihenfolge). Der Rückgabetyp allein reicht zur Unterscheidung nicht.
• this verweist auf das aktuelle Objekt:
  1. this.saldo := saldo – unterscheidet das Attribut vom gleichnamigen Parameter,
  2. this(kontoNr, inhaber, 0.0) – ruft einen anderen Konstruktor derselben Klasse auf (muss die erste Anweisung sein) und vermeidet doppelten Code,
  3. bank.registrieren(this) – übergibt das eigene Objekt an ein anderes Objekt (wichtig beim Observer-Muster).

Statische Attribute und Methoden (Klassenattribute, Klassenmethoden)

Ein mit static gekennzeichnetes Attribut gehört zur Klasse, nicht zu einem einzelnen Objekt. Es existiert genau einmal und wird von allen Objekten geteilt. Eine statische Methode wird über den Klassennamen aufgerufen (Konto.getAnzahlKonten()), auch wenn noch kein Objekt existiert. Sie hat kein this und kann deshalb nicht direkt auf Instanzattribute zugreifen.

• Typische Verwendung: Zähler für erzeugte Objekte, fortlaufende Nummern, Konstanten (static final), Hilfsmethoden (Math.sqrt), Fabrikmethoden und Singleton (OOP-04).
• UML: statische Elemente werden unterstrichen. Der IHK-Belegsatz erlaubt alternativ die Eigenschaft {static} hinter der Signatur.

Beispiel: vom Klassendiagramm zu Pseudocode und Java

Pseudocode

klasse Konto
  - anzahlKonten : integer := 0   {static}
  - kontoNr : string
  - inhaber : string
  - saldo : double
  - dispo : double

  konstruktor Konto(kontoNr : string,
                    inhaber : string, dispo : double)
    this.kontoNr := kontoNr
    this.inhaber := inhaber
    saldo := 0.0
    this.dispo := 0.0
    setDispo(dispo)
    anzahlKonten := anzahlKonten + 1
  Ende konstruktor

  konstruktor Konto(kontoNr : string, inhaber : string)
    this(kontoNr, inhaber, 0.0)
  Ende konstruktor

  methode setDispo(dispo : double) : void
    wenn dispo >= 0 und dispo <= 2000 dann
      this.dispo := dispo
    Ende wenn
  Ende methode

  methode abheben(betrag : double) : boolean
    wenn betrag > 0 und saldo - betrag >= -dispo dann
      saldo := saldo - betrag
      rückgabe true
    Ende wenn
    rückgabe false
  Ende methode

  methode getAnzahlKonten() : integer   {static}
    rückgabe anzahlKonten
  Ende methode
Ende klasse

Java (mit equals, siehe unten „Identität und Gleichheit“)

class Konto {
    private static int anzahlKonten = 0;
    private final String kontoNr;
    private String inhaber;
    private double saldo;
    private double dispo;

    public Konto(String kontoNr, String inhaber, double dispo) {
        this.kontoNr = kontoNr;
        this.inhaber = inhaber;
        this.saldo = 0.0;
        this.dispo = 0.0;
        setDispo(dispo);
        anzahlKonten = anzahlKonten + 1;
    }

    public Konto(String kontoNr, String inhaber) {
        this(kontoNr, inhaber, 0.0);
    }

    public void setDispo(double dispo) {
        if (dispo >= 0 && dispo <= 2000) {
            this.dispo = dispo;
        }
    }

    public boolean abheben(double betrag) {
        if (betrag > 0 && saldo - betrag >= -dispo) {
            saldo = saldo - betrag;
            return true;
        }
        return false;
    }

    public static int getAnzahlKonten() {
        return anzahlKonten;
    }

    public double getSaldo() {
        return saldo;
    }

    @Override
    public boolean equals(Object o) {
        return o instanceof Konto && kontoNr.equals(((Konto) o).kontoNr);
    }
}

Aufruf: Konto k1 = new Konto("DE01", "Yilmaz", 500.0); und Konto k2 = new Konto("DE02", "Novak"); – danach liefert Konto.getAnzahlKonten() den Wert 2. k2.abheben(50.0) liefert false, weil k2 keinen Dispo hat.

Klassen in Pseudocode – Schreibweise in diesem Block

Der IHK-Belegsatz legt nur die Kontrollstrukturen fest. Für Klassen ist jede eindeutige Schreibweise zulässig. Diese wird in den Lösungen verwendet:

Referenzen, null, Identität und Gleichheit

Eine Variable vom Typ einer Klasse enthält nicht das Objekt selbst, sondern einen Verweis (Referenz) darauf. Eine Zuweisung k3 := k1 kopiert nur den Verweis: Danach zeigen beide Variablen auf dasselbe Objekt (Aliasing), und eine Änderung über k3 ist auch über k1 sichtbar. null bedeutet „zeigt auf kein Objekt“; ein Methodenaufruf auf null führt zur NullPointerException.

So gehst du vor: Klasse aus Text oder Klassendiagramm umsetzen

1. Attribute sammeln: Jedes Substantiv mit einem Wert („Fachnummer“, „ob gesperrt“) wird ein Attribut mit passendem Typ (integer, double, string, boolean, eine Klasse oder List<…>). Sichtbarkeit -.
2. Klassenweite Werte erkennen: „für alle Objekte gemeinsam“, „Anzahl aller …“, „ohne dass ein Objekt existiert“ → static (unterstrichen).
3. Konstruktoren: Welche Werte müssen beim Erzeugen feststehen? Weitere Varianten mit Standardwerten als überladene Konstruktoren, die per this(…) den vollständigen Konstruktor aufrufen.
4. Getter und Setter nur dort, wo sie gebraucht werden; Setter prüfen Werte; unveränderliche Werte bekommen keinen Setter.
5. Fachmethoden: Name als Verb, Parameter mit Typ, Rückgabetyp. Vorbedingungen prüfen (wenn … dann), Zustand ändern, Erfolg melden (boolean) oder ein Objekt bzw. null zurückgeben.
6. Beziehungen: Ein Attribut, dessen Typ eine andere Klasse ist, wird im Diagramm als (gerichtete) Assoziation zu dieser Klasse gezeichnet.

OOP-02 · Vererbung, abstrakte Klassen und Interfaces Oft

Vorkommen: Teil von „OOP-Konzepte“ (5/9) · S23 T1 A2bb (9 P: abstrakte Klasse mit Unterklassen statt Fallunterscheidungen), S23 T1 A2bd (4 P: überschreibende Methoden), S26 T2 A2a (12 P: abstrakte Klasse, Vererbung, Aggregation), S22 T1 A3bb/bc (6 P: Interface-Methoden ergänzen, Realisierung erläutern)

Vererbung (Generalisierung und Spezialisierung)

Vererbung ist eine „ist-ein“-Beziehung: Die Unterklasse (abgeleitete Klasse, Subklasse) übernimmt alle Attribute und Methoden der Oberklasse (Basisklasse, Superklasse), kann neue hinzufügen und geerbte Methoden überschreiben. Gemeinsamkeiten stehen nur einmal in der Oberklasse (Generalisierung), Besonderheiten in den Unterklassen (Spezialisierung).

• Java: class Azubi extends Mitarbeiter – genau eine Oberklasse. UML: durchgezogene Linie mit hohlem Dreieck an der Oberklasse.
• Private Attribute der Oberklasse werden zwar geerbt, sind in der Unterklasse aber nicht direkt zugreifbar – Zugriff über Getter oder das Attribut # (protected) machen.
• Prüffrage: „Ist ein X ein Y?“ – Ein Azubi ist ein Mitarbeiter ✓. Ein Motor ist kein Auto, das Auto hat einen Motor → Assoziation bzw. Komposition, keine Vererbung.
• Vorteile: keine Redundanz, Wiederverwendung, Erweiterbarkeit durch neue Unterklassen, Grundlage für Polymorphie (OOP-03). Nachteile: enge Kopplung (eine Änderung der Oberklasse wirkt auf alle Unterklassen), tiefe Hierarchien sind schwer zu überblicken.

Konstruktoren und super

Konstruktoren werden nicht vererbt. Jeder Konstruktor einer Unterklasse ruft als erste Anweisung einen Konstruktor der Oberklasse auf: ausdrücklich mit super(…) oder – wenn man nichts schreibt – automatisch mit super(). Das automatische super() funktioniert nur, wenn die Oberklasse einen parameterlosen Konstruktor hat. Der Oberklassenteil eines Objekts wird also immer zuerst initialisiert („von oben nach unten“).

class Person {
    private String name;

    public Person(String name) {
        this.name = name;
        System.out.println("Person " + name + " angelegt");
    }
}

class Kunde extends Person {
    private int kundenNr;

    public Kunde(String name, int kundenNr) {
        super(name);                   // muss die erste Anweisung sein
        this.kundenNr = kundenNr;
        System.out.println("Kunde " + kundenNr + " angelegt");
    }
}

class Firmenkunde extends Kunde {
    private String firma;

    public Firmenkunde(String name, int kundenNr, String firma) {
        super(name, kundenNr);
        this.firma = firma;
        System.out.println("Firmenkunde " + firma + " angelegt");
    }
}

Aufruf und Ausgabe

new Firmenkunde("Kaya", 4711, "Kaya Bau GmbH");

Person Kaya angelegt
Kunde 4711 angelegt
Firmenkunde Kaya Bau GmbH angelegt

Mit super.methode() ruft eine Unterklasse außerdem die Oberklassen-Version einer überschriebenen Methode auf, z. B. rückgabe super.urlaubstage() + 2.

protected und final

• protected (#): sichtbar in der eigenen Klasse und in allen Unterklassen – für Attribute, die Unterklassen direkt lesen oder setzen sollen.
• final bei einer Klasse: keine Unterklassen möglich (Beispiel String). Bei einer Methode: darf nicht überschrieben werden. Bei einem Attribut: darf nur einmal zugewiesen werden; static final = Konstante.

Abstrakte Klassen

• Kennzeichnung: Java abstract; UML: Klassenname kursiv und/oder {abstract}, abstrakte Methoden ebenfalls kursiv bzw. mit {abstract}.
• Von einer abstrakten Klasse können keine Objekte erzeugt werden (new Mitarbeiter(…) ist verboten). Variablen, Parameter und Listen dürfen aber diesen Typ haben (List<Mitarbeiter>).
• Sie darf Attribute, Konstruktoren (für die Unterklassen), konkrete und abstrakte Methoden enthalten.
• Eine abstrakte Methode hat nur eine Signatur, keinen Rumpf. Jede konkrete Unterklasse muss sie implementieren (überschreiben) – sonst ist die Unterklasse selbst abstrakt.
• Wann? Wenn es einen Oberbegriff gibt, von dem es keine „allgemeinen“ Objekte geben soll (es gibt nur Angestellte, Aushilfen und Azubis, aber keinen „Mitarbeiter an sich“), die Unterklassen aber gemeinsame Attribute und gemeinsamen Code haben.

Interfaces (Schnittstellen)

• Ein Interface ist ein Vertrag: Jede Klasse, die es implementiert, garantiert die vorgegebenen Methoden. Es enthält nur Methodensignaturen (implizit public abstract) und Konstanten, keine Instanzattribute und keinen Konstruktor. (Seit Java 8 sind default-Methoden möglich – für die Prüfung nicht nötig.)
• Eine Klasse kann beliebig viele Interfaces implementieren: class Rechnung implements Druckbar, Exportierbar.
• UML: «interface» über dem Namen; Realisierung (Implementierung) = gestrichelte Linie mit hohlem Dreieck am Interface.
• Ein Interface beschreibt eine Fähigkeit oder Rolle („kann gedruckt werden“, „kann verglichen werden“, „kann beobachten“), die ganz unterschiedliche, sonst nicht verwandte Klassen haben können.

Abstrakte Klasse oder Interface?

Keine Mehrfachvererbung von Klassen

In Java und C# kann eine Klasse nur von einer Klasse erben. Grund ist das Diamond-Problem: Erben B und C von A und überschreiben beide die Methode m(), wäre bei einer Klasse D extends B, C unklar, welches m() gilt und ob die Attribute von A einmal oder doppelt vorhanden sind. Interfaces haben dieses Problem nicht, weil sie weder Zustand noch (verpflichtende) Implementierung mitbringen: Die implementierende Klasse schreibt die Methode selbst, es gibt also nur eine Implementierung. Deshalb gilt: eine Oberklasse, beliebig viele Interfaces. (C++ erlaubt Mehrfachvererbung und muss den Konflikt mit zusätzlichen Regeln lösen.)

Redundante Fallunterscheidungen durch Vererbung ersetzen

Ein klassischer Prüfungsfall (S23): Eine Klasse hat ein Attribut typ und mehrere Methoden, die alle mit derselben Fallunterscheidung (wenn typ = … dann …) arbeiten. Jeder neue Typ zwingt dazu, alle diese Methoden zu ändern – vergisst man eine, entsteht ein Fehler. Beispiel aus einer Personalverwaltung:

Jede Unterklasse implementiert nur „ihre Spalte“ der Tabelle. Beispiel Aushilfe:

klasse Aushilfe erbt von Mitarbeiter
  - stundenlohn : double
  - stunden : double

  konstruktor Aushilfe(name : string,
                       stundenlohn : double)
    super(name)
    this.stundenlohn := stundenlohn
    stunden := 0.0
  Ende konstruktor

  methode setStunden(stunden : double) : void
    this.stunden := stunden
  Ende methode

  methode gehalt() : double
    rückgabe stundenlohn * stunden
  Ende methode

  methode urlaubstage() : integer
    rückgabe 0
  Ende methode
Ende klasse

In Java entspricht erbt von dem Schlüsselwort extends, die überschreibenden Methoden werden mit @Override markiert.

So gehst du vor

1. Jeder Wert des Typ-Attributs wird eine Unterklasse (Name aus dem Fachbegriff: "AZUBI" → Azubi, "ANGESTELLT" → Angestellter).
2. Die Oberklasse wird abstrakt, das Attribut typ entfällt (auch aus dem Konstruktor).
3. Was für alle Typen gleich ist (Attribute, Getter, gleiche Methoden), bleibt nur in der Oberklasse – nicht in den Unterklassen wiederholen.
4. Jede Methode mit Fallunterscheidung wird in der Oberklasse abstrakt (kursiv bzw. {abstract}) und in jeder Unterklasse mit genau ihrem Zweig implementiert.
5. Nur für einen Typ benötigte Attribute (lehrjahr, stundenlohn) wandern in die passende Unterklasse.
6. Haben nur einige Typen eine Fähigkeit, wird sie als Interface modelliert, das nur diese Unterklassen realisieren.
7. Wer entscheidet beim Erzeugen, welche Unterklasse gebraucht wird? → Fabrikmethode (OOP-04).
8. Pfeile prüfen: Dreieck immer an der Oberklasse bzw. am Interface.

Vorteil des neuen Entwurfs: Ein neuer Typ ist eine neue Unterklasse; bestehende, getestete Klassen bleiben unverändert (Open-Closed-Prinzip: offen für Erweiterung, geschlossen für Änderung). Keine vergessenen Zweige, kürzere und verständlichere Methoden.

OOP-03 · Polymorphie, Überladen/Überschreiben, Generics Oft

Vorkommen: Teil von „OOP-Konzepte“ (5/9) · Polymorphie: S23 T1 A2ba (4 P: Begriff erläutern), S26 T2 A2bb (4 P: Mechanismus nennen und erklären) · überschreibende Methoden: S23 T1 A2bd · Generics: W22 T2 A1c (3 P: generische Klasse erläutern), W22 T2 A1d (7 P: Sortieren einer List<T>) · Vergleichsfunktion als Parameter: W22 T2 A1b, S24 T2 A2a

Polymorphie (Vielgestaltigkeit)

Beispiel Stadtbibliothek: Die abstrakte Klasse Medium hat die abstrakte Methode leihfrist() : integer. Buch liefert 28 Tage, DVD 7 Tage, Zeitschrift 14 Tage. Eine Methode, die alle Medien einer Ausleihe durchläuft, ruft einfach m.leihfrist() auf – jedes Objekt antwortet mit seiner eigenen Implementierung:

methode laengsteFrist(medien : List<Medium>)
        : integer
  max : integer := 0
  zähle i von 0 bis medien.size() - 1
    m : Medium := medien.get(i)
    frist : integer := m.leihfrist()
    // welches leihfrist()? Das Objekt
    // entscheidet (dynamische Bindung)
    wenn frist > max dann
      max := frist
    Ende wenn
  Ende zähle
  rückgabe max
Ende methode

Kommt später eine neue Medienart hinzu (z. B. Hoerbuch mit 21 Tagen), wird nur eine neue Unterklasse geschrieben – die Methode laengsteFrist bleibt unverändert.

Statischer und dynamischer Typ

Bei Medium m := new DVD("Metropolis") ist Medium der statische Typ (deklarierter Typ der Variablen) und DVD der dynamische Typ (Klasse des Objekts, auf das m gerade zeigt).

Überschreiben und Überladen

Medium m = new Buch("Faust");
Buch b = new Buch("Woyzeck");
drucker.drucke(m);   // Ausgabe: Medium   (statischer Typ von m ist Medium!)
drucker.drucke(b);   // Ausgabe: Buch

Upcast, Downcast und instanceof

• Upcast (Unterklasse → Oberklasse) geschieht automatisch und ist immer sicher: Medium m := new DVD(…).
• Downcast (Oberklasse → Unterklasse) muss ausdrücklich geschrieben werden: DVD d = (DVD) m;. Der Compiler erlaubt ihn, wenn die Typen verwandt sind. Zeigt m zur Laufzeit aber nicht auf eine DVD, entsteht eine ClassCastException.
• Deshalb vorher mit instanceof prüfen: if (m instanceof DVD) { DVD d = (DVD) m; … } (ab Java 16 kürzer: if (m instanceof DVD d) { … }). In Pseudocode: wenn m ist DVD dann.
• Viele instanceof-Abfragen sind ein Zeichen für schlechten Entwurf – meist gehört das Verhalten als überschriebene Methode in die Unterklassen.

Generics: generische Klassen und Methoden

Eine generische Klasse hat einen oder mehrere Typparameter (Platzhalter für einen Datentyp), z. B. class Warteschlange<T>. Erst beim Verwenden wird der konkrete Typ festgelegt: Warteschlange<Patient>, Warteschlange<String>. Die bekanntesten generischen Klassen sind die Collections: List<T>, Map<K, V>.

klasse Warteschlange<T>
  - elemente : List<T>

  konstruktor Warteschlange()
    elemente := new List<T>()
  Ende konstruktor

  methode einreihen(e : T) : void
    elemente.add(e)
  Ende methode

  methode naechster() : T
    wenn elemente.size() = 0 dann
      rückgabe null
    Ende wenn
    erster : T := elemente.get(0)
    elemente.remove(erster)
    rückgabe erster
  Ende methode
Ende klasse

Verwendung (Java)

Warteschlange<Patient> praxis = new Warteschlange<>();
praxis.einreihen(new Patient("Ahmadi"));
praxis.einreihen(new Patient("Brandt"));
Patient naechster = praxis.naechster();   // kein Cast nötig
// praxis.einreihen("Brandt");            // Compilerfehler: String ist kein Patient

Vorteile gegenüber einer Klasse, die Elemente vom Typ Object speichert:

• Typsicherheit beim Übersetzen: In eine Warteschlange<Patient> lässt der Compiler nur Patient-Objekte hinein. Mit Object passt alles hinein, ein falscher Typ fällt erst zur Laufzeit als ClassCastException auf.
• Keine Typumwandlungen (Casts) beim Herausholen – der Rückgabetyp ist bereits Patient.
• Wiederverwendbarkeit: Eine einzige Implementierung funktioniert für beliebige Typen, ohne Code zu kopieren (PatientenWarteschlange, AuftragsWarteschlange …).
• Lesbarkeit: Am Typ sieht man sofort, was gespeichert wird.

Weitere Formen: generische Methode mit eigenem Typparameter (<T> T letztes(List<T> liste)), beschränkter Typparameter <T extends Medium> – dann dürfen auf T die Methoden von Medium aufgerufen werden. Typparameter stehen nur für Referenztypen: List<Integer>, nicht List<int>.

Funktionsobjekte: eine Vergleichsfunktion als Parameter

Ein generischer Algorithmus (Sortieren, Minimum, „ist die Liste sortiert?“) weiß nicht, wie zwei Objekte vom Typ T zu vergleichen sind. Deshalb bekommt er ein Objekt mit einer Vergleichsmethode übergeben – in Java das Interface Comparator<T> mit compare(a, b):

• Ergebnis negativ: a kommt vor b (a ist „kleiner“), 0: gleichwertig, positiv: a kommt nach b.
• Für jedes Kriterium gibt es eine eigene Klasse (oder in Java einen Lambda-Ausdruck). Der Algorithmus ruft nur v.compare(a, b) auf – das ist wieder Polymorphie (und das Strategie-Muster, OOP-05).

// true, wenn die Liste nach dem Kriterium v
// aufsteigend sortiert ist
methode istAufsteigend<T>(liste : List<T>,
                          v : Comparator<T>) : boolean
  zähle i von 1 bis liste.size() - 1
    wenn v.compare(liste.get(i - 1), liste.get(i)) > 0 dann
      rückgabe false
    Ende wenn
  Ende zähle
  rückgabe true
Ende methode

Verwendung in Java (Vergleichsfunktion als Lambda-Ausdruck)

List<Buch> buecher = new ArrayList<>();
buecher.add(new Buch("Faust", 1808));
buecher.add(new Buch("Woyzeck", 1879));
Comparator<Buch> nachJahr = (x, y) -> x.getJahr() - y.getJahr();
boolean ok = istAufsteigend(buecher, nachJahr);   // true

Das Sortieren mit Vergleichsfunktion (Bubblesort) ist in Block 02 (ALG-05) ausführlich behandelt.

OOP-04 · Entwurfsmuster: Grundlagen, Kategorien, Erzeugungsmuster Wahrscheinlich

Vorkommen: Teil von „Entwurfsmuster“ (3/9: S22, S23, W24) · W24 T1 A4ba (4 P: zwei Vorteile von Entwurfsmustern), W24 T1 A4bb (2 P: Beispiele für Erzeugungs- und Verhaltensmuster) · S23 T1 A2bb/bc (statische Fabrikmethode im Klassendiagramm modellieren und in Pseudocode implementieren)

Was ist ein Entwurfsmuster?

Ein Entwurfsmuster (Design Pattern) ist eine bewährte, wiederverwendbare Lösungsvorlage für ein wiederkehrendes Entwurfsproblem der Softwareentwicklung. Es ist kein fertiger Code und keine Bibliothek, sondern eine Idee mit typischer Struktur (beteiligte Klassen, Interfaces und ihre Beziehungen), die auf die konkrete Situation übertragen wird. Bekannt wurde das Konzept durch den Katalog der „Gang of Four“ (Gamma, Helm, Johnson, Vlissides, 1994) mit 23 Mustern. Jedes Muster wird beschrieben durch Name, Problem, Lösung und Konsequenzen (Vor- und Nachteile).

Nachteile: zusätzliche Klassen und Indirektion (mehr Komplexität), Gefahr des „Overengineering“ (Muster ohne echtes Problem), Einarbeitungsaufwand, falsch gewählte Muster erschweren die Wartung.

Die drei Kategorien

Singleton

Zweck: Von einer Klasse darf es höchstens ein Objekt geben, und alle Programmteile sollen über einen globalen Zugriffspunkt genau dieses Objekt erhalten. Typische Einsätze: zentrales Protokoll (Logger), Konfiguration, Verbindungspool, Druckwarteschlange.

Aufbau (drei Bausteine):

1. ein privates statisches Attribut, das die einzige Instanz speichert (anfangs null),
2. ein privater Konstruktor – von außen ist kein new möglich,
3. eine öffentliche statische Methode getInstance(), die beim ersten Aufruf das Objekt erzeugt („lazy“) und danach immer dasselbe Objekt zurückgibt.

class Protokoll {
    private static Protokoll instanz = null;

    private Protokoll() {
        // z. B. Protokolldatei öffnen
    }

    public static synchronized Protokoll getInstance() {
        if (instanz == null) {
            instanz = new Protokoll();
        }
        return instanz;
    }

    public void schreibe(String text) {
        System.out.println("[LOG] " + text);
    }
}

Aufruf überall im Programm: Protokoll.getInstance().schreibe("Start"). Protokoll.getInstance() == Protokoll.getInstance() liefert true.

Thread-Sicherheit: Rufen zwei Threads getInstance() gleichzeitig zum ersten Mal auf, können beide instanz = null sehen und je ein Objekt erzeugen – dann gibt es zwei. Abhilfe: die Methode synchronized deklarieren (nur ein Thread gleichzeitig), das Objekt schon beim Laden der Klasse erzeugen (private static final Protokoll INSTANZ = new Protokoll();, „eager“) oder in Java ein enum mit genau einem Wert verwenden.

Nachteile: globaler Zustand und versteckte Abhängigkeiten (man sieht einer Methode nicht an, dass sie das Singleton benutzt), schlecht testbar (das Objekt lässt sich nicht durch eine Testattrappe ersetzen), Probleme bei Nebenläufigkeit, die Klasse kümmert sich zusätzlich um ihre eigene Erzeugung.

Fabrikmethode (Factory Method) und statische Fabrikmethode

Problem: An vielen Stellen im Code steht eine Fallunterscheidung, die je nach Parameter eine andere konkrete Klasse mit new erzeugt. Kommt eine Klasse hinzu, müssen alle diese Stellen geändert werden, und der aufrufende Code hängt von allen konkreten Klassen ab.

Lösung (statische Fabrikmethode, wie in S23): Eine einzige – meist statische – Methode in der Oberklasse oder in einer eigenen Fabrikklasse entscheidet anhand eines Parameters, welches Objekt erzeugt wird, und gibt es mit dem Typ der Oberklasse bzw. des Interfaces zurück. Der aufrufende Code kennt nur noch die Abstraktion.

Beispiel: Berichte sollen als CSV, JSON oder XML exportiert werden.

methode erzeugeExporter(format : string) : Exporter  {static}
  wenn format = "CSV" dann
    rückgabe new CsvExporter()
  sonst wenn format = "JSON" dann
    rückgabe new JsonExporter()
  sonst wenn format = "XML" dann
    rückgabe new XmlExporter()
  Ende wenn
  rückgabe null      // unbekanntes Format
Ende methode

// Verwendung – keine Fallunterscheidung mehr:
e : Exporter := Exporter.erzeugeExporter(wahl)
e.exportiere(bericht)

Vorteile: Die Erzeugungslogik steht an einer Stelle (eine neue Klasse = eine Änderung in der Fabrik), der aufrufende Code ist unabhängig von den konkreten Klassen (lose Kopplung), redundante Fallunterscheidungen verschwinden, die Fabrik kann Parameter prüfen und Standardwerte setzen.

Fabrikmethode im Sinne der Gang of Four: Statt einer statischen Methode deklariert eine abstrakte „Erzeuger“-Klasse eine abstrakte Methode erzeugeProdukt(); jede Unterklasse des Erzeugers überschreibt sie und entscheidet so, welches konkrete Produkt entsteht. Die Abstrakte Fabrik erweitert die Idee auf ganze Familien zusammengehöriger Objekte (z. B. alle Bedienelemente im hellen oder dunklen Design). In der Prüfung genügt meist die statische Variante.

Builder (Erbauer) – kurz

Problem: Ein Objekt hat viele, teils optionale Angaben. Konstruktoren mit vielen Parametern sind unlesbar (new Reise("Rom", null, true, false, 2, null)) oder man braucht unzählige überladene Konstruktoren. Lösung: Eine eigene Builder-Klasse sammelt die Angaben Schritt für Schritt über sprechende Methoden und erzeugt mit build() das fertige, vollständig geprüfte Objekt.

Reise r = new Reise.Builder("Rom")      // Pflichtangabe
        .hotel("Albergo Sole")          // optionale Angaben
        .personen(2)
        .build();                       // prüft und erzeugt das Objekt

OOP-05 · Verhaltens- und Strukturmuster: Observer, Strategie, MVC, Adapter, Fassade, Decorator Wahrscheinlich

Vorkommen: Teil von „Entwurfsmuster“ (3/9) · Observer: S22 T1 A3 (durchgängig: Beziehung im Klassendiagramm, Interface-Methoden, Realisierung erläutern, Sequenzdiagramm, notifyObservers in Pseudocode – 23 der 30 P), W24 T1 A4bc (4 P: geeignetes Muster für die Aktualisierung aller Anzeigen nennen und begründen)

Observer (Beobachter)

Problem: Ein Objekt ändert seinen Zustand, und beliebig viele andere Objekte sollen darüber automatisch informiert werden – ohne dass das geänderte Objekt deren konkrete Klassen kennen muss (1:n-Abhängigkeit, lose Kopplung). Signalwörter in der Aufgabe: „sobald sich … ändert, sollen alle Anzeigen aktualisiert werden“, „weitere Anzeigen sollen später hinzukommen“, „App, Display und Verwaltung zeigen denselben Wert“.

Beispiel Kühlhaus: Ein Temperatursensor misst die Temperatur. Bei jeder neuen Messung sollen eine Anzeigetafel und eine Alarmanlage informiert werden; später kommt ein Protokoll dazu.

Pseudocode (Methoden des Temperatursensors)

methode addObserver(o : Observer) : void
  observers.add(o)
Ende methode

methode removeObserver(o : Observer) : void
  observers.remove(o)
Ende methode

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

methode setTemperatur(t : double) : void
  temperatur := t
  notifyObservers()      // nach jeder Änderung!
Ende methode

Der zeitliche Ablauf: Zuerst melden sich die Beobachter an. Bei einer neuen Messung ruft der Sensor sich selbst notifyObservers() auf; diese Methode ruft nacheinander update(…) bei jedem angemeldeten Objekt auf. Erst wenn alle fertig sind, kehrt der Aufruf zurück.

Push oder Pull? Es gibt zwei Varianten, wie die Beobachter an die neuen Daten kommen:

Vorteile des Observer-Musters: lose Kopplung (das Subjekt kennt nur das Interface), beliebig viele Beobachter zur Laufzeit an- und abmeldbar, neue Beobachter-Klassen ohne Änderung des Subjekts (Erweiterbarkeit), kein ständiges Abfragen (Polling). Nachteile: Reihenfolge der Benachrichtigung nicht festgelegt, Kaskaden von Aktualisierungen, vergessenes Abmelden hält Objekte im Speicher, Ablauf schwerer nachvollziehbar.

Strategie (Strategy)

Problem: Für eine Aufgabe gibt es mehrere Verfahren (Algorithmen), die austauschbar sein sollen – auch zur Laufzeit – ohne dass die nutzende Klasse lange wenn … sonst wenn …-Ketten enthält. Lösung: Jedes Verfahren wird in eine eigene Klasse gekapselt, die ein gemeinsames Interface realisiert. Die nutzende Klasse (Kontext) hat ein Attribut vom Typ des Interfaces und delegiert die Arbeit an das gerade eingesetzte Strategie-Objekt.

// in der Klasse Navigation (Kontext)
methode setStrategie(s : Routenstrategie) : void
  strategie := s
Ende methode

methode planeRoute(start : string, ziel : string) : Route
  rückgabe strategie.berechneRoute(start, ziel)
Ende methode

Navigation nav = new Navigation(new SchnellsteRoute());
Route r1 = nav.planeRoute("Kiel", "Lübeck");
nav.setStrategie(new Fahrradroute());   // Wechsel zur Laufzeit
Route r2 = nav.planeRoute("Kiel", "Lübeck");

Strategie statt Unterklassen des Kontexts: Das Verfahren kann zur Laufzeit gewechselt werden; es entstehen keine Unterklassen für jede Kombination (Navigation für Auto mit schnellster Route, Navigation für Fahrrad …); jedes Verfahren ist einzeln test- und wiederverwendbar; neue Verfahren ändern den Kontext nicht. Das Prinzip dahinter: Komposition statt Vererbung. (Ähnlich aufgebaut ist das Zustandsmuster; dort wechselt das Objekt sein Verhalten aber selbst, je nach Zustand.)

MVC (Model-View-Controller)

Architekturmuster für Anwendungen mit Benutzeroberfläche. Es trennt die Anwendung in drei Teile mit klaren Zuständigkeiten:

Vorteile: Trennung der Zuständigkeiten, Oberfläche austauschbar (Web, App) bei gleichem Model, mehrere Ansichten derselben Daten, parallele Entwicklung im Team, Model ohne Oberfläche testbar.

Adapter

Problem: Eine vorhandene Klasse (Fremdbibliothek, Altsystem) bietet die benötigte Funktion, aber mit einer anderen Schnittstelle als erwartet, und sie darf oder kann nicht geändert werden. Lösung: Eine Adapter-Klasse realisiert die erwartete Schnittstelle und leitet jeden Aufruf – übersetzt – an das vorhandene Objekt weiter. Beispiel: Die Kühlhaus-Software erwartet Temperaturquelle.getCelsius(), ein neu gekaufter Sensor liefert über seine Bibliothek nur readFahrenheit().

Fassade (Facade)

Problem: Ein Teilsystem besteht aus vielen Klassen, die in einer bestimmten Reihenfolge benutzt werden müssen. Jeder Nutzer müsste alle kennen. Lösung: Eine Fassadenklasse bietet eine einfache, vereinheitlichte Schnittstelle und ruft intern die Klassen des Teilsystems auf. Beispiel: Ein Reiseportal ruft nur ReiseFassade.bucheReise(kunde, angebot) auf; die Fassade reserviert Flug und Hotel, zieht die Zahlung ein und verschickt die Bestätigung.

Abgrenzung: Ein Adapter macht eine vorhandene Schnittstelle passend zu einer erwarteten. Eine Fassade vereinfacht viele Schnittstellen zu einer neuen, einfacheren.

Decorator (Dekorierer)

Problem: Objekte sollen zur Laufzeit beliebig kombinierbare Zusatzfunktionen erhalten. Eine Unterklasse für jede Kombination würde zur „Klassenexplosion“ führen. Lösung: Ein Decorator realisiert dieselbe Schnittstelle wie das Objekt, das er „umhüllt“, hält eine Referenz darauf, leitet Aufrufe weiter und ergänzt eigenes Verhalten. Decorator lassen sich beliebig verschachteln. Beispiel Café: new Sirup(new Milch(new Kaffee())) – preis() ergibt 2,50 + 0,30 + 0,50 = 3,30 €. Bekanntes Java-Beispiel: new BufferedReader(new FileReader("daten.txt")).

Welches Muster passt? Signalwörter

B · Belegsatz

Enthält nur, was dir auch die IHK beilegen würde: die Notationshilfen (UML-Klassendiagramm und UML-Sequenzdiagramm wie in den Belegsätzen S22/S24, Pseudocode-Konventionen wie S24) und die Anlagen zur Ausgangssituation. Keine Erklärungen.

UML-Klassendiagramm

UML-Sequenzdiagramm

Pseudocode, prozedurale Programmierung

wenn [ Bedingung ] dann
   [ Anweisung ]
sonst
   [ Anweisung ]
Ende wenn

zähle [ Variable ] von [ Startwert ] bis [ Endwert ]
   [ Schleifeninhalt ]
Ende zähle

solange [ Bedingung ]
   [ Schleifeninhalt ]
Ende solange

wiederhole
   [ Schleifeninhalt ]
solange [ Bedingung ]

:=

=; <; >; <=; >=; <>

integer
double
string
boolean
array

class Etikett {
    private static int naechsteNr = 1000;
    private int nummer;
    private String empfaenger;
    private double gewicht;

    public Etikett(String empfaenger, double gewicht) {
        this.nummer = naechsteNr;
        naechsteNr = naechsteNr + 1;
        this.empfaenger = empfaenger;
        this.gewicht = 1.0;
        setGewicht(gewicht);
    }

    public Etikett(String empfaenger) {
        this(empfaenger, 1.0);
    }

    public void setGewicht(double gewicht) {
        if (gewicht > 0 && gewicht <= 31.5) {
            this.gewicht = gewicht;
        }
    }

    public int getNummer() {
        return nummer;
    }

    public static int getAnzahl() {
        return naechsteNr - 1000;
    }

    @Override
    public boolean equals(Object o) {
        if (!(o instanceof Etikett)) {
            return false;
        }
        Etikett e = (Etikett) o;
        return empfaenger.equals(e.empfaenger) && gewicht == e.gewicht;
    }

    @Override
    public int hashCode() {
        return empfaenger.hashCode() + Double.hashCode(gewicht);
    }

    @Override
    public String toString() {
        return nummer + " | " + empfaenger + " | " + gewicht + " kg";
    }
}

abstract class Fahrzeug {
    private String kennung;
    protected int reichweiteKm;

    public Fahrzeug(String kennung, int reichweiteKm) {
        this.kennung = kennung;
        this.reichweiteKm = reichweiteKm;
        System.out.println("Fahrzeug " + kennung + " angelegt");
    }

    public String getKennung() {
        return kennung;
    }

    public abstract double kostenProKm();

    public final String info() {
        return kennung + " (" + reichweiteKm + " km)";
    }
}

interface Kuehlbar {
    boolean kuehlen(int zielTemperatur);
}

class Lastenrad extends Fahrzeug {
    public Lastenrad(String kennung) {
        super(kennung, 60);
        System.out.println("Lastenrad " + getKennung() + " bereit");
    }

    @Override
    public double kostenProKm() {
        return 0.05;
    }
}

class Kuehltransporter extends Fahrzeug implements Kuehlbar {
    private int temperatur;

    public Kuehltransporter(String kennung, int reichweiteKm) {
        super(kennung, reichweiteKm);
        temperatur = 20;
        System.out.println("Kuehlung auf " + temperatur + " Grad");
    }

    @Override
    public double kostenProKm() {
        return 0.32;
    }

    @Override
    public boolean kuehlen(int zielTemperatur) {
        if (zielTemperatur < -20) {
            return false;
        }
        temperatur = zielTemperatur;
        return true;
    }
}

class Zustellung {
    public String beschreibung() {
        return "Zustellung";
    }

    public double gebuehr() {
        return 4.00;
    }

    public String quittung() {
        return beschreibung() + ": " + gebuehr() + " EUR";
    }
}

class Expresszustellung extends Zustellung {
    @Override
    public String beschreibung() {
        return "Express";
    }

    @Override
    public double gebuehr() {
        return super.gebuehr() + 6.00;
    }

    public String zeitfenster() {
        return "bis 12 Uhr";
    }
}

class Nachtzustellung extends Expresszustellung {
    @Override
    public String beschreibung() {
        return "Nacht-" + super.beschreibung();
    }
}

class Kasse {
    public String buche(Zustellung z) {
        return "Standardbuchung";
    }

    public String buche(Expresszustellung e) {
        return "Expressbuchung";
    }
}

 1  public class Tarifkonfiguration {
 2      private Tarifkonfiguration instanz;
 3      private double grundpreisPaket;
 4      private double kgZuschlag;
 5
 6      public Tarifkonfiguration() {
 7          grundpreisPaket = ladeWert("paket.grundpreis");
 8          kgZuschlag = ladeWert("paket.kgzuschlag");
 9      }
10
11      public Tarifkonfiguration getInstanz() {
12          instanz = new Tarifkonfiguration();
13          return instanz;
14      }
15
16      public double getGrundpreisPaket() { return grundpreisPaket; }
17      public double getKgZuschlag() { return kgZuschlag; }
18
19      private double ladeWert(String schluessel) { ... }   // Rumpf nicht dargestellt
20  }

wenn k.getKanal() = "EMAIL" dann
  b := new EmailBenachrichtigung(k.getKontakt())
sonst wenn k.getKanal() = "SMS" dann
  b := new SmsBenachrichtigung(k.getKontakt())
sonst wenn k.getKanal() = "PUSH" dann
  b := new PushBenachrichtigung(k.getKontakt())
Ende wenn

C · Aufgaben

Alle Aufgaben beziehen sich auf die Ausgangssituation in Anlage 1. Methoden sind – sofern nicht anders angegeben – in Pseudocode nach den Konventionen des Belegsatzes zu entwickeln; eine Programmiersprache (z. B. Java) ist ebenfalls zulässig. Für alle Attribute stehen Get-Methoden zur Verfügung. Summe aller Aufgaben: 178 Punkte (≈ 160 Minuten).

OOP-01 · Grundkonzepte: Klasse, Objekt, Kapselung

Etikett e1 = new Etikett("Ahrens", 2.5);
Etikett e2 = new Etikett("Bode");
Etikett e3 = e1;
e3.setGewicht(4.0);
e2.setGewicht(40.0);
Etikett e4 = new Etikett("Ahrens", 4.0);
Etikett e5 = new Etikett("Cramer", 0.0);

System.out.println(e1);                    // (1)
System.out.println(e2);                    // (2)
System.out.println(e1 == e3);              // (3)
System.out.println(e1 == e4);              // (4)
System.out.println(e1.equals(e4));         // (5)
System.out.println(Etikett.getAnzahl());   // (6)

OOP-02 · Vererbung, abstrakte Klassen und Interfaces

Fahrzeug f1 = new Lastenrad("LR-07");
Fahrzeug f2 = new Kuehltransporter("KT-02", 180);

 1  public class EScooter extends Fahrzeug {
 2      public EScooter(String kennung) {
 3          reichweiteKm = 35;
 4          System.out.println("E-Scooter bereit");
 5      }
 6
 7      @Override
 8      public String info() {
 9          return "E-Scooter " + kennung;
10      }
11  }
12
13  // in einer Testklasse:
14  Fahrzeug reserve = new Fahrzeug("RES-1", 50);

OOP-03 · Polymorphie, Überladen/Überschreiben, Generics

Zustellung a = new Zustellung();
Zustellung b = new Expresszustellung();
Zustellung c = new Nachtzustellung();
Expresszustellung d = new Nachtzustellung();
Kasse k = new Kasse();

System.out.println(b.beschreibung());   // (1)
System.out.println(b.quittung());       // (2)
System.out.println(c.quittung());       // (3)
System.out.println(a.quittung());       // (4)
System.out.println(k.buche(b));         // (5)
System.out.println(k.buche(d));         // (6)

OOP-04 · Entwurfsmuster: Grundlagen, Kategorien, Erzeugungsmuster

OOP-05 · Verhaltens- und Strukturmuster

Originalaufgaben zum Üben

Diese echten Prüfungsaufgaben passen zu diesem Block (Dateien im Ordner Prüfungsvorbereitung). Lösungen gibt es nur für 2023 Sommer, 2023 Winter, 2024 Sommer und 2025 Winter (S23 und W25 vom u-form-Verlag).