Konstruktor mit filename bzw. methode load(filename)

[nossek]

Guten Abend

Zu Übungszwecken bastle ich grad ein kleines Büchereiprojekt. Die Klasse Library sieht so aus (Wie die Klasse Book aussieht ist für meine Fragen wohl unerheblich):

import java.io.Serializable;
import java.util.ArrayList;

public class Library implements Serializable{

    private boolean unsavedChanges = false; //wird derzeit noch nicht benutzt...
    private ArrayList<Book> books;

    public Library() {
        books = new ArrayList<Book>(100);
    }

    public void addBook(Book book){
        books.add(book);
        unsavedChanges = true;//wird derzeit noch nicht benutzt...
    }

    @Override
    public String toString() {
        StringBuilder result = new StringBuilder(10000);
        for(Book b : books){
            result.append(b.toString() +"\n");
        }
        return result.toString();
    }

}

Man ahnt es schon, es geht um das Speichern und Laden von Library-Objekten.
(Nebenbei-Frage:
ist die Methode toString() so okay, kommt mir ein wenig murksig vor, zudem warnt NetBeans "String concat in StringBuilder.append" - es funktioniert aber.)
EDIT: Die IDE-Warnung "String concat in StringBuilder.append" ist mir jetzt klar: das unterminiert die Effizienzsteigerung vom StringBuilder und ist deshalb dumm, gelle?!

Das Speichern und laden in der main-methode sieht so aus und funktioniert auch (man beachte meinen guten Büchergeschmack ):

import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;

public class Main {

    public static void main(String[] args) {
       
        Library l1 = new Library();
        Library l2 ;

        l1.addBook(new Book("Barthes, Roland", "Die Helle Kammer"));
        l1.addBook(new Book("Luhmann, Niklas", "Soziale Systeme"));
        l1.addBook(new Book("Carle, Eric", "Die Raupe Nimmersatt"));
        l1.addBook(new Book("Dostojewski, Fjodor", "Schuld und Sühne"));

	//speichern
        try{
            File file = new File("buecher.ser");
            FileOutputStream fos = new FileOutputStream(file);
            ObjectOutputStream oos = new ObjectOutputStream(fos);

            oos.writeObject(l1);
            fos.close();
        }
        catch(Exception e){
            e.printStackTrace();
        }

        //laden
        try {
            FileInputStream fis = new FileInputStream("buecher.ser");
            ObjectInputStream ois = new ObjectInputStream(fis);

            l2 = (Library) ois.readObject();
            ois.close();
            System.out.println(l2);
        }
        catch (Exception e) {
            e.printStackTrace();
        }
        
    }
}

Später einmal soll der Nutzer im Hauptproramm folgende Möglichkeiten haben:
- eine neue (leere) Library erstellen.
- eine gespeicherte Library Laden.
- ein neues Buch erstellen.
- einer im Arbeitsspeicher vorhandenen Library ein Buch hinzufügen.
- eine im Arbeitsspeicher vorhandene Library speichern.

So, jetzt die eigentlichen Fragen:
Der Nutzer soll immer nur ein Buch und eine Library bearbeiten können. Deshalb ist es wohl sinvoll, daß es in der main-methode auch nur eine Referenz vom Typ Library und eine vom Typ Book gibt. Richtig???

Des weiteren erscheint es mir sinnvoll, das ganze Speichern und Laden von Library-Objekten (einschliesslich es Dialogs) in Methoden der Klasse Library zu verpacken - Beim Laden wäre gar ein Konstruktor Library(filename) denkbar. Darf/kann/sollte denn ein bereits bestehendes Objekt einen Konstruktor der eigenen Klasse aufrufen, um sich quasi selbst durch das neue Objekt, das dieser Konstruktor erzeugt zu ersetzen?!?!? Oder ist das eh totaler Murks?!

Leider weiß ich also weder, ob a) diese Designidee sinnvoll bzw. möglich ist und b) wenn ja wie man das umsetzen soll.

Ich verbleibe wie immer in der Hoffnung, mich verständlich ausgedrückt zu haben und verharre in gespannter Erwartung auf eure Antworten.

