Projekt aufsetzen

Projekt aufsetzen

0:00 Die meisten von uns haben Java gelernt, indem sie einzelne Klassen geschrieben haben. Eine Datei, eine Main-Methode, auf Ausführen klicken, fertig. Und dann kommt der erste Arbeitstag in einem echten Projekt, und da sieht plötzlich alles anders aus: mehrere Verzeichnisse, eine Datei namens pom Punkt xml, Abhängigkeiten, ein Build-Server.

0:20 In diesem Seminar bauen wir genau so ein Projekt — von der leeren Oberfläche bis zur ausgelieferten Anwendung. In diesem ersten Modul geht es um das Fundament. Und ja, das ist der unspektakulärste Teil. Aber er entscheidet darüber, ob das, was danach kommt, trägt.

Projekt aufsetzen

0:37 Wir gehen sieben Stationen durch. Zuerst schauen wir uns an, was wir überhaupt bauen — es gibt einen roten Faden, der durch alle fünf Module trägt. Dann klären wir die Werkzeuge, setzen das Projekt mit Maven auf, schreiben die erste Klasse und bauen sie einmal ohne Entwicklungsumgebung. Danach kommen Kommandozeilenargumente, die erste externe Bibliothek und zum Schluss eine ordentliche Protokollierung.

1:00 Klingt nach viel Vorbereitung für wenig Code — und genau das ist es auch. Nur ist diese Vorbereitung der Unterschied zwischen einer Übung und einem Projekt. Vier Dinge nehmen Sie aus diesem Modul mit. Erstens ein Gefühl dafür, was ein gebautes Projekt von einer Sammlung von Klassen unterscheidet. Zweitens Maven als Werkzeug, das das Bauen von der Entwicklungsumgebung ablöst — und zwar bewusst, nicht nebenbei.

1:24 Drittens eine Anwendung, die auch dort baut, wo niemand eine IDE geöffnet hat; das klingt banal, wird aber spätestens beim ersten automatisierten Build wichtig. Und viertens eine Haltung zu externen Bibliotheken: Man bindet sie ein, weil man sie braucht, und man weiß dann auch, was man sich damit ins Haus geholt hat.

Was wir bauen — das Projekt Kursradar

1:43 Bevor wir eine einzige Zeile schreiben, sollten wir wissen, wohin die Reise geht. Ein Projekt ohne Ziel wird beliebig, und dann diskutiert man über Technik statt über Nutzen. Schauen wir uns also an, was am Ende dieses Seminars stehen soll — und warum wir es uns ausgerechnet so zuschneiden. Denn die Aufteilung, die wir gleich sehen, bestimmt für die nächsten vier Module, wo welcher Code hingehört.

2:06 Stellen Sie sich ein Entwicklerteam vor, das ständig Weiterbildungsangebote hin- und herschickt: Links in Chatnachrichten, Empfehlungen im Vorbeigehen, irgendwann findet niemand mehr etwas wieder. Kursradar räumt das auf. Ein kleines Kommandozeilenwerkzeug holt sich Kurse aus einer externen Schnittstelle und legt sie in einer Datenbank ab.

2:25 Ein zweiter Dienst gibt sie wieder heraus und nimmt Notizen entgegen — damit jemand hinschreiben kann, dass Kapitel drei sich lohnt und der Rest nicht. Das ist bewusst klein gehalten. Klein genug, um es in fünf Modulen wirklich zu Ende zu bauen, und groß genug, dass echte Fragen auftauchen. Wichtig an dieser Aufteilung ist weniger, was in welcher Zeile steht, sondern dass es überhaupt drei Teile sind. Eine Anwendung, die Daten holt.

2:51 Ein Stück, das mit der Datenbank spricht. Und ein Dienst, der die Daten wieder herausgibt. In Modul drei werden wir diese Trennung auch technisch ziehen, mit eigenen Maven-Modulen. Warum nicht gleich? Weil man Grenzen erst sinnvoll ziehen kann, wenn man weiß, was auf welcher Seite liegt. Wir fangen deshalb mit einem Teil an — dem Kommandozeilenwerkzeug — und schneiden das Projekt später bewusst neu.

