Objektorientiert programmieren

Im ersten Lehrjahr hast du gelernt, dass Code funktioniert. Jetzt geht es darum, dass er auch verständlich, erweiterbar und testbar bleibt. Du zerlegst eine Aufgabe in Klassen mit klaren Verantwortlichkeiten, verbindest sie über Beziehungen und Interfaces und prüfst mit Unit-Tests, dass alles korrekt läuft. Am Ende kannst du eine kleine Anwendung mit mehreren fachlichen Klassen sauber entwerfen, umsetzen und dokumentieren.

Das sind die Fähigkeiten, die am Ende des Moduls sitzen sollten. Jedes Ziel mit einem Beispiel aus dem Lehrbetrieb.

1. 1

   Aus einer Aufgabenstellung passende Klassen ableiten

   Kompetenz A

   Du liest eine Anforderung und erkennst, welche 'Dinge' darin vorkommen (z.B. Kunde, Bestellung, Artikel), welche Daten sie haben und was sie tun. Daraus entstehen Klassen mit klaren Zuständigkeiten statt einer grossen Sammelklasse.

   Situation

   Der Lehrbetrieb möchte ein kleines Tool, mit dem Mitarbeitende Laptops ausleihen und zurückgeben können.

   Deine Aufgabe

   Bestimme die fachlichen Klassen und ihre wichtigsten Attribute und Methoden.

   Gutes Ergebnis

   Klassen 'Geraet', 'Mitarbeiter' und 'Ausleihe'. Eine Ausleihe kennt Gerät, Person, Start- und Rückgabedatum und kann prüfen, ob sie überfällig ist.

   KlasseObjektAttributMethodeVerantwortlichkeit (SRP)Domänenmodell
2. 2

   Daten schützen und nur über Methoden verändern lassen

   Kompetenz B

   Attribute sind privat, Änderungen laufen über Methoden, die Regeln durchsetzen. So kann niemand ein Objekt in einen ungültigen Zustand bringen, z.B. einen negativen Lagerbestand.

   Situation

   In einer Lagerverwaltung wird der Bestand direkt überschrieben und ist plötzlich negativ.

   Deine Aufgabe

   Baue die Klasse 'Artikel' so um, dass der Bestand nur über 'einlagern()' und 'auslagern()' änderbar ist.

   Gutes Ergebnis

   'bestand' ist private, 'auslagern(menge)' wirft einen Fehler, wenn zu wenig vorhanden ist. Ein Getter liefert den aktuellen Wert.

   private / publicGetter / SetterInvarianteKonstruktor
3. 3

   Beziehungen, Vererbung und Interfaces gezielt einsetzen

   Kompetenz C

   Du entscheidest, ob Klassen einander kennen (Assoziation), ob eine Klasse eine Spezialisierung einer anderen ist (Vererbung) oder ob mehrere Klassen nur dasselbe können müssen (Interface). Und du weisst, wann Vererbung die falsche Wahl ist.

   Situation

   Ein Shop verkauft physische Produkte, die versendet werden, und digitale Produkte, die man herunterlädt.

   Deine Aufgabe

   Modelliere, wie beide Produktarten ihren Versand bzw. ihre Auslieferung berechnen.

   Gutes Ergebnis

   Ein Interface 'Lieferbar' mit 'liefern()', implementiert von 'PhysischesProdukt' (Paket) und 'DigitalesProdukt' (Download-Link). Der Warenkorb arbeitet nur mit 'Lieferbar'.

   AssoziationKompositionVererbungabstrakte KlasseInterfacePolymorphie
4. 4

   Den Entwurf mit UML skizzieren und den Code dokumentieren

   Kompetenz A, E

   Bevor du programmierst, hältst du den Entwurf in einem Klassendiagramm fest. Für Abläufe nutzt du ein Sequenzdiagramm. Im Code beschreibst du öffentliche Methoden mit Doc-Kommentaren, sodass andere sie verstehen, ohne den Code zu lesen.

   Situation

   Dein Berufsbildner will vor der Umsetzung sehen, wie du das Ausleih-Tool aufbauen möchtest.

   Deine Aufgabe

   Erstelle ein Klassendiagramm mit Klassen, Attributen, Methoden und Beziehungen inkl. Multiplizitäten.

   Gutes Ergebnis

   Ein Diagramm, in dem man sieht: ein Mitarbeiter hat 0..* Ausleihen, eine Ausleihe gehört genau zu einem Gerät. Dazu Javadoc/XML-Doc für alle öffentlichen Methoden.

   KlassendiagrammSequenzdiagrammMultiplizitätJavadoc / XML-Doc
