Informatik · Klasse 10 · Objektorientierte Modellierung und Programmierung · 1. Halbjahr

Vererbung: Hierarchien bilden

Die Schülerinnen und Schüler wenden das Prinzip der Vererbung an, um Klassenhierarchien zu erstellen und Code-Duplizierung zu vermeiden.

• KMK Bildungsstandards
• KMK: STD.01
• KMK: STD.03

Über dieses Thema

In diesem Thema lernen Schülerinnen und Schüler, wie Vererbung in der objektorientierten Programmierung Klassenhierarchien schafft und Code-Duplizierung vermeidet. Eine 'ist-ein'-Beziehung ist architektonisch sinnvoll, wenn eine Unterklasse alle Eigenschaften und Verhaltensweisen einer Oberklasse erbt, wie bei Fahrzeugen, wo ein Auto ein Fahrzeug ist. Gemeinsame Merkmale wie Farbe oder Geschwindigkeit werden in der Oberklasse gebündelt, was den Code wartbarer macht.

Zu tiefe Hierarchien bergen Risiken wie Komplexität und starre Strukturen, die Erweiterungen erschweren. Schüler analysieren, wann Vererbung passt und üben, Hierarchien zu modellieren und zu implementieren. Dies stärkt das Verständnis für saubere Softwarearchitektur gemäß KMK-Standards STD.01 und STD.03.

Aktives Lernen fördert hier das tiefe Begreifen, da Schüler selbst Hierarchien bauen und testen, was abstrakte Konzepte greifbar macht und langfristig bessere Programmierfähigkeiten schafft.

Leitfragen

1. Wann ist eine 'ist-ein'-Beziehung zwischen Klassen architektonisch sinnvoll?
2. Wie können wir gemeinsame Eigenschaften und Verhaltensweisen in einer Oberklasse zusammenfassen?
3. Welche Risiken entstehen durch zu tiefe Vererbungshierarchien?

Lernziele

• Klassifizieren Sie verschiedene Objekte als Instanzen einer Oberklasse basierend auf gemeinsamen Merkmalen und Verhaltensweisen.
• Analysieren Sie bestehenden Code, um redundante Abschnitte zu identifizieren, die durch Vererbung refaktorisiert werden können.
• Entwerfen Sie eine einfache Klassenhierarchie für eine gegebene Problemstellung unter Anwendung des Vererbungsprinzips.
• Erklären Sie die 'ist-ein'-Beziehung und ihre Bedeutung für die Erstellung von Klassenhierarchien.
• Bewerten Sie die Angemessenheit der Vererbung für eine spezifische Modellierungssituation und begründen Sie Ihre Wahl.

Bevor es losgeht

Grundlagen der Objektorientierten Programmierung

Warum: Schüler müssen die Konzepte von Klassen, Objekten, Attributen und Methoden verstehen, bevor sie Vererbung anwenden können.

Methoden und Funktionen

Warum: Das Verständnis, wie Methoden aufgerufen und verwendet werden, ist essenziell, um zu verstehen, wie Unterklassen Methoden der Oberklasse nutzen oder überschreiben.

Schlüsselvokabular

Vererbung	Ein Mechanismus in der objektorientierten Programmierung, bei dem eine Klasse (Unterklasse) Eigenschaften und Methoden von einer anderen Klasse (Oberklasse) übernimmt.
Oberklasse (Superklasse)	Die Klasse, von der andere Klassen Eigenschaften erben. Sie enthält gemeinsame Merkmale und Verhaltensweisen.
Unterklasse (Subklasse)	Die Klasse, die Eigenschaften und Methoden von einer Oberklasse erbt. Sie kann eigene, spezifische Merkmale hinzufügen oder bestehende überschreiben.
'ist-ein'-Beziehung	Eine konzeptionelle Beziehung, bei der eine Unterklasse eine spezialisierte Form der Oberklasse darstellt (z.B. ein 'Auto' ist ein 'Fahrzeug').
Code-Duplizierung	Das mehrfache Vorkommen desselben oder sehr ähnlichen Codes an verschiedenen Stellen, was durch Vererbung vermieden werden kann.

Vorsicht vor diesen Fehlvorstellungen

Häufige Fehlvorstellung

Vererbung ist immer besser als Komposition.

Was Sie stattdessen lehren sollten

Vererbung eignet sich nur für 'ist-ein'-Beziehungen; Komposition für 'hat-ein' flexibler und vermeidet tiefe Hierarchien.

Häufige Fehlvorstellung

Alle Klassen brauchen eine Oberklasse.

Was Sie stattdessen lehren sollten

Nicht jede Klasse erbt; flache Strukturen sind oft wartbarer und erweiterbarer.

Häufige Fehlvorstellung

Tiefe Hierarchien machen Code mächtiger.

Was Sie stattdessen lehren sollten

Tiefe Hierarchien erhöhen Komplexität und Kopplung, was Wartung erschwert.