3:16 Jetzt kommt die Frage, die im Java-Umfeld sofort aufkommt: Warum nicht Spring, warum nicht Quarkus? Die Antwort ist keine Ablehnung. Diese Rahmenwerke sind gut, und Sie werden in Ihrem Berufsleben fast sicher mit einem davon arbeiten. Aber sie nehmen Ihnen Entscheidungen ab, die Sie noch gar nicht kennen. Wer nie selbst ein Objekt an ein anderes übergeben hat, für den bleibt Dependency Injection Magie.

3:39 Wir bauen deshalb den unbequemen Weg — nicht aus Prinzipientreue, sondern damit Sie später sehen, was ein Rahmenwerk eigentlich für Sie erledigt. Danach ist es Werkzeug statt Zauberei. Die Fallstricke hier sind keine technischen, sondern gedankliche. Der häufigste: Man lernt ein Rahmenwerk, bevor man das Problem kennt, das es löst — und kann dann Konfiguration abschreiben, aber nicht beurteilen.

4:03 Der zweite: Man denkt die Anwendung als eine große Klasse, in die alles hineinwandert, weil es gerade passt. Der dritte betrifft die Erwartung an dieses Seminar: Versionsverwaltung, Container, Betrieb — das sind eigene Themen, und wir streifen sie höchstens. Und der vierte: Der Abruf aus der externen Schnittstelle sieht nach der Hauptsache aus. Ist er nicht. Die Hauptsache ist, wie die Teile zusammenspielen.

Werkzeuge und Versionen

4:29 Kommen wir zum Handwerkszeug. Nichts davon ist überraschend, aber es lohnt sich, kurz sauber zu klären, was Sie installiert haben sollten. Diese fünf Minuten ersparen erfahrungsgemäß eine halbe Stunde später — nämlich die, in der jemand einen Fehler im Code sucht, der in Wahrheit ein Pfadproblem ist. Und diese Verwechslung passiert öfter, als man denkt.

4:50 Drei Dinge brauchen Sie: ein Java-Entwicklungskit in Version fünfundzwanzig, eine Entwicklungsumgebung und Maven. Die Bilder, die Sie in diesem Seminar sehen, stammen aus IntelliJ IDEA — aber nichts davon hängt daran. Wer mit Eclipse oder Visual Studio Code arbeitet, kommt genauso ans Ziel, nur sehen die Dialoge anders aus. Wichtiger als die Entwicklungsumgebung ist der Java-Stand.

5:13 Wir nutzen an einigen Stellen Sprachmittel, die es in älteren Versionen schlicht nicht gibt. Nach oben sind Sie freier: Neuere Stände funktionieren erfahrungsgemäß, ältere nicht. Der interessante Eintrag in dieser Übersicht ist der letzte, und der ist optional. SDKMAN ist ein kleines Werkzeug, mit dem Sie mehrere Java- und Maven-Stände nebeneinander installieren und mit einem Befehl umschalten können.

5:37 Warum das nützlich ist, merkt man meist erst später: Auf der Arbeit läuft ein Projekt auf Java siebzehn, das Seminar hier auf fünfundzwanzig, und ohne so ein Werkzeug räumt man ständig an Umgebungsvariablen herum. Nötig ist es nicht — Sie können alles auch einzeln installieren. Es erspart Ihnen nur eine Klasse von Ärger, die niemand vermisst.

5:57 Zwei Befehle, und Sie wissen, woran Sie sind. Der Punkt dabei ist nicht die Ausgabe an sich, sondern wo Sie sie abfragen: im Terminal, nicht in der Entwicklungsumgebung. Denn die IDE bringt oft ihr eigenes Java mit und benutzt es auch. Auf der Kommandozeile gilt dagegen, was in Ihrem Pfad steht — und das ist erfahrungsgemäß nicht immer dasselbe.

6:18 Wenn hier eine andere Version erscheint als erwartet, dann lohnt sich die Viertelstunde, das jetzt geradezuziehen. Später, mitten in einem Build-Fehler, kostet dieselbe Ursache deutlich mehr Nerven. Diese vier Punkte klingen banal, und trotzdem stolpert fast jeder Kurs über mindestens einen davon. Zwei Java-Installationen, und der Pfad zeigt auf die ältere.

