Python · OOP · Desktop Applications
Vier kompakte Kursprojekte dokumentieren den Weg von ersten Klassenmodellen bis zu zustandsbehafteten Desktop-Anwendungen.
Projekte erkunden →Der Lernpfad
Die Projekte entstanden im Kurskontext und konzentrieren sich bewusst auf einzelne Programmierkonzepte. Gemeinsam zeigen sie, wie aus Klassen und Funktionen schrittweise Anwendungen mit Benutzerinteraktion, Zustandsverwaltung und Dateiimport entstehen.
Statt sie als vier große Produkte darzustellen, bündelt diese Fallstudie ihre stärksten Lernmomente: Modellierung, Kontrollfluss, Persistenz und grafische Oberflächen.
Vier Etappen
01 · OBJECT-ORIENTED MODELING
Personen, Studierende, Lehrende und Workshops werden als zusammenhängendes Klassenmodell abgebildet. Vererbung reduziert Dopplungen, Rollen steuern Verhalten und JSON-Exporte machen Objekte außerhalb des Programms nutzbar.
02 · STATE & SEARCH
Ein textbasiertes Shopsystem modelliert Bestand, Kunden, Käufe, Sammlungen und Wunschlisten. Suchbegriffe werden mit Buchobjekten kombiniert; ein Menü führt durch die Anwendungsfälle.
03 · DESKTOP WORKFLOW
Das Restaurantprojekt überträgt eine Speisekarte in eine Tkinter-Oberfläche. Gerichte wandern in einen Warenkorb, Summen und Trinkgeld werden berechnet und der Bestellstatus durch einen Zahlungsablauf geführt.
04 · CRUD & FILE I/O
Die Desktop-App verwaltet Kartennummern und Bestände. Karten können hinzugefügt oder versendet, Listen angezeigt sowie Bestände über CSV exportiert und wieder importiert werden.
Kompetenzaufbau
Domänenobjekte, Eigenschaften und Beziehungen sauber benennen.
Listen, Warenkörbe und Sammlungen über Interaktionen hinweg verändern.
JSON und CSV als Grenze zwischen Anwendung und Datenbestand nutzen.
Konsolenmenüs und Tkinter-Dialoge in nachvollziehbare Abläufe übersetzen.
Einordnung
Die Anwendungen sind Lernstände und keine produktionsreifen Systeme. Genau darin liegt ihr Wert: Sie zeigen, auf welchen Grundlagen spätere Projekte wie Daisy, KuraPilot und der Material Data Hub aufbauen.
Heute würde ich Zuständigkeiten stärker trennen, automatisierte Tests ergänzen, Eingaben konsequent validieren und Abhängigkeiten reproduzierbar verwalten. Diese Lücke zwischen damaliger Lösung und heutigem Anspruch zeigt den tatsächlichen Lernfortschritt.
Was geblieben ist
Verstehen, modellieren, bauen, prüfen und neu denken: Die vier Übungen waren kleine Systeme, aber ein wichtiger Schritt zu den deutlich größeren Projekten, die danach folgten.
Architektur-Lernkurve
Die Übungen zeigen nicht nur neue Python-Syntax. Sie machen sichtbar, wie Datenmodell, Anwendungszustand, Ein-/Ausgabe und Oberfläche schrittweise als unterschiedliche Verantwortlichkeiten erkennbar wurden.
Die Coding-Schule führte Klassen, Vererbung und Beziehungen ein – Grundlage für spätere fachliche Modelle.
Buchhandlung und Wunschliste zeigten, dass Menüführung und Datenbestand über mehrere Aktionen konsistent bleiben müssen.
JSON und CSV machten Serialisierung, Validierung und die Trennung zwischen internem Objekt und Austauschformat sichtbar.
Restaurant und Sammelkartenverwaltung übersetzten Zustandswechsel in Buttons, Dialoge, Feedback und Fehlerpfade.
Daisy übernimmt die Trennung von Daten und Engine; KuraPilot entwickelt Zustands- und Persistenzfragen zu einer geschützten Domäne weiter. Die Übungen sind die nachvollziehbare Vorgeschichte der großen Systeme.