Eine Anforderung objektorientiert modellieren

Eine Freigabe braucht verlässliche Regeln

Die Nordlicht Lernsysteme GmbH verwaltet Lernmodule für mehrere Ausbildungsbetriebe. Ein Modul besteht aus Lernbausteinen wie Texten und Quizfragen. Erst wenn mindestens ein Baustein vorhanden ist, darf die Redaktion das Modul veröffentlichen. Nach der Veröffentlichung soll der Titel nicht nebenbei überschrieben werden können.

Im ersten Entwurf liegen Titel, Status und Bausteine als lose Variablen an verschiedenen Stellen. Jede Funktion kann sie verändern. Dadurch kann ein Modul den Status veroeffentlicht erhalten, obwohl es leer ist. Das fachliche Problem lautet deshalb nicht nur “Daten speichern”. Die Software soll gültige Zustände schützen und die passenden Handlungen dort bündeln, wo die Regeln gelten.

Nach dieser Lektion kannst du:

• fachliche Objekte mit Zustand und Verhalten erkennen,
• aus einem konkreten Objekt eine Klasse als gemeinsamen Bauplan ableiten,
• veränderbare Daten durch Methoden kapseln,
• ein Modul aus Bausteinen zusammensetzen,
• Vererbung auf echte fachliche Varianten begrenzen,
• dein Modell mit Normal-, Rand- und Fehlerfällen prüfen.

Du solltest Variablen, Datentypen, Bedingungen und Funktionen kennen. Die Beispiele verwenden TypeScript. Die Grundidee gilt aber auch in anderen objektorientierten Sprachen.

Suche zuerst nach Verantwortung

Ein Objekt ist eine konkrete Einheit im laufenden Programm. Es besitzt einen Zustand und kann Verhalten anbieten. Das Lernmodul “IPv4-Grundlagen” wäre ein Objekt. Sein Titel, sein Status und seine Bausteine bilden den Zustand. bausteinHinzufuegen() und veroeffentlichen() beschreiben Verhalten.

Eine Klasse legt fest, welche Daten und welches Verhalten gleichartige Objekte besitzen. Sie ist der Bauplan. Aus der Klasse Lernmodul können viele Objekte entstehen, zum Beispiel ein Modul zu IPv4 und ein anderes zu SQL. Beide folgen denselben Regeln, behalten aber ihren eigenen Zustand.

Das wichtige Signal sind Verantwortungen, nicht Substantive allein. Aus dem Wort “Redaktion” muss nicht automatisch eine Klasse werden. Eine Klasse ist dann hilfreich, wenn sie zusammengehörigen Zustand und die Regeln für diesen Zustand trägt.

Schnellcheck

Ordne Zustand und Verhalten zu

Entscheide dich bei jeder Frage. Du bekommst die Erklärung direkt nach deiner Antwort.

/2

Das Modul soll nur veröffentlicht werden, wenn es mindestens einen Baustein enthält. Wo gehört diese Regel am ehesten hin?

Das passt.

Noch nicht ganz.

Das Lernmodul besitzt den Status und die Bausteine. Wenn es die Regel selbst schützt, gilt sie auch für Aufrufe aus anderen Oberflächen oder Schnittstellen. Eine Oberfläche darf die Entscheidung anzeigen, sollte sie aber nicht allein absichern.

Nächste Frage

Welche Formulierung beschreibt ein Objekt und nicht die Klasse?

Das passt.

Noch nicht ganz.

`IPv4-Grundlagen` bezeichnet eine konkrete Instanz mit einem konkreten Zustand. Die anderen Aussagen beschreiben den gemeinsamen Bauplan aller Lernmodule.

Ergebnis ansehen

Geschafft

von 2

Situationen richtig eingeordnet.

Quiz noch einmal machen

Kapsle Zustand und schütze gültige Übergänge

Kapselung bedeutet, Zustand und die Regeln für seine Veränderung zusammenzuhalten. Andere Programmteile erhalten nur die Zugriffe, die sie wirklich brauchen. Sichtbarkeiten wie private und public machen diese Grenze im Code sichtbar.

type Modulstatus = "entwurf" | "veroeffentlicht"

class Lernmodul {
  private status: Modulstatus = "entwurf"
  private readonly bausteine: Lernbaustein[] = []

  constructor(public readonly titel: string) {}

  bausteinHinzufuegen(baustein: Lernbaustein): void {
    if (this.status === "veroeffentlicht") {
      throw new Error("Ein veröffentlichtes Modul ist gesperrt.")
    }

    this.bausteine.push(baustein)
  }