6:39 Eine frisch installierte Umgebung, aber die Entwicklungsumgebung läuft noch mit dem alten Zustand, weil sie nie neu gestartet wurde. Das Java der IDE mit dem Java der Kommandozeile verwechselt. Und schließlich Vorab-Versionen: Wer eine Beta einsetzt, sucht irgendwann Fehler, die im Release gar nicht existieren. Merken Sie sich vor allem eines — wenn etwas Unerklärliches passiert, ist der erste Blick der auf die Version.

Ein Maven-Projekt aufsetzen

7:05 Jetzt wird es konkret: Wir legen das Projekt an, und zwar mit Maven als Build-Werkzeug. Bevor wir irgendwo klicken, lohnt sich aber eine Frage, die im Kurs regelmäßig kommt — wozu überhaupt ein eigenes Build-Werkzeug, wo die Entwicklungsumgebung doch schon kompilieren kann? Die Antwort erklärt gleichzeitig, warum Java-Projekte alle so ähnlich aufgebaut sind.

7:26 Die kurze Antwort: weil das Bauen nicht an Ihrem Rechner hängen darf. Maven trennt das Erzeugen der Anwendung von der Arbeit in der Entwicklungsumgebung. Es gibt eine feste Verzeichnisstruktur vor, kümmert sich um den Klassenpfad, lädt Bibliotheken und liefert auf jedem Rechner dasselbe Ergebnis. Man nennt dieses Prinzip Konvention vor Konfiguration: Wer sich an die vorgegebene Ablage hält, muss fast nichts einstellen. Das fühlt sich am Anfang nach Bevormundung an.

7:53 Nach dem dritten Projekt merken Sie, dass Sie sich in jedem fremden Java-Projekt sofort zurechtfinden — genau weil alle dieselbe Struktur benutzen. Der wichtigste Punkt steht ganz oben: Der Build läuft auch dort, wo niemand eine Entwicklungsumgebung geöffnet hat. Das ist der Moment, in dem ein Projekt teamfähig wird. Solange nur Ihr Rechner die Anwendung erzeugen kann, ist sie ein Einzelstück. Dazu kommt das einheitliche Layout, das jedes Java-Werkzeug ohne Absprache versteht.

8:22 Abhängigkeiten stehen an einer Stelle statt als JAR-Dateien im Repository — was übrigens früher völlig normal war und heute zu Recht als Altlast gilt. Und schließlich: derselbe Befehl, dasselbe Ergebnis, überall. Reproduzierbarkeit ist im Betrieb keine Feinheit, sondern die Grundlage von Fehlersuche. Diese fünf Schritte sind schnell erzählt, und vier davon sind reines Ausfüllen von Dialogfeldern. Interessant sind zwei Details.

8:48 Erstens die Group ID: Sie identifiziert üblicherweise die Organisation, der der Code gehört, und taucht später als Paketname wieder auf. Zweitens der letzte Schritt — der automatische Abgleich zwischen der Projektdatei und der Entwicklungsumgebung. Ohne ihn ändern Sie etwas an der Konfiguration, und die IDE bekommt es schlicht nicht mit. Sie suchen dann einen Fehler im Code, der in Wahrheit gar keiner ist.

9:12 Einmal einschalten, und das Thema ist erledigt. Was Sie hier sehen, ist der Kern der Projektbeschreibung: wer der Code ist, wie er heißt, in welcher Version er steht. Die eine Änderung, die wir an der erzeugten Datei vornehmen, betrifft die Compiler-Einstellung. Die Entwicklungsumgebung schreibt üblicherweise zwei getrennte Angaben hinein — für die Sprachversion und für die Zielplattform.

9:36 Neuere Java-Stände bieten dafür eine einzige, präzisere Angabe. Der praktische Gewinn: Zwei Werte, die auseinanderlaufen können, werden zu einem, der es nicht kann. Das ist ein Muster, das Ihnen in diesem Seminar noch mehrfach begegnen wird. Diese vier Verzeichnisse sind der eigentliche Vertrag zwischen Ihnen und Maven. Produktionscode links, Testcode getrennt davon, Dateien zur Laufzeit noch einmal woanders — und alles Erzeugte landet im Zielverzeichnis.

