Den Ausleihzustand nach einem Neustart erhalten

JavaBeginner
Jetzt üben

Einführung

Eine Werkzeugausgabe muss auch nach dem Schließen der Anwendung wissen, wer welches Werkzeug hat. Diese unabhängige Umgebung enthält funktionierende Ausleihregeln und eine neue Ausgabedatei mit bestehenden Ausleihen und einem Werkzeug in Wartung. Der unvollständige Speichercode verliert derzeit beim Laden den gespeicherten Zustand und schreibt keine Änderungen.

Du ordnest UTF-8-Dateidatensätze Objekten zu und speicherst nur gültige Änderungen. Die Objektregeln aus dem vorherigen Lab werden vorausgesetzt; Dateien aus dessen Umgebung brauchst du nicht. Dies ist eine Lernanwendung mit einem einzelnen Prozess, keine Datenbank und keine Absicherung gegen Stromausfälle. Vom Autor geschätzte Lese- und Übungszeit: 45 Minuten.

Den tatsächlich auf dem Datenträger gespeicherten Zustand laden

In diesem Schritt liest du einen gewöhnlichen Dateidatensatz und reparierst anschließend, wie gespeicherte Zustände und Beziehungen zu ausleihenden Personen in Java-Objekte überführt werden.

Öffne den Tab Terminal. cd wählt den Ordner dieses unabhängigen Labs aus. Mit Ctrl+U löschst du eine falsch eingegebene, noch nicht ausgeführte Shell-Zeile. Kehre bei einem Dateipfadfehler hierher zurück und wiederhole den richtigen Befehl.

cd /home/labex/project/tool-library

Die Anwendung bietet funktionierende Objektregeln, aber unvollständigen Speichercode. Verwende zunächst eine kleine Übungsdatei, um das Format mit fünf Feldern kennenzulernen, ohne bestehende Ausleihen zu gefährden. mkdir -p erstellt bei Bedarf den Übungsordner. printf schreibt nach einem vorgegebenen Format: \t erzeugt einen Tabulator und \n beendet den Datensatz; > schreibt die Ausgabe in die benannte Datei und ersetzt eine frühere Übungskopie. Die einfachen Anführungszeichen verhindern, dass die Shell das Format verändert. cp kopiert die Mitgliederliste neben diese Datei, weil die Anwendung members.tsv neben der als Eingabe übergebenen Datei der Werkzeugausgabe sucht. Keiner dieser Befehle verändert die echte Werkzeugausgabe.

mkdir -p work
printf 'S01\tSpare drill\tAVAILABLE\t-\tPractice only\n' > work/sample.tsv
cp members.tsv work/members.tsv

Kompiliere den aktuellen Quelltext. -encoding UTF-8 wählt seine Textkodierung, -d out das Ziel der kompilierten Dateien und *.java die Java-Dateien dieses Ordners aus. Fahre nur fort, wenn die Kompilierung ohne Fehler gelingt.

javac -encoding UTF-8 -d out *.java

-cp out nennt Java den Ort der Klassen. -Dfile.encoding=UTF-8 wählt die Textkodierung zur Laufzeit. Die Übungseingabe ist work/sample.tsv; --memory verhindert das Speichern dieser Demonstration.

java -Dfile.encoding=UTF-8 -cp out Desk work/sample.tsv --memory

Gib im Programm diese Zeilen ein und drücke nach jeder Enter:

list
borrow S01 M01
list
quit

S01 beginnt mit AVAILABLE und der ausleihenden Person -; die Ausleihe an M01 gelingt. Dieser gewöhnliche Fall funktioniert auch mit dem unvollständigen Ladecode, weil der Übungsdatensatz bereits den Zustand hat, den der fehlerhafte Code voraussetzt. Er kann nicht beweisen, dass bestehende Ausleihen erhalten bleiben. Die Übungsänderung verschwindet beim Schließen dieses Prozesses.

Lies die echte Werkzeugausgabe und die registrierten Mitglieder. cat zeigt eine Datei an, ohne sie zu bearbeiten:

cat desk.tsv
cat members.tsv

Es gibt fünf tabulatorgetrennte Felder: ID, Name, Enum-Zustand, ausleihende Person und Notiz. Das kontrollierte Format erlaubt Leerzeichen und UTF-8-Text in den Feldern, aber keine Tabulatoren oder Zeilenumbrüche. T24 ist bereits an M03 ausgeliehen; T25 ist an M02 ausgeliehen und hat die Notiz Cafe workshop. T23 ist in Wartung. Diese Fakten müssen beim Laden erhalten bleiben. Bearbeite desk.tsv, members.tsv und den Ordner reference nicht direkt.

Lies den vorbereiteten Speichercode:

cat Store.java

