Ein RandomAccessFile dient uns im Semesterprojekt dazu, die Personendaten persistent zu machen. Im dem zum Blogpost gehörenden Vlog Semesterprojekt_05_funct_erweit_fileops3u4 geht es um die Interimsversion V03: die dateiorientierten Methoden (RandowAccessFile-Methhoden) zu den Menüoptionen “Records in eine Datei sichern > 3” und “Records aus einer Datei laden >4” werden ausprogrammiert.
Zuerst Vlog und dann Blog
Ich habe das oben erwähnte Video zuerst veröffentlicht, damit Sie die im Programm verwendeten Konzepte sehen. Der Blog hier soll jetzt vielleicht einige Unklarheiten beseitigen und das ein oder andere Konzept für die Dateibehandlung plausibel machen.
Dateien
Dateien werden heute als Möglichkeit genutzt Daten dauerhaft festzuhalten (dies wird auch als Persistenz bezeichnet)- Daten werden in Dateien persistent gemacht. Später werden wir dazu auch Datenbanken nutzen. Warum also erst Dateien nutzen und nicht gleich Datenbanken?
Für Dateien sprechen mehrere Gründe: 1) in den heute gängigen Betriebssystemen – egal ob für Dektop-Computer oder für Mobiles – alle Betriebssysteme (engl. kurz OS für “Operating System”) haben als eingebaute Funktionalität ein “Dateisystem” (engl. “Filesystem”). Ein eingebautes Datenbanksystem (engl. kurz DBMS für “Database Management System”) liefern nur die wenigsten Betriebssysteme mit. Wer’s braucht, muss es separat kaufen.
2) Mit einem DBMS ist das Codd’sche “relationale Modell” mehr oder weniger fest verbunden, das die Grundlage der relationalen Datenbanken ist, die bis heute einen Standard der Datenbanktechnik darstellt. Um uns nicht während der Einarbeitung in die Programmiersprache JAVA im gleichen Kurs mit dem relationalen Modell auch auseinander setzen zu müssen (und wegen 1)) weichen wir also auf Dateien aus.
3) Filesysteme werden noch eine Weile ihre massivste Existenberechtigung darin haben, dass das Betriebssystem selbst sich auch im Filesystem abgelegt sieht, ebenso die vom Betriebssystem benötigten diversen Hilfsfiles.
Wenn es überall, wo Java verfügbar ist, auch ein Dateisystem gibt, so können wir gleich von Anfang an mit Dateien arbeiten, unsere Daten dort persisten ( = “dauerhaft“) zu machen. Für unser Semesterprojekt “friends” bedeutet das, dass wir
mit dem Menüpunkt “Records in eine Datei sichern: > 3” dafür sorgen, dass die Daten in einer Datei für die langfristige Datenerhaltung gespeichert wurden. Wenn wir danach die Applikation beenden (mit dem Menüpunkt “das Programm verlassen: > 6“), lagern unsere vorher erfassten Daten sicher in der Datei, bis wird sie wieder sehen möchten
Die friends sind nicht verloren
Wenn wir später unsere friends wieder in der Applikation sehen möchten, müssen wir nur mit dem Menüpunkt “”Records in eine Datei laden: > 4” die Daten aus der Datei holen, so dass wir die Daten wieder verfügbar haben und mit der Menüauswahl “Records auflisten > 2” auf der Konsole wieder ausgeben können und weiter Daten aufnehmen können: “eine neue Person aufnehmen > 1”
Zusammenhang Daten im Hauptspeicher und Daten auf der Platte
Schauen wir uns mal den Zusammenhang zwischen unserer String-Matrix myPersons und der Datei personenDB.csv an. Die Stringmatrix befindet sich im Hauptspeicher (kurz “RAM” genannt), wenn unser Programm läuft. Die Daten daraus sollen in der Datei dauerhaft gemacht werden. Die Datei befindet sich auf der Platte unseres Java-Computers.
Natürlich interessieren sich die/der Programmierer/innen für die Frage, wie Daten des Java-Programms im Hauptspeicher und auf der Platte abgelegt werden. Im Laufe Ihres Studiums werden Sie das an anderer Stelle auch noch sehr exakt kennenlernen!
Für den/die Programmierer/innen ist es zunächst aber wichtiger, eine modellhafte, konzeptionelle Vorstellung von der Datenablage im Hauptspeicher und auf dem Hintergrundspeicher (Platte/hard disk/solid state disk (kurz SSD genannt) zu haben, also zu abstrahieren. (Abstrahieren bedeutet von Details absehen).
Vorstellung von der Matrix String [][] myPersons
Die Stringmatrix können wir kurz behandeln, denke ich. Wir haben bei der Diskussione von zweidimensionalen Arrays das Bild des Eierkartons verwendet und uns dann darauf geeinigt, dass beim Umgang mit Array generell eine kleine Skizze hilfreich ist. Ausserdem haben Sie zu Array auch diverse Übungen gemacht.
Wenn wir im Semesterprojekt die Personendaten in der String-Matrix MyPersons sammeln, stellen Sie sich deshalb die im Bild unten im grünen Rahmen gezeichnete Matrix vor: in der Zeile 0 haben wir die Personendaten “Herr”, “Otto”, “Diesel” für die Anrede, den Vornamen und den Nachnamen gesammelt. Wenn wir diese Daten auch für “Frau”, “Claudia”, “Lusser” aufgenommen haben, können wir uns diese Daten in der zweiten Matrixzeile vorstellen. (Sie sehen also wir brauchen Vorstellungskraft = Phantasie)
Sorry, für die nicht besonders entwickelte Schreib- und Zeichenhand. Aber sicherlich erkennen Sie die Stringmatrix mit ihren Einträgen und den skizzierten Zeilen- und Spalten-Indizes. (Klicken Sie aufs Bild und studieren Sie es in einer vergrößerten Darstellung).
Die im RAM (englisch kurz für Random Access Memory – das ist der Hauptspeicher) befindet sich die String-Matrix myPersons irgendwo. Die genaue Lage im RAM interessiert uns in diesem Zusammenhang nicht. Das soll durch die drei Punkte vor und nach der Matrix verdeutlicht werden. Ausserdem haben wir in unserer Interimsversion V03 ja auch noch andere Daten in unserer Lösung.
Immerhin, wir haben jetzt eine Vorstellung von der Stringmatrix myPersons. Wie aber können wir uns das RrandomAccessFile personenDB.csv vorstellen?
Vorstellung vom RrandomAccessFile personenDB.csv
Schauen wir uns dazu ein etwas ausführlicheres Bild an (unten). Im Bild oben “RAM_und_Platte” haben Sie das RandomAccessFile schon im roten Kasten entdeckt. Hier ein etwas präziseres Bild mit einigen zusätzlichen Informationen – aber immer noch ein Konzeptbild – wie gesagt, das Bild in unseren Köpfen muss für den/die JAVA-Programmierer/innen hinreichend sein.
Im Bild oben “Vom Ram in die Datei auf der Platte” sind einige Code-Zeilen eingebette und die Zusammenhänge zwischen Java-Code und der konzeptionellen Vorstellung der Datei personenDB.csv farblich gekennzeichnet.
Mit RandomAccessFile-Methode writeBytes() Daten ins File
Der im Bild erkennbare grüne Kasten (symbolisier den RAM) zeigt, wie man sich die Matrix String myPersons [][] vorstellen kann, nachdem zwei Personendatensätze erfasst/aufgenommen wurden (mit den Methoden funct_1() und pers_append()).
Im Vlog Semesterprojekt_05_funct_erweit_fileops3u4 finden Sie
- die Deklaration der Matrix in der Codezeile 20,
- die Deklaration der Methode funct_1() in Codezeile 59 ff und
- die Deklaration der Methode pers_append() ind Codezeile 166ff
Wir wollen die Inhalte der Matrix myPersons in der RandomAccessDatei personenDB.csv speichern
- die Deklaration der RandomAccessDatei personenDB.csv finden Sie in den Codezeilen 136 – 138. (Die try-catch-Konstruktion darum herum ist zwingend notwendig – warum? Damit beschäftigen wir uns später!)
- Wie unser Programm nun die Daten in die RandomAccessDatei hineinschreibt finden Sie in der Methode funct_3() im Rahmen der for-Schleife in den Codezeilen 103 – 108. Die verwendten writeBytes()-Methodenaufrufe finden Sie im Bild oben unter dem grünen Rahmen notiert, Die relevanten Codezeilen sind dort auch notiert.
Jetzt sollten Sie erkennen, dass raf.writeBytes() die Feldinhalte aus der Matrix myPersons in die RandomAccessDatei personenDB.csv schreib. Wir können uns die Ablage in der Datei dabei Bildlich so vorstellen, wie sie oben gezeichnet ist! Das RandomAccessFile sieht einem Array seht ähnlich – ist aber natürlich kein Array!
Wichtig ist, dass sie erkennen, wie die Methode writeByte() auf die Matrix myPersons zugreift und wie die Daten dann im RandomAccessFile personenDB.csv liegen, die Felder durch “;” getrennt werden und der Zeilenwechsel durch NEWLINE symbolisiert wird.
Weitere RandomAccessFile-Methoden…
…werde ich später in einem Blogpost-Nachtrag hier ergänzen.
Aphorismen zu Baustellen
Wie bei Gebäudebaustellen so geht es auch manchmal bei Software-Baustellen zu:”drunter und drüber”. Bei beiden Baustellen sorgen die Baumeister dafür, dass das Chaos nicht zu groß wird – die Teams müssen den Überblick behalten.
Für den Überblick sorgen wir, indem wir die Klasse im Demobeispiel “aufgeräumt” halten: Daten und Methoden sind fein säuberlich getrennt, obwohl uns JAVA nicht dazu zwingt. Daten- und Methodendeklarationen können auch durcheinander notiert werden. Die Ordnung “zuerst alle Datendeklarationen”, “danach alle Methodendeklarationen” hat aber in diesem Fall Vorteile: die Klasse lässt sich leichter lesen, pflegen und weiterentwickeln, durch Ergänzung und Änderung der Methoden- und Daten-Deklarationen.
Trotz der Ordnungsversuche bleiben Baustellen eine Stück weit ein “Durcheinander”. Beim “Grooming” wird das fertige Produkt dann noch entsprechend “aufgeräumt”, damit einer langfristigen Wartbarkeit nichts im Wege steht.