5. 5

   Polymorphie nutzen, um if-else-Ketten zu vermeiden

   Kompetenz D

   Statt mit vielen Abfragen zu prüfen, um welchen Typ es sich handelt, rufst du dieselbe Methode auf und jede Klasse reagiert auf ihre Art. Neue Varianten kommen dazu, ohne bestehenden Code anzupassen.

   Situation

   Eine Lohnberechnung enthält eine riesige switch-Anweisung für Festangestellte, Stundenlöhner und Lernende.

   Deine Aufgabe

   Refaktoriere die Berechnung, sodass jeder Mitarbeitertyp seinen Lohn selbst berechnet.

   Gutes Ergebnis

   Abstrakte Klasse 'Mitarbeiter' mit 'berechneLohn()'. Drei Unterklassen überschreiben die Methode, und die Lohnliste ruft nur noch 'm.berechneLohn()' auf.

   Überschreiben (override)dynamische BindungOpen-Closed-PrinzipRefactoring
6. 6

   Klassen mit Unit-Tests auf Korrektheit prüfen

   Kompetenz E

   Du schreibst automatisierte Tests für die wichtigsten Methoden, inklusive Grenzfälle. So merkst du sofort, wenn eine Änderung etwas kaputt macht.

   Situation

   Die Methode 'istUeberfaellig()' der Ausleihe liefert manchmal falsche Ergebnisse.

   Deine Aufgabe

   Schreibe Tests für: Rückgabe heute fällig, gestern fällig, bereits zurückgegeben.

   Gutes Ergebnis

   Drei JUnit-/xUnit-Tests nach dem Muster Arrange-Act-Assert. Ein Test schlägt fehl und zeigt den Fehler beim Datumsvergleich.

   Unit-TestArrange-Act-AssertGrenzfallTestabdeckung

Die Kompetenzmatrix zerlegt das Modul in Themenstränge und drei Stufen. Für den Kompetenznachweis solltest du überall mindestens Stufe 2 erreichen. Dein Stand bleibt in diesem Browser gespeichert und färbt Lernweg und Übungen ein.

Mia ist im 2. Lehrjahr bei der Treuhand Brunner AG in Aarau, 40 Mitarbeitende. Laptops werden bisher über eine Excel-Liste ausgeliehen, und ständig weiss niemand, wo ein Gerät ist. Ihr Berufsbildner gibt ihr den Auftrag, ein kleines Ausleih-Tool in Java zu bauen.

1. Kapitel 1

   Wer macht hier eigentlich was?

   Mia spricht 20 Minuten mit der Office-Managerin und notiert jedes Nomen, das fällt: Laptop, Mitarbeiterin, Ausleihe, Rückgabe, Frist. Daraus streicht sie Doppeltes und landet bei drei Klassen: Geraet, Mitarbeiter und Ausleihe. Für jede schreibt sie auf, was sie weiss und was sie kann.

   Ziel 1

2. Kapitel 2

   Der Plan auf einer Seite

   Bevor sie programmiert, zeichnet Mia ein Klassendiagramm. Im Review fragt ihr Berufsbildner, ob eine Mitarbeiterin mehrere Geräte gleichzeitig haben darf. Mia ergänzt die Multiplizität 0..* und merkt, dass sie diese Regel sonst erst im Code entdeckt hätte.

   Ziel 4

3. Kapitel 3

   Kein Laptop doppelt verliehen

   Im ersten Test verleiht ein Kollege denselben Laptop zweimal. Mia macht den Status im Geraet privat und lässt Ausleihen nur noch über eine Methode zu, die prüft, ob das Gerät frei ist. Ein doppeltes Ausleihen löst jetzt eine klare Fehlermeldung aus.

   Ziel 2

4. Kapitel 4

   Monitore und Beamer kommen dazu

   Die Geschäftsleitung ist begeistert und will auch Monitore und Beamer verleihen. Beamer dürfen nur 3 Tage weg sein, Laptops 30. Statt überall if-Abfragen einzubauen, führt Mia eine abstrakte Klasse Geraet mit der Methode ausleihfrist() ein. Jede Geräteart liefert ihre eigene Frist.

   Ziel 3Ziel 5

