Diese Seite erklärt jede einzelne Zeile des Codes: was sie macht, warum sie dort steht, was sie voraussetzt und wie sie mit dem Rest zusammenhängt. Klicke unten auf eine Codezeile, um ihre Erklärung zu öffnen.
Klicke auf eine Zeile. Die Zeile wird hervorgehoben und darunter öffnet sich eine ausführliche Erklärung.
enum Type
Speichert: die Art eines Stempels — entweder KOMMEN oder GEHEN.
Warum: Es gibt nur diese zwei Möglichkeiten. Ein Enum verhindert Tippfehler und falsche Werte.
Verwendung: Jeder TimeEntry hat ein Type. Überall mit == verglichen (z. B. Type.KOMMEN).
record TimeEntry
Speichert: einen einzelnen Stempelvorgang — die Art (type) und den Zeitpunkt (timestamp).
Warum: Ein record ist ein kurzer, unveränderlicher Datencontainer. Konstruktor und type()/timestamp() entstehen automatisch.
Verwendung: validate bekommt eine List<TimeEntry> und verarbeitet sie.
record ValidationResult
Speichert: das Ergebnis der Prüfung — eine List<String> mit allen gefundenen Fehlertexten.
Warum: Verpackt das Resultat sauber in ein Objekt, statt nur eine Liste herumzureichen. Ist die Liste leer, gab es keine Verstöße.
Verwendung: validate gibt am Ende new ValidationResult(errors) zurück.
Zugriffsmodifizierer: „von überall sichtbar". Andere Klassen dürfen es benutzen.
Nur innerhalb dieser Klasse nutzbar. Die drei Hilfsmethoden sind private.
Ein Bauplan/Container. Bündelt Daten und Methoden zu einer Einheit (hier: TimeValidator).
Eine Aufzählung: ein Typ mit fester, begrenzter Menge benannter Werte.
public = Eingang von außen (z. B. validate). private = interne Helfer, vor Außen verborgen.
Pakete ordnen Klassen in Namensräume/Ordner, vermeiden Namenskonflikte und gliedern große Projekte.
Ganz oben steht keine package …;-Zeile. Die Klasse liegt daher im „default package" (Standardpaket). In echten Projekten ist ein benanntes Package üblich.
TimeValidator ist die zentrale Klasse. Sie prüft Arbeitszeit-Stempel auf Verstöße gegen Arbeitszeitregeln (Pausen, Höchstarbeitszeit, Ruhezeit). Sie enthält das Enum Type, die Records TimeEntry und ValidationResult sowie eine öffentliche Methode validate(…) und drei private Hilfsmethoden.
Im MIS-Kontext zeigt der TimeValidator beispielhaft, wie Unternehmenssoftware fachliche Regeln wie Arbeitszeiten, Pausen und Ruhezeiten automatisiert prüfen kann — inklusive der Annahmen und möglichen Schwächen, die solche Geschäftslogik in der Praxis hat.
Die animierten Pfeile zeigen, wer wen aufruft.
…ohne das Sortieren (Zeile 15) keine Prüfung stimmt. Erst sortiert ergeben Kommen/Gehen-Paare und Abstände Sinn.
…i += 2 in calculateWorkTime & calculatePauses: gerade Indizes = Kommen-Blöcke, ungerade = Pausen.
…Validierung: eine Fehlerliste anlegen, viele Regeln prüfen, Fehler sammeln und am Ende gebündelt zurückgeben.
…records ersetzen viel Boilerplate: ein TimeEntry bekommt Konstruktor und Getter (type(), timestamp()) geschenkt.
private Methoden sind Helfer und nur intern aufrufbar — validate ist public, der Einstieg von außen.
Pausen werden pro Tag geprüft; checkRestPeriod läuft über die ganze sortierte Liste und misst den Abstand nach jedem GEHEN — unterscheidet aber nicht zwischen Pause und echter Ruhezeit.
TimeValidator nimmt eine Liste von Stempeln (TimeEntry = Kommen/Gehen + Zeitpunkt), sortiert sie, prüft auf doppelte Stempel, gruppiert nach Tag und kontrolliert pro Tag Pausen, Pausensumme und Höchstarbeitszeit. Zum Schluss prüft sie über die gesamte sortierte Liste den Abstand nach jedem Gehen auf 11 Stunden — das erkennt Ruhezeiten zwischen Arbeitstagen, kann aber ohne Tageswechsel-Prüfung auch normale Pausen fälschlich als Verstoß werten. Alle Verstöße landen in einer Fehlerliste, die als ValidationResult zurückkommt.
1 Enum, 2 Records, 1 öffentliche + 3 private Methoden.
Sammle Fehler in einer Liste, prüfe Regel für Regel.
Leere Fehlerliste = alles in Ordnung.
Klicke jede Codezeile oben an, um sie einzeln zu lernen.
by Ph4ntomic · ph4ntomic.de ↗