  veroeffentlichen(): void {
    if (this.bausteine.length === 0) {
      throw new Error("Ein leeres Modul kann nicht veröffentlicht werden.")
    }

    this.status = "veroeffentlicht"
  }

  statusLesen(): Modulstatus {
    return this.status
  }

  anzahlBausteine(): number {
    return this.bausteine.length
  }
}

status und bausteine sind private. Code außerhalb der Klasse kann sie nicht direkt überschreiben. Er nutzt die öffentlichen Methoden. Diese Methoden prüfen die fachlichen Bedingungen, bevor sie den Zustand ändern.

Der Titel ist public readonly. Er darf gelesen, aber nach der Erzeugung nicht verändert werden. Das ist ebenfalls eine bewusste Schnittstelle. Kapselung bedeutet nicht, jedes Attribut mit einem Getter und Setter zu versehen. Ein öffentlicher Setter für status würde die Schutzregel wieder umgehen.

Fehlersuche

Finde den gefährlichen Zugriff

Welche Zeile ermöglicht einen ungültigen Zustand, wenn `status` öffentlich wäre?

1. 1 const modul = new Lernmodul("IPv4-Grundlagen")
2. 2 modul.status = "veroeffentlicht"
3. 3 console.log(modul.statusLesen())
4. 4 console.log(modul.anzahlBausteine())

Fehler gefunden.

Diese Stelle ist nicht die Ursache.

Die direkte Zuweisung umgeht `veroeffentlichen()` und damit die Prüfung auf mindestens einen Baustein. Lesende Methoden verändern den Zustand nicht.

Noch einmal suchen

Setze das Ganze aus eigenständigen Teilen zusammen

Ein Lernmodul hat Lernbausteine. Diese Formulierung weist auf Komposition hin. Bei der Komposition wird ein Objekt aus anderen Objekten zusammengesetzt und nutzt deren Verhalten. Das Modul muss nicht selbst wissen, wie ein Text oder ein Quiz dargestellt wird. Es hält nur Bausteine, die einen gemeinsamen Vertrag erfüllen.

interface Lernbaustein {
  zusammenfassen(): string
}

class Textbaustein implements Lernbaustein {
  constructor(
    private readonly ueberschrift: string,
    private readonly absatz: string,
  ) {}

  zusammenfassen(): string {
    return `${this.ueberschrift}: ${this.absatz}`
  }
}

class Quizbaustein implements Lernbaustein {
  constructor(
    private readonly frage: string,
    private readonly antworten: string[],
  ) {}

  zusammenfassen(): string {
    return `${this.frage} (${this.antworten.length} Antworten)`
  }
}

const modul = new Lernmodul("IPv4-Grundlagen")
modul.bausteinHinzufuegen(
  new Textbaustein("Adressen im Netz", "Eine IPv4-Adresse umfasst 32 Bit."),
)
modul.bausteinHinzufuegen(
  new Quizbaustein("Welche Adresse liegt im privaten Bereich?", [
    "10.1.2.3",
    "203.0.113.9",
  ]),
)
modul.veroeffentlichen()

Das interface Lernbaustein beschreibt eine Schnittstelle: Jeder passende Baustein muss zusammenfassen() anbieten. Das Modul arbeitet nur gegen diesen Vertrag. Es ist dadurch nicht an die inneren Details von Textbaustein oder Quizbaustein gebunden.

Komposition beantwortet hier zwei Fragen:

1. Wer koordiniert die Freigabe? Das Lernmodul.
2. Wer kennt die Darstellung eines einzelnen Inhalts? Der jeweilige Lernbaustein.

Diese Aufteilung lässt sich unabhängig prüfen. Ein neuer Bausteintyp kann den Vertrag implementieren, ohne die Freigaberegel des Moduls zu verändern.

Bausteinaufgabe

Baue die Verantwortungen zusammen

Ordne die Schritte vom fachlichen Satz bis zur verwendbaren Modellgrenze.

Ziehe die Einträge an die richtige Position. Geht auch per Tastatur über den Griff.

Reihenfolge prüfen Neu versuchen

Die Reihenfolge stimmt.

Die Reihenfolge passt noch nicht.

Die fachliche Regel kommt zuerst. Aus ihr ergeben sich der betroffene Zustand und die Verantwortung. Erst danach entsteht die Methode. Fälle prüfen am Ende, ob das Modell die Regel wirklich schützt.

Nutze Vererbung nur bei echter Austauschbarkeit