5. Kapitel 5

   Der Fehler mit dem Rückgabedatum

   Ein Laptop wird als überfällig gemeldet, obwohl er am Fälligkeitstag zurückkam. Mia schreibt drei Unit-Tests für fällig gestern, heute und morgen. Der Test für heute schlägt fehl: Sie hatte Datum und Uhrzeit verglichen. Nach der Korrektur laufen alle Tests grün, und sie ergänzt die Doc-Kommentare für die Übergabe.

   Ziel 6

1. 1

   Denken in Objekten

   ca. 3 Std.

   Bevor du Code schreibst, übst du, die Welt in Objekte zu zerlegen. Das ist der wichtigste und am meisten unterschätzte Schritt.

   • Drei Alltagssysteme (Bibliothek, Kino, Kantine) auf Papier in Klassen zerlegen
   • Für jede Klasse notieren: Was weiss sie? Was kann sie?
   • Mit CRC-Karten (Klasse, Verantwortung, Partner) einen Ablauf durchspielen

   Trainiert Kompetenz A1

   Lernziel1

2. 2

   Erste Klassen sauber bauen

   ca. 4 Std.

   Du setzt einzelne Klassen mit Konstruktor, privaten Attributen und Methoden um und lernst, Regeln im Objekt durchzusetzen.

   • Klasse 'Bankkonto' mit einzahlen/abheben und Überzugsschutz programmieren
   • Mehrere Objekte erzeugen und im Debugger ihren Zustand beobachten
   • toString(), equals() und hashCode() bewusst überschreiben

   Trainiert Kompetenz B1B2

   Lernziel2

3. 3

   Klassen verbinden

   ca. 5 Std.

   Jetzt arbeiten mehrere Klassen zusammen. Du übst Assoziationen, Listen von Objekten und den Unterschied zwischen Vererbung und Interface.

   • Ein Mini-Modell 'Kunde, Bestellung, Artikel' mit Listen umsetzen
   • Dieselbe Aufgabe einmal mit Vererbung und einmal mit Interface lösen und vergleichen
   • Ein Klassendiagramm zum eigenen Code zeichnen

   Trainiert Kompetenz C1C2A2

   Lernziel34

4. 4

   Polymorphie und Refactoring

   ca. 5 Std.

   Du nimmst bestehenden 'Spaghetti-Code' und baust ihn schrittweise objektorientiert um, ohne dass sich das Verhalten ändert.

   • switch-Anweisung durch polymorphe Methoden ersetzen
   • Lange Methoden in kleinere mit sprechenden Namen aufteilen
   • Code-Review mit einer Kollegin oder einem Tutor durchführen

   Trainiert Kompetenz D2D3C3

   Lernziel5

5. 5

   Absichern mit Tests

   ca. 4 Std.

   Du schreibst Unit-Tests für deine Klassen und lernst, Grenzfälle systematisch zu finden.

   • Für jede öffentliche Methode mindestens einen positiven und einen negativen Test schreiben
   • Absichtlich einen Fehler einbauen und prüfen, ob ein Test ihn findet
   • Testabdeckung in der IDE anzeigen lassen und Lücken schliessen

   Trainiert Kompetenz E1E2

   Lernziel6

6. 6

   Alles zusammen: Mini-Projekt

   ca. 4 Std.

   Du entwirfst und baust eine kleine Anwendung mit 3 bis 5 fachlichen Klassen von A bis Z, wie im Kompetenznachweis.

   • Anforderung lesen, Klassendiagramm skizzieren, umsetzen, testen, dokumentieren
   • Zeit stoppen und mit der erwarteten Prüfungsdauer vergleichen
   • Ergebnis jemandem in 5 Minuten erklären

   Trainiert Kompetenz A2B3E3

   Lernziel1346

Klasse

Bauplan, der festlegt, welche Daten (Attribute) und Fähigkeiten (Methoden) Objekte haben.

Objekt

Konkretes Exemplar einer Klasse mit eigenen Werten.

Kapselung

Interne Daten verstecken und nur über definierte Methoden zugänglich machen.

Vererbung

Eine Klasse übernimmt Eigenschaften und Verhalten einer allgemeineren Klasse und spezialisiert sie.

Interface

Vertrag, der festlegt, welche Methoden eine Klasse anbieten muss, ohne die Umsetzung vorzugeben.

Polymorphie

Gleicher Aufruf, unterschiedliches Verhalten je nach Objekttyp.

Single Responsibility Principle

Jede Klasse sollte genau einen Grund haben, sich zu ändern.

Unit-Test

Automatisierter Test, der eine kleine Einheit (meist eine Methode) isoliert prüft.

Passende Module