Ideen für aktives Lernen

Paararbeit: Tierhierarchie modellieren

Schüler zeichnen ein UML-Diagramm für eine Tier-Oberklasse mit Unterklassen wie Hund und Vogel. Sie implementieren gemeinsame Methoden wie 'bewegen()'. Paare testen den Code mit Instanzen.

30 Min.·Partnerarbeit

Kleingruppen: Auto-Familie erweitern

Gruppen erweitern eine Fahrzeugklasse um Elektroauto und Lkw. Sie extrahieren gemeinsame Attribute und diskutieren 'ist-ein'-Beziehungen. Code wird refaktoriert, um Duplikate zu entfernen.

40 Min.·Kleingruppen

Individuell: Hierarchie-Tiefe prüfen

Jeder Schüler erstellt eine tiefe Hierarchie und analysiert Risiken. Sie refactoren zu flacheren Strukturen und dokumentieren Verbesserungen.

20 Min.·Einzelarbeit

Ganzer Unterricht: Code-Review

Klassen teilen Hierarchien und bewerten gegenseitig auf Sinnhaftigkeit und Duplizierung. Gemeinsam optimieren.

25 Min.·Ganze Klasse

Bezüge zur Lebenswelt

• In der Spieleentwicklung nutzen Programmierer Vererbung, um verschiedene Charaktertypen (z.B. Krieger, Magier) von einer gemeinsamen 'Charakter'-Oberklasse abzuleiten. Dies erlaubt es, grundlegende Eigenschaften wie Lebenspunkte oder Bewegung für alle Charaktere zentral zu definieren.
• Automobilhersteller wie Volkswagen verwenden Klassenhierarchien in ihrer Software. Ein 'Golf' und ein 'Passat' könnten beide von einer 'Fahrzeug'-Klasse erben, die gemeinsame Attribute wie 'Motor' oder 'Getriebe' definiert, während spezifische Modelle eigene Besonderheiten hinzufügen.

Ideen zur Lernstandserhebung

Lernstandskontrolle

Geben Sie den Schülerinnen und Schülern eine Liste von Begriffspaaren (z.B. 'Hund' und 'Tier', 'Rechteck' und 'Kreis'). Sie sollen für jedes Paar entscheiden, ob eine 'ist-ein'-Beziehung und damit Vererbung sinnvoll ist, und ihre Entscheidung kurz begründen.

Kurze Überprüfung

Zeigen Sie ein einfaches Klassendiagramm mit einer Ober- und zwei Unterklassen (z.B. 'Mitarbeiter' als Oberklasse, 'Angestellter' und 'Azubi' als Unterklassen). Fragen Sie die Schüler: Welche Attribute und Methoden könnten in der Oberklasse 'Mitarbeiter' definiert sein? Welche spezifischen Merkmale könnten die Unterklassen haben?

Diskussionsfrage

Stellen Sie die Frage: 'Wann könnte es problematisch werden, wenn wir sehr viele Vererbungsebenen (eine tiefe Hierarchie) in unserem Programm haben?' Leiten Sie eine Diskussion über mögliche Nachteile wie Komplexität oder Abhängigkeiten.

Häufig gestellte Fragen

Wann ist eine 'ist-ein'-Beziehung sinnvoll?

Eine 'ist-ein'-Beziehung passt, wenn die Unterklasse alle Merkmale der Oberklasse teilt und erweitert, z. B. ein Sportwagen ist ein Auto. Sie vermeidet Duplizierung und fördert Wiederverwendung. Schüler prüfen dies durch Modellierung, um Fehlentscheidungen zu vermeiden. Dies entspricht KMK STD.01 und stärkt Architekturdenken. (62 Wörter)

Warum aktives Lernen bei Vererbung?

Aktives Lernen lässt Schüler Hierarchien selbst bauen, testen und refactoren, was abstrakte Konzepte konkretisiert. Sie entdecken Risiken wie tiefe Strukturen durch Trial-and-Error und peer review. Das verbessert Retention und Problemlösungsfähigkeiten nachhaltig, im Gegensatz zu passivem Vortrag. KMK STD.03 wird so praxisnah umgesetzt. (68 Wörter)

Wie fasst man gemeinsame Eigenschaften zusammen?

Gemeinsame Attribute und Methoden wandern in die Oberklasse, z. B. 'farbe' und 'fahren()' bei Fahrzeugen. Unterklassen überschreiben bei Bedarf. Dies reduziert Code und erhöht Konsistenz. Schüler üben mit Diagrammen vor dem Codieren. (54 Wörter)

Welche Risiken hat tiefe Vererbung?

Tiefe Hierarchien koppeln Klassen stark, erschweren Änderungen und Erweiterungen. Fragilitäse Base Class Problem tritt auf, wenn Oberklassen geändert werden. Flache Designs mit Komposition sind oft stabiler. Schüler lernen, Hierarchien auf zwei bis drei Ebenen zu beschränken. (59 Wörter)