Danke jedenfalls schon mal dafür, bis hierher gelesen zu haben!

EDIT2: Vlt. sollte man eine Klasse schreiben, die ein Objekt der Klasse Library enthält und die ganzen Schreib- und Leseaufgaen einschliesslich der Dialoge uind Überprüfungen erledigt?!?!

 

[kirax]

Der Nutzer soll immer nur ein Buch und eine Library bearbeiten können. Deshalb ist es wohl sinvoll, daß es in der main-methode auch nur eine Referenz vom Typ Library und eine vom Typ Book gibt. Richtig???

Ist eine Möglichkeit. Aber warum immer nur 1 gleichzeitig? Wenn man z.B. was GUI-mäßiges draus macht, könnte es durchaus sinnvoll sein, mehrere gleichzeitig zu handlen. Ist auch kein großes Problem, einfach die Änderungsmethoden in Library bzw. Book schreiben (das ist dann schon guter Stil) und sich nicht drum kümmern im Code, was da grad für ein Objekt drinsteckt .

Beim Laden wäre gar ein Konstruktor Library(filename) denkbar. Darf/kann/sollte denn ein bereits bestehendes Objekt einen Konstruktor der eigenen Klasse aufrufen, um sich quasi selbst durch das neue Objekt, das dieser Konstruktor erzeugt zu ersetzen?!?!? Oder ist das eh totaler Murks?!

Nein. Das ist Murks. Wozu denn den Konstruktor aufrufen, wenn du schon ein Objekt hast? Das würde man eher über eine statische Methode regeln. Z.B. so:

public static Library loadFromFile(String filename) {
  ObjectInputStream ois = new ObjectInputStream(new FileInputStream(filename));  
  Library lib = (Library) ois.readObject();
  ois.close();
  return lib;
}

//auch denkbar:
public static Library[] loadManyFromFile(String filename) {
// ...
}

EDIT2: Vlt. sollte man eine Klasse schreiben, die ein Objekt der Klasse Library enthält und die ganzen Schreib- und Leseaufgaen einschliesslich der Dialoge uind Überprüfungen erledigt?!?!

Ja. Nenne sie anschließend Library Nein im Ernst, sowas gehört in die Klasse Library.
Aber welche Dialoge meinst du?

Edith meint grade: Ein Konstruktor Library(String filename) könnte Sinn machen, wenn in der Datei Bücherdaten liegen, mit denen die Library "initialisiert" werden soll:

public Library(String filename) {
  this(Book.loadManyFromFile(filename));
}

public Library(Book[] books) {
  for (Book b : books) {
    this.addBook(b);
  }
}

 

[nossek]

Guten Morgen,

danke kirax, jetzt wird es ja langsam interessant!

Also, die Botschaft ist angekommen: die Idee mit dem Konstruktoraufruf aus einem bestehenden Objekt heraus war nicht so gut - ich habs geahnt!

Ich sehe aber grad ein generelles Problem, was das laden von Library-Objekten (und von Objekten im allgemeinen) angeht:

Was ist eine Library?

Attribute:
- ein Array mit Books.
- sonstige Informationen über die Library
- Parameter die das Verhalten der Library steuern und kontrollieren,
zB. unsavedChanges
name/pfad der Datei, aus der zuletzt geladen wurde

Methoden:
- speichern
- laden
- Buch hinzufügen
- Buch entfernen
- sortieren, suchen etc…

Soweit klar, es sollen die Bücher gespeichert werden und die sonstigen Informationen. ABER: wenn Objekte der Klasse Library Attribute enthält, die das eigene Verhalten (u.a. speichern und laden) steuern und kontrollieren, dann werden diese Attribute ja ebenfalls gespeichert und geladen.

Das ist bei der derzeitigen minimal Version NOCH kein großes Problem
(nach dem laden eines Objekts der Klasse Library würde unsavedChanges false gesetzt: )

public static Library loadFromFile(String filename) {
    ObjectInputStream ois = new ObjectInputStream(new FileInputStream(filename)); *
    Library lib = (Library) ois.readObject();
    ois.close();
    lib.setUnsavedChanges(false);
    return lib;
}

