Situationsaufgabe: OOP-Implementierung
OOP-Aufgaben im AP Teil 2 FIAE sind kein Test im Auswendiglernen von Syntax – sie testen, ob du objektorientiertes Denken auf einen konkreten Anwendungsfall anwenden kannst. Das bedeutet: Klassen sauber modellieren, Vererbungshierarchien ableiten, Interfaces definieren und Code schreiben, der die Anforderungen des Szenarios erfüllt. Diese Lektion führt dich durch eine vollständige OOP-Situationsaufgabe mit Klassendiagramm, Implementierung und Design-Pattern-Begründung.
1) Das Szenario
Betrieb: Die FuhrPark GmbH verwaltet einen Fuhrpark mit verschiedenen Fahrzeugtypen. Du wirst beauftragt, eine objektorientierte Klassen-Struktur zu entwerfen und zu implementieren.
Anforderungen:
- Es gibt verschiedene Fahrzeugtypen: PKW und LKW
- Alle Fahrzeuge haben: Kennzeichen, Baujahr, Kilometerstand und eine Methode
getInfo() - PKW hat zusätzlich: Anzahl Sitzplätze
- LKW hat zusätzlich: maximale Nutzlast (in kg)
- Alle Fahrzeuge können gewartet werden – die Wartung wird protokolliert (Datum, Beschreibung, Kosten)
- Die Klasse
Fuhrparkverwaltet eine Liste aller Fahrzeuge und kann alle Fahrzeuge ausgeben sowie das teuerste Fahrzeug nach Gesamtwartungskosten finden - Fahrzeuge sollen vergleichbar sein (nach Kilometerstand sortierbar)
2) Teilaufgaben mit Musterlösungen
3) OOP-Grundprinzipien – Prüfungsreferenz
| Prinzip | Erklärung | Prüfungs-Tipp |
|---|---|---|
| Kapselung | Attribute private, Zugriff nur über Getter/Setter. Implementierungsdetails verstecken. | In Prüfungscode immer private für Attribute, public für Methoden. Getter/Setter explizit schreiben. |
| Vererbung | Kindklasse erbt Attribute und Methoden der Elternklasse. extends (Java/Kotlin) bzw. : (C#). | Abstrakte Oberklasse wenn kein direktes Objekt der Oberklasse sinnvoll. abstract class Fahrzeug. |
| Polymorphismus | Methode wird überschrieben, Verhalten ändert sich je nach Typ. @Override. | Immer @Override (Java) annotieren – zeigt dem Prüfer, dass du Polymorphismus bewusst einsetze. |
| Abstraktion | Interfaces und abstrakte Klassen definieren „Was", nicht „Wie". | Interface für „kann-Beziehungen" (Fahrzeug kann gewartet werden → implements Wartbar). Abstrakte Klasse für „ist-ein"-Hierarchien. |
4) Design Patterns – die häufigsten in der Prüfung
Klick ein Pattern für Details und Prüfungs-Beispiel:
Singleton
Genau eine Instanz
Factory Method
Objekterstellung kapseln
Observer
Event-basierte Benachrichtigung
Strategy
Algorithmus austauschbar
Decorator
Funktionalität erweitern
MVC
Architektur-Pattern
5) Typische Fehler in OOP-Aufgaben
- Alles in eine Klasse. Gott-Klasse mit 20 Methoden – kein OOP. Eine Klasse = eine Verantwortlichkeit (Single Responsibility Principle).
- Public Attribute. In der Prüfung immer
privatefür Felder. Public-Attribute zeigen, dass das Kapselungsprinzip nicht verstanden ist. - Vererbung statt Komposition. Nicht alles ist eine Vererbungsbeziehung. „Ein PKW hat Wartungseinträge" (Komposition) ≠ „ein PKW ist ein Wartungseintrag".
- Interface und abstrakte Klasse verwechseln. Interface: keine Implementierung (nur Signaturen), für Querschnittsverhalten. Abstrakte Klasse: kann Implementierung enthalten, für Hierarchien.
- Konstruktor vergessen. Immer Konstruktor mit Pflichtparametern angeben – zeigt, welche Attribute bei der Objekterstellung gesetzt werden.
Zusammenfassung
OOP-Situationsaufgaben testen immer: (1) Klassendiagramm mit korrekter Vererbung, Interfaces, Attributen und Methoden, (2) Implementierung mit Kapselung, @Override und Konstruktoren, (3) Design-Pattern-Wahl mit Begründung, (4) Erweiterbarkeit durch Interfaces und Polymorphismus. Schlüsselprinzipien: Single Responsibility, Kapselung (private Felder), und klare is-a vs. has-a Unterscheidung.
Verwandte Lektionen: Situationsaufgabe Datenbank · Situationsaufgabe Architektur · Situationsaufgabe Testkonzept · und mehrWeitere relevante LektionenKlassen und ObjekteVererbungDesign Patterns