Vererbung beschreibt eine Ist-ein-Beziehung. Eine Unterklasse übernimmt Merkmale einer Oberklasse und kann sie spezialisieren. Das ist nur tragfähig, wenn jedes Objekt der Unterklasse überall dort sinnvoll eingesetzt werden kann, wo die Oberklasse erwartet wird.

Für Textbaustein und Quizbaustein braucht unser Modell keine gemeinsame Oberklasse mit fertiger Logik. Der kleine Schnittstellenvertrag reicht. Eine Vererbung nur zum Einsparen von zwei Attributzeilen würde die Klassen enger verbinden, ohne eine fachliche Regel auszudrücken.

Eine abstrakte Oberklasse wäre erst begründet, wenn alle Lernbausteine wirklich denselben geschützten Zustand und dasselbe Verhalten teilen. Zum Beispiel könnte jeder Baustein eine unveränderliche Kennung besitzen und seine Freigabe nach derselben finalen Regel prüfen:

abstract class PruefbarerLernbaustein implements Lernbaustein {
  constructor(public readonly id: string) {}

  freigeben(): void {
    if (!this.istVollstaendig()) {
      throw new Error("Der Lernbaustein ist noch nicht vollständig.")
    }
  }

  protected abstract istVollstaendig(): boolean
  abstract zusammenfassen(): string
}

Konkrete Unterklassen müssten istVollstaendig() passend umsetzen. Der Aufrufer könnte trotzdem jeden PruefbarerLernbaustein über freigeben() behandeln. Dieses Verwenden unterschiedlicher konkreter Objekte über einen gemeinsamen Vertrag heißt Polymorphie.

Die Entscheidungshilfe ist knapp:

• Komposition: Ein Objekt hat oder nutzt ein anderes Objekt.
• Schnittstelle: Unterschiedliche Objekte sollen denselben Vertrag erfüllen.
• Vererbung: Eine Variante ist fachlich eine spezialisierte Form der Oberklasse und bleibt austauschbar.

Schnellcheck

Wähle die passende Beziehung

Entscheide dich bei jeder Frage. Du bekommst die Erklärung direkt nach deiner Antwort.

/3

Ein Lernmodul enthält eine sortierte Liste von Lernbausteinen. Welche Beziehung beschreibt das am besten?

Das passt.

Noch nicht ganz.

Das Modul hat Bausteine und koordiniert sie. Ein Lernmodul ist kein Lernbaustein. Deshalb trägt eine Ganzes-Teil-Beziehung besser als Vererbung.

Nächste Frage

Text- und Quizbausteine sollen beide eine Vorschau liefern, haben intern aber unterschiedliche Daten. Was ist der kleinste passende gemeinsame Vertrag?

Das passt.

Noch nicht ganz.

Ein Interface fordert nur das gemeinsame Verhalten. Die Varianten bleiben frei, ihren unterschiedlichen Zustand passend zu kapseln.

Nächste Frage

Wann wäre eine gemeinsame Oberklasse für Lernbausteine fachlich begründet?

Das passt.

Noch nicht ganz.

Vererbung soll eine stabile Ist-ein-Beziehung ausdrücken. Ähnliche Namen oder wenige doppelte Zeilen reichen dafür nicht.

Ergebnis ansehen

Geschafft

von 3

Situationen richtig eingeordnet.

Quiz noch einmal machen

Prüfe das Modell an beobachtbaren Fällen

Ein Klassendiagramm kann ordentlich aussehen und trotzdem eine Fachregel verfehlen. Prüfe deshalb konkrete Abläufe. Für das Lernmodul sind mindestens diese Fälle interessant:

Der letzte Fall prüft den Unterschied zwischen Klasse und Objekt. Beide Module stammen aus derselben Klasse. Eine Zustandsänderung an einem Objekt darf das andere Objekt nicht verändern.

const netzwerkModul = new Lernmodul("IPv4-Grundlagen")
const datenbankModul = new Lernmodul("SQL-Grundlagen")

netzwerkModul.bausteinHinzufuegen(
  new Textbaustein("Netzanteil", "Die Präfixlänge markiert den Netzanteil."),
)
netzwerkModul.veroeffentlichen()

console.log(netzwerkModul.statusLesen()) // "veroeffentlicht"
console.log(datenbankModul.statusLesen()) // "entwurf"

Transferaufgabe

Modelliere einen Lernpfad mit geschütztem Fortschritt