10:03 Der letzte Punkt ist wichtiger, als er aussieht: Das Zielverzeichnis ist Ergebnis, nicht Quelle. Es gehört nie in die Versionsverwaltung, und es darf jederzeit gelöscht werden. Wenn Sie sich diese Grenze merken — hier steht, was ich geschrieben habe, dort steht, was der Build daraus gemacht hat —, dann verstehen Sie auch die meisten Build-Fehler deutlich schneller.

10:24 Jetzt sind Sie dran. Legen Sie das Projekt an, so wie wir es besprochen haben. Es geht dabei nicht darum, möglichst schnell zu klicken, sondern darum, danach in die erzeugte Projektdatei zu schauen und zu verstehen, was da eigentlich steht. Prüfen Sie, ob Group ID und Artifact ID stimmen und ob die Compiler-Einstellung aufgeräumt ist.

10:43 Und werfen Sie einen Blick in die Ausschlussliste für die Versionsverwaltung: Das Zielverzeichnis gehört da hinein. Wer möchte, legt gleich ein Git-Repository an — verpflichtend ist das für dieses Seminar nicht.

Die erste Klasse bauen und ausführen

10:56 Das Gerüst steht, jetzt kommt endlich Code. Viel wird es nicht sein — eine Klasse, eine Methode, eine Ausgabe. Interessanter ist, was wir direkt danach machen und was viele überspringen: Wir bauen dieselbe Klasse noch einmal, diesmal ohne Entwicklungsumgebung, nur mit Maven im Terminal. Der Vergleich der beiden Wege ist lehrreicher, als man erwartet.

11:18 Die erste Klasse landet nicht einfach irgendwo, sondern in einer Paketstruktur — und die entsteht nicht willkürlich. Sie setzt sich aus der Organisationskennung, dem Projektnamen und der Komponente zusammen. Das wirkt bei einer einzigen Klasse übertrieben. Aber wir wissen ja schon aus dem Überblick, dass mehrere Komponenten dazukommen.

11:37 Wer die Trennung von Anfang an anlegt, muss später nicht umziehen — und Umzüge von Paketen sind zwar technisch einfach, sozial aber teuer, weil sie jeden offenen Änderungsstand im Team berühren. Ein bisschen Voraussicht kostet hier fast nichts. Viel passiert hier nicht: eine Klasse, eine Main-Methode, eine Ausgabe. Zwei Kleinigkeiten sind trotzdem erwähnenswert.

11:58 Erstens braucht die Main-Methode in aktuellen Java-Ständen nicht mehr öffentlich zu sein — wer das aus älteren Projekten anders kennt, wundert sich sonst. Zweitens ist die Ausgabe über System-Punkt-out ein bewusstes Zwischenstadium. Sie wird uns am Ende dieses Moduls wieder begegnen, wenn wir sie durch echte Protokollierung ersetzen.

12:18 Merken Sie sich also ruhig, wie unbefriedigend das gerade ist — dieses Gefühl ist die Begründung für die letzte Station heute. Diese vier Schritte sind der eigentliche Erkenntnisgewinn dieses Kapitels. Sie öffnen ein Terminal und lassen Maven aufräumen — das Zielverzeichnis verschwindet sichtbar. Dann bauen Sie neu, und es entsteht wieder, samt fertigem Archiv.

12:39 Der Punkt dabei: Diesmal hat nicht die Entwicklungsumgebung kompiliert, sondern Maven, und zwar ohne dass wir irgendetwas konfiguriert hätten außer der Java-Version. Das funktioniert nur, weil wir uns an das Standardlayout gehalten haben. Beim allerersten Lauf dauert das übrigens länger, weil Maven sich seine eigenen Bausteine erst herunterlädt. Danach geht es schnell.

13:01 Die Aufgabe klingt trivial, und sie ist es technisch auch. Interessant ist, was Sie dabei beobachten. Bauen Sie das Projekt einmal über die Entwicklungsumgebung und einmal über die Kommandozeile, und schauen Sie danach ins Zielverzeichnis. Sie werden sehen, dass Maven etwas mehr hinterlässt als die IDE — unter anderem ein fertig gepacktes Archiv.