Hmm, versteht ihr worauf ich hinaus will: Das Speichern und Laden von Attributen, die das eigene Verhalten steuern und kontrollieren könnte bei zunehmender Komplexität zu schwer nachvollziehbaren Fehlern führen.

Man könnte (und das hat kirax ja auch schon so ähnlich angedacht) statt der Library einfach die ArrayList mit den Books speichern. Sobald die Klasse Library aber mehr Attribute enthalten soll funktioniert das nicht mehr. (klar, langfristig wäre das ein Fall für eine Datenbank, aber soweit bin ich noch nicht)

Trotzdem: deshalb jetzt eine Klasse1 zu implementieren, die nur die Bücher und sonstigen Informationen zur Library enthält, und das ganze dann in eine Klasse2 zu packen die das Speichern und Laden erledigt ist ja wirklich nicht schön.

Also, es hilft wohl nichts, ich muss im Methodenrumpf von loadFromFile einfach gut aufpassen: die Books und sonst. Informationen werden stumpf aus der Datei geladen. Die "verhaltenssteuernden" Attribute müssen korrekt initialisiert werden. Simmt ihr diesen Überlegungen zu?

Kirax, Du fragtest noch was ich mit Dialog meine:

System.out.println("Bitte geben Sie den Namen der Datei ein, die sie öffnen wollen");
try{
filename = scanner.next();
...

(Bei professionellen Projekten gehört das wohl nicht in die Klasse Library?!)

 

[Murray]

Also, es hilft wohl nichts, ich muss im Methodenrumpf von loadFromFile einfach gut aufpassen: die Books und sonst. Informationen werden stumpf aus der Datei geladen. Die "verhaltenssteuernden" Attribute müssen korrekt initialisiert werden. Simmt ihr diesen Überlegungen zu?

Wenn Du diesen "verhaltenssteuernden" Attributen den Modifier transient verpasst, werden sie nicht serialisiert. Insofern hätte ein aus der Datei gelesenes Objekt bzgl. dieser Attribute die Default-Werte und nicht die der ursprünglich gespeicherten Instanz.

 

[Murray]

Des weiteren erscheint es mir sinnvoll, das ganze Speichern und Laden von Library-Objekten (einschliesslich es Dialogs) in Methoden der Klasse Library zu verpacken

Im Sinne der OOP liegt das nahe; es hat sich allerdings bewährt, sowohl die Persistenz-Funktionalität ( also das Laden und Speichern) und bes. das GUI in eigenen Klassen zu realisieren. Damit steht man besser da, wenn man später mal z.B. die Persistenz über eine Datenbank oder das GUI mit einem anderen Framework realisieren will. Außerdem fördert so einen Aufteilung die Testbarkeit.

 

[nossek]

Danke, Murray!

Wenn Du diesen "verhaltenssteuernden" Attributen den Modifier transient verpasst, werden sie nicht serialisiert. Insofern hätte ein aus der Datei gelesenes Objekt bzgl. dieser Attribute die Default-Werte und nicht die der ursprünglich gespeicherten Instanz.

Das hört sich guuut an!

es hat sich allerdings bewährt, sowohl die Persistenz-Funktionalität ( also das Laden und Speichern) und bes. das GUI in eigenen Klassen zu realisieren.

Hm, in dem Fall scheinst Du also eher anderer Ansicht zu sein als kirax, der ja meinte, zumindest die methoden zum speichern und laden von Librarys gehörten in die Klasse Library.

Ich werde weiter darüber nachdenken und probieren...

 

[kirax]

Es führen oft viele Wege zum Ziel Man muss dann immer schauen was im aktuellen Projekt gut ist.

Die Dialog-Geschichte sollte in eine extra Klasse.
Bei einem kleinen Projekt kann man sich an die Faustregel halten, Benutzerinteraktionen nur in der Main-Klasse zu machen. Wenns größer wird, macht man sich ein Main-Package, wo dann die Klassen Benutzerinteraktionen machen (Lokalitätsprinzip).
Eine Klasse sollte entweder die Abstraktion eines Objekts/Teilsystems sein (z.B. Library oder Book) oder den Kontrollfluss steuern und Benutzerinteraktion verwalten (z.B. Main). Nicht beides.

 

[nossek]

So, die Methode loadFromFile sieht jetzt so aus:

 public static Library loadFromFile(String filename){
        try {
            FileInputStream fis = new FileInputStream(filename);
            ObjectInputStream ois = new ObjectInputStream(fis);
            Library lib = (Library) ois.readObject();
            ois.close();
            return lib;
        }
        catch (Exception e) {
            return null;
}

Wenn ich im Hauptprogramm (oder in einer Klasse LibraryDialog) die Methode benutze, würde ich den Rückgabewert auf == null prüfen, und entsprechend weitermachen oder eben eine Fehlermeldung ausgeben und "zurück ins Hauptmenü" ("Was wollen sie tun? Library laden etc...)

ist das eine vernünftige Art, mit einem Fehler beim laden umzugehen?!?

EDIT: Ich bekomme auf diesem Weg ja nur die Info "hat nicht geklappt". Warum, sagt mir vermutlich die Excepiton ("file nicht vorhanden" oder "file ist keine Library").

Wenn ich also mehr wissen will muß ich wohl die Exception dort, wo loadFromFile(..) aufgerufen wird fangen?

EDIT2: könnte natürlich auch die Fehlermeldungsausgabe in die Methode loadFromFile(...) schreiben. Nur habt ihr mir ja plausibel gemacht, daß Nutzerinterakton nicht in die Klasse Library gehört.... Fragen über Fragen!

 

[kirax]

Hi

du kannst die Exception auch nach oben durchreichen:

public static Library loadFromFile(String filename) throws IOException {
    FileInputStream fis = new FileInputStream(filename);
    ObjectInputStream ois = new ObjectInputStream(fis);
    Library lib = (Library) ois.readObject();
    ois.close();
    return lib;
}

Und dann im Aufrufcode:

...
try {
  Library fromFile = loadFromFile(filename);
} catch (IOException e) {
  System.out.println("I/O Fehler aufgetreten: "+e.getMessage());
  e.printStackTrace(); // Standard Fehlermeldung auf System.err ausgeben
}
...

Das fängt nur IOExceptions. Generell sollte man nicht einfach "Exception" fangen, da das so gut wie "alles" ist und man merkt plötzlich u.U. nicht, dass plötzlich eine ganz andere Exception geflogen ist. Man kann natürlich den allgemeinen Fall auch noch abdecken:

...
try {
  Library fromFile = loadFromFile(filename);
} catch (IOException e) {
  System.out.println("I/O Fehler aufgetreten:");
  e.printStackTrace(); // Standard Fehlermeldung auf System.err ausgeben
} catch (Exception e) {
  System.out.println("Allgemeiner Fehler aufgetreten:");
  e.printStackTrace();
}
...

Exceptions kann man immer weiter bis ganz nach oben (main Methode) durchreichen. Generell hat man die Wahl, lokal zu behandeln oder durchzureichen.

 

[nossek]

Danke kirax!

Sowas in der Art hatte ich mir schon gedacht.

Mittlerweile funktioniert die erste Version von meinem Bibliotheksprogramm einschliesslich der Nutzerinterakton über die Konsole, allerdings ist der code letztlich ein ziemliches Durcheinander geworden

Ich fürchte ich muß mir zum lernen etwas noch einfacheres überlegen. Aller Anfang ist schwer!

 

[Ullenboom]

Kurz aufgefallen:

StringBuilder result = new StringBuilder(10000);
for(Book b : books){
result.append(b.toString() +"\n");
}
return result.toString();

Mit b.toString() +"\n" ruinierst du dir auch wieder die Performance. Besser:


StringBuilder result = new StringBuilder(10000);
for(Book b : books){
result.append(b).append('\n');
}
return result.toString();

Und statt 10000 einfach books.size() * GESCHÄTZEGRÖSSEEINESELEMENTS.

Für das Lesen/Schreiben bietet sich ein eigene Klasse an. Such im Internet mal nach dem Begriff DAO, dann bekommst du einige Anregungen.

Grüße

Christian

 

[nossek]

Danke für die Hinweise Christian.