Store bildet die Persistenzgrenze: In load werden Datensätze zu Objekten, in save Objekte zu Datensätzen. Files.readAllLines liest ausdrücklich UTF-8. fields(line) prüft das Format und liefert die Felder f[0] bis f[4]. Suche den Aufruf new Tool(...): Er setzt derzeit für jede Zeile Tool.State.AVAILABLE und "-" ein. Sage die Auswirkungen auf die ausleihende Person von T24 und den Wartungszustand von T23 voraus. Schleife, Liste, Parser- und Validierungshilfen sind bereits vorbereitet; erhalte sie. Ihre HashSet-Implementierung musst du nicht neu schreiben.

Erstelle vor dem Bearbeiten eine reine Quelltextsicherung:

cp Store.java work/Store-before-load.java.txt
nano Store.java

Wie im ersten Lab sucht Ctrl+W, Enter bestätigt die Suche, Pfeiltasten bewegen den Cursor und Backspace korrigiert Zeichen. Suche nach Tool tool = new Tool, um diesen einen Konstruktoraufruf zu finden. Ändere seine Zustands- und Ausleiherargumente so, dass er lautet:

            Tool tool = new Tool(f[0], f[1], Tool.State.valueOf(f[2]), f[3], f[4]);

Tool.State.valueOf(f[2]) wandelt den gespeicherten Enum-Namen in seinen Enum-Wert um; f[3] stellt die gespeicherte ausleihende Person wieder her. Erhalte die Argumente für ID, Name und Notiz, die umgebende Schleife sowie alle Hilfsmethoden. Du ordnest vorhandene Informationen zu, statt ein neues verfügbares Werkzeug zu erfinden. Speichere mit Ctrl+O, Enter und beende mit Ctrl+X. Einen ungespeicherten Fehler verwirfst du mit Ctrl+X, N. Öffne die Datei erneut und suche den Aufruf, um einen Compilerfehler zu beheben. Falls du diese Änderung bewusst neu beginnen musst, stellt cp work/Store-before-load.java.txt Store.java nur diese Quelldatei wieder her; wiederhole danach die Zuordnung. Führe niemals setup erneut aus, um Änderungen rückgängig zu machen.

Hier deklariert throws IOException, dass Dateizugriffe fehlschlagen können. Bei fehlender oder fehlerhaft formatierter Eingabe zeigt die Befehlsschleife Cannot continue an und hält an. Das ist ein Dateiproblem, keine abgewiesene Ausleihe. Korrigiere den genannten Pfad oder die Quelltextzuordnung; leere oder überschreibe die ursprünglichen Datensätze nicht, um den Fehler zu beseitigen.

Kompiliere den gespeicherten Quelltext und starte die echte Werkzeugausgabe. Anders als in der Demonstration lässt du --memory weg: Die echte Ausgabe speichert gültige Änderungen, sobald du im nächsten Schritt das Speichern vervollständigst. Ein Syntaxfehler nennt Datei und Zeile. Korrigiere ihn in nano und kompiliere vor dem Start erfolgreich, statt alte Klassen auszuführen.

javac -encoding UTF-8 -d out *.java
java -Dfile.encoding=UTF-8 -cp out Desk desk.tsv

Gib diese Zeilen im Programm der Werkzeugausgabe ein:

list
members
quit

Die Liste muss T24 → M03, T25 → M02, den Zustand MAINTENANCE von T23 und alle Notizen erhalten. members zeigt die registrierten IDs. Öffnen und Auflisten dürfen die Datei nicht neu schreiben. quit führt zur Shell zurück. Der nächste Schritt vervollständigt das tatsächliche Speichern; eine Erfolgsmeldung allein würde keine Persistenz beweisen.

Gültige Änderungen speichern und die Ausgabe erneut öffnen

In diesem Schritt sorgst du dafür, dass eine neue Ausleihe und eine gültige Rückgabe auch nach dem tatsächlichen Ende des Prozesses erhalten bleiben.

Beginne in der Shell desselben Tabs Terminal. Beim Speichern wird jedes aktuelle Objekt serialisiert, einschließlich unveränderter Ausleihen und Wartungsdatensätze. row(tool) verbindet die fünf Felder mit Tabulatoren. Die Schleife fügt alle Zeilen zu einer Liste hinzu; Files.write schreibt diese als UTF-8. Die Befehlsschleife ruft save nur auf, nachdem eine Fachmethode normal zurückgekehrt ist. Eine abgewiesene Aktion darf die Datendatei nicht beschreiben, auch nicht mit identischem Inhalt.

Lies das Befehlsgerüst, um diese Regel mit der Persistenzgrenze zu verbinden:

cat Desk.java