13:21 Erfolgreich ist die Aufgabe, wenn der Build sauber durchläuft und Sie diese Datei in der Hand haben. Das ist zum ersten Mal ein Artefakt, das Sie theoretisch jemandem geben könnten. Vier Klassiker. Die Klasse landet im Standardpaket, also ganz ohne Paketangabe — technisch erlaubt, praktisch der Anfang vom Chaos. Das Zielverzeichnis wandert in die Versionsverwaltung, und ab da diskutiert das Team über Konflikte in erzeugten Dateien.

13:47 Es wird ausschließlich über die Entwicklungsumgebung gebaut, und beim ersten automatisierten Build fällt auf, dass etwas fehlt. Und der vierte, der eigentlich für das ganze Seminar gilt: Maven-Ausgaben werden überflogen. Die entscheidende Warnung steht fast immer weit oben, lange bevor das rote Wort am Ende erscheint.

Argumente verarbeiten

14:07 Unsere Anwendung soll später die Kurse einer bestimmten Autorin holen. Aber woher weiß sie, welche? Von außen — über die Kommandozeile. Damit bekommt das Programm zum ersten Mal eine Schnittstelle zur Außenwelt. Und jede Schnittstelle bekommt irgendwann Eingaben, mit denen niemand gerechnet hat. Schauen wir uns an, wie man das sauber abfängt, bevor es weh tut.

14:29 Eine Kommandozeile ist eine Benutzerschnittstelle, auch wenn sie nicht so aussieht. Und wie jede Schnittstelle bekommt sie Eingaben, mit denen niemand gerechnet hat — in unserem Fall gar keine. Kursradar prüft deshalb gleich zu Beginn, ob eine Kennung übergeben wurde, und bricht mit einem verständlichen Hinweis ab, wenn sie fehlt.

14:47 Das ist eine Minute Arbeit und erspart später eine unangenehme Fehlersuche, bei der die Anwendung irgendwo tief drinnen an einer halbfertigen Adresse scheitert. Fehler früh und deutlich zu melden ist eine der billigsten Qualitätsmaßnahmen, die es gibt. Zwei Muster stecken in diesen paar Zeilen. Das erste ist der Wächter ganz oben: Fehlt die Eingabe, sagt das Programm das und beendet sich, statt weiterzumachen.

15:11 Das zweite ist das Auffangbecken darunter — ein Bereich, der jede unbehandelte Ausnahme abfängt. Das Ausgeben des Fehlerprotokolls ist an dieser Stelle noch grob; wir ersetzen es später durch eine ordentliche Meldung. Der Gedanke dahinter bleibt aber: Es gibt genau eine Stelle, an der alles landet, was sonst niemand behandelt hat. Ohne diese Stelle endet Ihre Anwendung im Zweifel wortlos.

15:35 Stellen Sie sich einen Wasserschaden vor. Sie können in jedem Zimmer einen Eimer aufstellen — oder Sie sorgen dafür, dass alles, was durchläuft, an einer Stelle ankommt, wo jemand es sieht. Genau das macht dieser äußere Bereich. Er ersetzt keine gezielte Fehlerbehandlung: Wenn Sie tief im Code wissen, wie Sie auf ein bestimmtes Problem reagieren, dann tun Sie das dort.

15:57 Aber alles, wofür es keine sinnvolle Reaktion gibt, soll wenigstens sichtbar werden. Und der Nutzer bekommt eine Meldung statt eines Programms, das sich kommentarlos verabschiedet. Der erste Punkt ist der, der am meisten Zeit kostet: Ein fehlendes Argument fällt erst beim Netzwerkaufruf auf, und dann sucht man den Fehler an der falschen Stelle.

16:17 Der zweite ist das Gegenteil des Auffangbeckens — überall Ausnahmen fangen und stillschweigend weitermachen. Das ist der zuverlässigste Weg, einen Fehler unsichtbar zu machen. Der dritte: Man schreibt die Kennung fest in den Code, weil das Setzen in der Entwicklungsumgebung gerade unbequem ist. Und der vierte betrifft die Ausgabe des Fehlerprotokolls — als Zwischenlösung in Ordnung, als Dauerzustand nicht. Dazu kommen wir gleich.

Die erste Abhängigkeit