Nordlicht ergänzt Lernpfade. Ein Lernpfad hat einen Titel und eine geordnete Liste von Lernmodulen. Ein Modul darf nur einmal im Pfad vorkommen. Der Pfad kann erst gestartet werden, wenn mindestens zwei Module enthalten sind. Nach dem Start darf die Reihenfolge nicht mehr verändert werden. Leite Klassen oder Schnittstellen ab, ordne Zustand und Verhalten zu und skizziere die zentralen Methoden in TypeScript oder sprachnahem Pseudocode. Begründe, wo du Kapselung und Komposition einsetzt. Prüfe dein Modell mit mindestens vier Fällen.

Deine Lösung

Musterlösung vergleichen

Musterlösung: Eine Klasse Lernpfad kapselt status und eine private Liste von Lernmodul-Objekten. modulHinzufuegen(modul) prüft zuerst, ob der Pfad noch im Entwurf ist und ob die Kennung oder Objektreferenz noch nicht enthalten ist. starten() prüft module.length >= 2 und setzt erst danach den Status auf gestartet. Eine Methode moduleLesen() kann eine unveränderliche Kopie zurückgeben, statt die interne Liste freizulegen. Der Lernpfad hat Lernmodule, deshalb passt Komposition. Eine Vererbung ist für diese Anforderung nicht nötig.

Testbare Fälle sind: Ein Pfad mit einem Modul lässt sich nicht starten. Dasselbe Modul lässt sich nicht zweimal ergänzen. Zwei verschiedene Module ermöglichen den Start. Nach dem Start lehnt modulHinzufuegen() ein weiteres Modul ab und die Reihenfolge bleibt unverändert.

Das steckt auch in meiner Lösung:

Ich habe Zustand und Verhalten einer klaren Verantwortung zugeordnet. Direkte Änderungen können die Regeln des Lernpfads nicht umgehen. Ich habe die Ganzes-Teil-Beziehung zwischen Lernpfad und Modulen begründet. Ich nutze Vererbung nur, wenn eine echte Ist-ein-Beziehung besteht. Meine Fälle prüfen Mindestanzahl, Duplikat, Änderung nach Start und einen gültigen Ablauf.

Was du aus dem Modell mitnehmen kannst

Objektorientierte Modellierung beginnt bei einer fachlichen Verantwortung. Du suchst nicht möglichst viele Klassen, sondern eine nachvollziehbare Grenze für Zustand und Verhalten:

1. Beschreibe die fachliche Regel und einen konkreten Ablauf.
2. Bestimme, welcher Zustand von der Regel betroffen ist.
3. Ordne Zustand und Verhalten einem verantwortlichen Objekt zu.
4. Schütze gültige Änderungen mit einer kleinen öffentlichen Schnittstelle.
5. Setze größere Objekte aus eigenständigen Teilen zusammen.
6. Nutze Vererbung nur für stabile, austauschbare Varianten.
7. Prüfe das Modell mit Normal-, Rand- und Fehlerfällen.

Damit entsteht kein automatisch perfektes Design. Das Modell wird aber begründbar: Jede Klasse und jede Beziehung beantwortet eine fachliche Frage.

Quellenbasis und Abgrenzung

Der KMK-Rahmenlehrplan ordnet das Modellieren und Realisieren von Anwendungsfunktionalität in Lernfeld 11a ein. Die Fachinformatikerausbildungsverordnung verankert für die Fachrichtung Anwendungsentwicklung das Konzipieren und Umsetzen kundenspezifischer Softwareanwendungen sowie im Prüfungsbereich “Entwicklung und Umsetzung von Algorithmen” das Umsetzen von Programmlogik und Prüfen von Anwendungen.

Der FIAE-Prüfungskatalog 2026 konkretisiert die Themenbreite mit objektorientierten Analyse- und Designverfahren, Klassen, Objekten, Schnittstellen, Kapselung, Vererbung und Polymorphie. Eine historische Beispielprüfung wurde nur auf die wiederkehrenden Aufgabenformen untersucht: Klassen und Beziehungen aus einer Anforderung ableiten und eine Beziehungsart begründen. Unternehmen, Lernplattform-Szenario, Code, Aufgaben und Lösungen dieser Lektion sind neu erstellt.

Diese Lektion behandelt das fachliche Verteilen von Zustand und Verhalten. Sie ist keine Einführung in Variablen, Bedingungen, Funktionen oder TypeScript-Syntax. UML-Klassendiagramme, Multiplizitäten und Notationsregeln gehören in eine eigene Lektion. Entwurfsmuster, SOLID-Prinzipien, Persistenz, Nebenläufigkeit und vollständige automatisierte Tests werden ebenfalls nicht vertieft. Die Inhalte sagen keine Aufgabe eines konkreten Prüfungstermins voraus.

Belegmatrix