Suche found.borrow(c[2]), found.giveBack(c[2]) und den folgenden Aufruf Store.save(path, tools). Eine ausgelöste Fachausnahme überspringt den Speicheraufruf und wird zu einer normalen Ablehnung. Erhalte diese vorbereitete Reihenfolge; ein zusätzlicher Schreibaufruf in der Fehlerbehandlung würde den Vertrag verletzen.

Erstelle eine reine Quelltextsicherung, die deinen korrigierten Ladecode erhält:

cp Store.java work/Store-before-save.java.txt
nano Store.java

Drücke Ctrl+W, suche nach TODO: write all rows und drücke Enter. Lies die Schleife unmittelbar darüber: Sie sammelt eine serialisierte Zeile für jedes Werkzeug, einschließlich unveränderter Ausleihen. Gehe mit den Pfeiltasten zum Ende dieses Kommentars und entferne seine Zeichen mit Backspace. Gib den Schreibaufruf mit derselben Einrückung ein. Ersetze nur den TODO-Kommentar durch diesen tatsächlichen Schreibaufruf nach der Schleife und vor der schließenden Klammer der Methode:

        Files.write(path, rows, StandardCharsets.UTF_8);

path ist die gewählte Ausgabedatei; rows ist die vollständige serialisierte Liste, nicht nur das zuletzt geänderte Objekt. Der ausdrücklich angegebene Zeichensatz erhält die Textkodierung jedes Feldes. Erhalte die korrigierte Methode load, die Zeilenschleife und alle Hilfsmethoden. Speichere mit Ctrl+O, Enter, Ctrl+X. Einen ungespeicherten Fehler verwirfst du mit Ctrl+X, N. Bei einem gespeicherten Quelltextfehler öffne die Datei erneut und korrigiere ihn; cp work/Store-before-save.java.txt Store.java ist eine optionale reine Quelltextwiederherstellung, die deinen Ladecode erhält. Ergänze danach den Schreibaufruf erneut. Setze weder die Ausgabedatei zurück noch führe setup erneut aus.

Kompiliere den gespeicherten Quelltext erneut:

javac -encoding UTF-8 -d out *.java
java -Dfile.encoding=UTF-8 -cp out Desk desk.tsv

Gib in der Ausgabe Folgendes ein:

borrow T21 M01
borrow T21 M02
return T24 M01
borrow T23 M01
borrow TYPO M01
return T24 M03
list
quit

T21 wird an M01 ausgeliehen. Die doppelte Ausleihe, die falsche Person bei der Rückgabe, die Ausleihe des Werkzeugs in Wartung und die falsch eingegebene ID werden erwartungsgemäß abgewiesen. Nur die Rückgabe von T24 durch M03 gelingt. T22 bleibt verfügbar, T23 bleibt in Wartung und T25 bleibt mit der ursprünglichen Notiz an M02 ausgeliehen. Nach der unbekannten ID ist die Befehlsschleife weiterhin nutzbar. Korrigiere die ID, statt neu zu starten oder die Umgebung zurückzusetzen.

Starte jetzt einen neuen Java-Prozess mit derselben Datei:

java -Dfile.encoding=UTF-8 -cp out Desk desk.tsv
list
quit

T21 muss weiterhin durch M01 BORROWED sein; T24 muss weiterhin AVAILABLE sein und als ausleihende Person - haben. Andernfalls prüfe, ob du die aktuelle Store.java kompiliert und ohne --memory gestartet hast. Bearbeite die endgültigen Datensätze nicht, um eine gespeicherte Ausleihe vorzutäuschen. Wenn eine akzeptierte Aktion bereits gespeichert wurde, wiederhole sie nicht nur deshalb, weil sie nun abgewiesen wird; list zeigt den aktuellen tatsächlichen Zustand.

Lies zurück in der Shell das tatsächlich gespeicherte Ergebnis:

cat desk.tsv

Die Datensatzbeziehungen müssen mit der Liste im neuen Prozess übereinstimmen. Erhalte sämtliche IDs, Namen, Mitglieder, Wartungszustände, nicht betroffenen Ausleihen und Notizen. Nur Zustand/ausleihende Person von T21 und Zustand/ausleihende Person von T24 ändern sich. Diese kleine Schreibkomponente ersetzt die Datei bei einem erfolgreichen Speichern. Sie bietet keinen gleichzeitigen Zugriff, keine Wiederherstellung nach einem Absturz und keine atomare Transaktion. Schlägt das Schreiben fehl, halte an und prüfe den Fehler, bevor du fortfährst.

Zusammenfassung

Du hast UTF-8-Datensätze Java-Objekten zugeordnet, nach einem gültigen Übergang jeden aktuellen Datensatz gespeichert und die Ausgabe in einem neuen Prozess geöffnet. Bestehende Ausleihen, Wartungszustände und Notizen blieben erhalten, während abgewiesene Aktionen nichts in den Datenspeicher schrieben.