16:42 Bis hierhin haben wir ausschließlich mit dem gearbeitet, was Java selbst mitbringt. Das ändert sich jetzt: Wir binden zum ersten Mal fremden Code ein. Technisch ist das ein Routinevorgang von sechs Zeilen. Trotzdem lohnt es sich, ihn einmal bewusst zu betrachten — denn mit jeder Bibliothek übernehmen Sie auch Verantwortung für Code, den Sie nicht geschrieben haben.

17:03 Maven Central ist so etwas wie das öffentliche Lager der Java-Welt: Praktisch jede Bibliothek, die es gibt, liegt dort. Angesprochen wird sie über drei Angaben — wer sie herausgibt, wie sie heißt und in welcher Version. Maven holt sie einmal, legt sie lokal ab und stellt sie dem Compiler bereit. Das klingt selbstverständlich, ist aber noch keine zwanzig Jahre alt. Davor lud man Archive von Projektwebseiten herunter und legte sie ins eigene Repository.

17:30 Wer solche Projekte einmal erben durfte, weiß, warum dieser Schritt ein echter Fortschritt war. Diese fünf Schritte beschreiben, wie Sie an die drei Angaben kommen, wenn Sie sie nicht auswendig wissen — und das ist der Normalfall. Die Suche auf der Seite von Maven Central liefert meist mehrere Treffer, und da lohnt der zweite Blick: Oft gibt es zu einer Bibliothek mehrere Bausteine, und Sie wollen genau einen bestimmten davon.

17:55 Bei der Version gilt: eine echte Freigabe, keine Vorab-Fassung. Und der letzte Schritt ist die Kontrolle — taucht die Bibliothek in der Entwicklungsumgebung auf, hat Maven sie tatsächlich geholt. Sechs Zeilen, mehr braucht es nicht. Bemerkenswert ist der Hinweis darunter: Was einmal in Maven Central veröffentlicht wurde, verschwindet dort nicht wieder.

18:15 Das wirkt zunächst wie eine Kleinigkeit, ist aber die Grundlage dafür, dass ein Build von vor fünf Jahren heute noch durchläuft. Irgendwo hängt immer noch ein Projekt an genau dieser Version. Für Sie heißt das: Sie dürfen eine konkrete Version festschreiben und sich darauf verlassen. Sie sollten sie nur nicht vergessen — dazu gleich mehr bei den Stolpersteinen.

18:36 Der erste Punkt ist der ernsteste. Eine Abhängigkeit einzubinden ist einfach; sie gepflegt zu halten, ist Arbeit — und zwar dauerhaft. Der Code, den Sie sich ins Haus holen, kann Sicherheitslücken enthalten, und niemand außer Ihnen wird ihn in Ihrem Projekt aktualisieren. Der zweite: Vorab-Versionen, weil sie in der Liste ganz oben stehen. Der dritte ist die erwähnte Altlast, Archive von Hand herunterzuladen.

19:01 Und der vierte ist eine Frage des Maßes: Für jede Kleinigkeit eine Bibliothek zu ziehen, macht die Anwendung nicht besser, sondern nur größer und angreifbarer.

Logging mit SLF4J

19:11 Wir haben jetzt eine Bibliothek eingebunden, aber noch gar nicht benutzt. Das holen wir zum Abschluss dieses Moduls nach. Dabei ersetzen wir die provisorischen Ausgaben durch etwas, das man im Betrieb tatsächlich auswerten kann — und lernen nebenbei ein Muster kennen, das Ihnen in Java an vielen Stellen wieder begegnen wird.

19:29 Hier steckt ein Muster, das Ihnen in Java immer wieder begegnet: die Trennung von Schnittstelle und Umsetzung. SLF4J ist keine Protokollbibliothek. Es ist eine Fassade davor — Ihr Code spricht nur mit dieser Fassade, und wer tatsächlich schreibt, entscheidet sich erst zur Laufzeit. Der Vergleich, der ganz gut trägt: eine Steckdose. Ihr Gerät kennt nur den Stecker, nicht das Kraftwerk. Wechselt der Anbieter, ändert sich am Gerät nichts.

19:56 Und wenn gar kein Kraftwerk angeschlossen ist, passiert eben nichts — genau das werden wir gleich erleben. Zwei Dinge lohnen sich hier. Erstens: Statt Zeichenketten zusammenzukleben, setzen Sie geschweifte Klammern als Platzhalter und übergeben die Werte getrennt. Das liest sich besser — und es spart Arbeit, denn wenn die Protokollstufe gar nicht aktiv ist, wird die Nachricht erst gar nicht gebaut.

20:20 Zweitens die Fehlermeldung ganz unten: Die Ausnahme wird als eigenes Argument übergeben, nicht in den Text hineingeschrieben. Nur so landet auch der vollständige Aufrufweg im Protokoll. Damit hat sich das Ausgeben des Fehlerprotokolls von vorhin erledigt. Diese Tabelle erklärt einen Fehler, den Sie garantiert einmal sehen: Die Anwendung läuft, meldet aber, sie habe keine Protokoll-Umsetzung gefunden, und schreibt nichts.

20:46 Der Grund steht hier. Die eine Abhängigkeit ist die Schnittstelle, gegen die Sie programmieren. Die andere ist die Umsetzung, die tatsächlich schreibt — und die berühren Sie im Code nie. Genau deshalb bekommt sie einen anderen Geltungsbereich: verfügbar beim Ausführen, unsichtbar beim Übersetzen. Das ist kein Formalismus.

21:05 Es verhindert technisch, dass sich jemand doch an die konkrete Umsetzung bindet. Ein kleiner Schritt mit großer Wirkung. Beide Bausteine gehören zusammen und müssen dieselbe Version haben. Solange die Zahl an zwei Stellen steht, wird sie irgendwann an einer davon vergessen — nicht aus Nachlässigkeit, sondern weil beim Aktualisieren niemand an die zweite denkt.

21:26 Eine Eigenschaft an einer Stelle, zwei Verweise darauf, und das Problem existiert nicht mehr. Merken Sie sich dieses Muster: In Modul fünf treiben wir es weiter und heben solche Angaben aus den einzelnen Modulen heraus an eine gemeinsame Stelle. Jetzt räumen Sie auf. Ersetzen Sie sämtliche direkten Ausgaben durch Protokollaufrufe, in der jeweils passenden Stufe — Information, Warnung, Fehler.

21:49 Achten Sie dabei auf die Platzhalter statt auf Zeichenkettenverkettung, und geben Sie die Ausnahme als eigenes Argument mit. Fertig sind Sie, wenn im Lauf jede Zeile Zeitstempel, Stufe und Herkunftsklasse zeigt und die Version nur noch an einer Stelle in der Projektdatei steht. Wer mag, tauscht danach die Umsetzung testweise gegen eine andere aus — ohne eine einzige Zeile Java zu ändern. Das ist der Beweis, dass die Fassade ihren Zweck erfüllt.

22:16 Der erste Punkt ist der erwähnte Klassiker: nur die Schnittstelle eingebunden, keine Umsetzung — die Anwendung sagt das sogar, man muss die Meldung nur lesen. Der zweite ist subtiler: die Umsetzung im falschen Geltungsbereich, sodass man versehentlich gegen sie programmieren kann. Damit ist der ganze Vorteil der Fassade dahin.

22:35 Der dritte und vierte betreffen die Schreibweise — Verkettung statt Platzhalter und die Ausnahme im Text statt als Argument. Beides funktioniert scheinbar. Auffallen tut es erst, wenn Sie im Ernstfall den Aufrufweg brauchen und ihn nicht haben.

Das Gerüst steht

22:50 Halten wir fest, was jetzt da ist. Ein Maven-Projekt, das auf jedem Rechner gleich baut. Eine Einstiegsklasse, die ihre Eingaben prüft und einen Ort für unerwartete Fehler hat. Und eine Protokollierung, deren Umsetzung austauschbar bleibt. Das ist wenig Funktion und viel Fundament — aber genau in dieser Reihenfolge entstehen Projekte, die man später noch anfassen kann.

23:12 Im nächsten Modul wird es dann inhaltlich: Kursradar ruft zum ersten Mal eine fremde Schnittstelle auf und holt sich echte Daten. Und dabei stellen sich sofort ganz neue Fragen.