I/O Code Gerüst vorgegeben

[ocsme]

Hallo zusammen,

nervig ich weiß doch ich hab wieder ein Stück Code vorgegeben bekommen und Fragezeichen im Kopf

Das ganze sieht so aus:

Interface ReadStream<T> {
    T read();
}

Interface WriteStream<T> {
    void write(T object);
}

class IOStream<T> implements ReadStream<T>, WriteStream<T> { ... }

Ihre Aufgabe ist, unter Verwendung des jeweils geeigneten der drei oben angegebenen Typen, eine Klasse ReadOnly und eine Klasse WriteOnly zu erstellen.
Nur Leseoperationen und Schreiboperationen für Strings

Meine Idee wäre so etwas in der Art.
Doch ich denke das ist wieder zu kurzsichtig gedacht oder
(Nur mal für ReadOnly class!)

class ReadOnly {
    IOStream<String> ios = new IOStream<>("Dateipath");
    
    String read() {
        return (String) ios.read();
    }
}

Ich weiß diese Aufgabe lässt auch wieder eine Frage offen da die IOStream<T> ja nicht gecodet wurde!

LG

 

[temi]

Vielleicht etwa in der Art:

class ReadOnly implements ReadStream<String>

Ein sinnvoller Konstruktor wäre auch wünschenswert.

 

[mrBrown]

Ich weiß diese Aufgabe lässt auch wieder eine Frage offen da die IOStream<T> ja nicht gecodet wurde!

Das ist für die Aufgabe egal - das ist nur ein Interface und gegen das Interface solltest du implementieren


Unklar ist eher, wie die Klassen ReadOnly und WriteOnly aussehen sollen. Steht da nicht mehr dazu? In die richtige Richtung könnten beide Varianten hier gehen....

 

[ocsme]

Vielleicht etwa in der Art:

class ReadOnly implements ReadStream<String>

Das dachte ich auch zuerst doch dann müsste man ja die read() Methode selbst schreiben. Wenn ich ja eine Klasse habe die das Interface ReadStream<T> Implementiert muss das dort ja implementiert sein deswegen habe ich mich so entschieden.

Unklar ist eher, wie die Klassen ReadOnly und WriteOnly aussehen sollen. Steht da nicht mehr dazu? In die richtige Richtung könnten beide Varianten hier gehen....

Bei den Klassen stehen noch 2 Kommentaren hier mal was dort steht

class ReadOnly {
    //Definieren Sie eine Variable eingabe zum Lesen von Strings
    ...  <- soll unser Programmcode hin
    
    //Hier Methode zum Lesen einfügen
    ...
}


class WriteOnly {
    //Definieren Sie eine Variable ausgabe zum Lesen von Strings
    ...  <- soll unser Programmcode hin
    
    //Hier Methode zum Schreiben einfügen
    ...
}

 

[temi]

doch dann müsste man ja die read() Methode selbst schreiben.

Die read-Methode hast du doch oben schon hingeschrieben...

Edit: Aber, da das Gerüst der Klasse "ReadOnly" oben bereits ohne "implements ReadStream<String>" angegeben ist, ist dein Ansatz wohl nicht ganz falsch.

Edit: Noch mal zum Implementieren des Interfaces. Genau das hast du ja gemacht, indem du in eine Methode mit der zum Interface passenden Signatur Code geschrieben hast, der das tut, was du möchtest.die Methode verlangt.

 

[temi]

Definieren Sie eine Variable eingabe zum Lesen von Strings

Du könntest z.B. deine Variable "ios" in "eingabe" umbenennen.

 

[mrBrown]

Und neben dem umbenennen: du sollst den geeignetsten Typ nutzen, und wenn du nur lesen musst ist das ....?

 

[ocsme]

Naja meine Frage ist eigentlich eher die wieso ünnötig 2x das gleiche schreiben?

Wenn doch die Klasse IoStream die Interfaces implementiert dann stehen dort die Methoden zur Verfügung ich kann eine Instanz dieser Klasse erzeugen und diese Methoden nutzen oder habe ich dabei erneut ein Denkfehler und übersehe eben etwas das war die Frage

Denn andernfalls sollte das doch so gehen wie ich es oben geschrieben habe. Jetzt mal der Name der Variable außer acht gelassen. Denn andernfalls müsste man die T read() Methode selbst schreiben dabei könnte man ja den FileReader nutzen und immer 1 String lesen

 

[temi]

Naja meine Frage ist eigentlich eher die wieso ünnötig 2x das gleiche schreiben?

Was meinst du damit?

Wenn doch die Klasse IoStream die Interfaces implementiert dann stehen dort die Methoden zur Verfügung ich kann eine Instanz dieser Klasse erzeugen und diese Methoden nutzen

Ja, das ist korrekt.

Denn andernfalls müsste man die T read() Methode selbst schreiben

Hättest du es so gemacht, wie ich in #2 geschrieben habe, dann hätte es genau deiner bereits gezeigten Implementation von read() entsprochen. Musst du aber nicht, wie wir aufgrund der Vorgabe (der Klassengerüste) gesehen haben.

Ich zitiere mich mal selbst:

Noch mal zum Implementieren des Interfaces. Genau das hast du ja gemacht, indem du in eine Methode mit der zum Interface passenden Signatur Code geschrieben hast, der das tut, was die Methode verlangt.

 

[ocsme]

Achso, weil ich ja eh die read() Methode implementiere kann ich die Klasse implements Interface schreiben obwohl ich Intern die andere Klasse benutze und die meine Arbeit macht. So also:

class ReadOnly implements ReadStream<String> {
    IOStream<String> eingabe = new IOStream<>("Dateipath");
    
    String read() {
        return (String) eingabe.read();
    }
}

 

[temi]

Achso, weil ich ja eh die read() Methode implementiere kann ich die Klasse implements Interface schreiben obwohl ich Intern die andere Klasse benutze und die meine Arbeit macht.

Genau so ist es. Du solltest dich allerdings an die vorgegebene Klasse halten und das "implements.." wieder entfernen.

Beachte noch den Hinweis von @mrBrown in #7 und mach einen sinnvollen Konstruktor, der dieses unschöne "Dateipath" beseitigt.


Edit: Ein Tipp von mir: Verwende beim Überschreiben/Implementieren von Methoden immer "@Override". Damit stellst du sicher, dass du auch tatsächlich die korrekte Signatur geschrieben hast. Im Fehlerfall würdest du eine Meldung vom Compiler erhalten. Außerdem zeigt es sofort, dass man hier eine Methode vor sich hat die überschrieben wird/ein Interface implementiert.

 

[temi]

class ReadOnly implements ReadStream<String> {
    IOStream<String> eingabe = new IOStream<>("Dateipath");
   
    String read() {
        return (String) eingabe.read();
    }
}

Noch was: Schau dir mal deine Deklaration von "eingabe" an und das Interface "ReadStream". Welchen Typ liefert demnach die Methode eingabe.read() zurück?

 

[ocsme]

Noch was: Schau dir mal deine Deklaration von "eingabe" an und das Interface "ReadStream". Welchen Typ liefert demnach die Methode eingabe.read() zurück?

T also String

Beachte noch den Hinweis von @mrBrown in #7 und mach einen sinnvollen Konstruktor, der dieses unschöne "Dateipath" beseitigt.

Ja das mach ich

Edit: Ein Tipp von mir: Verwende beim Überschreiben/Implementieren von Methoden immer "@Override". Damit stellst du sicher, dass du auch tatsächlich die korrekte Signatur geschrieben hast. Im Fehlerfall würdest du eine Meldung vom Compiler erhalten. Außerdem zeigt es sofort, dass man hier eine Methode vor sich hat die überschrieben wird/ein Interface implementiert.

achso @Override hat eine bedeutung ich lösche das immer weg :O das macht natürlich Sinn

 

[ocsme]

public class ReadOnly {
    
    IOStream<String> eingabe;
    
    ReadOnly() {
        eingabe = new IOStream<>();
    }
    
    ReadOnly(File f){
        eingabe = new IOStream<>(f);
    }
    
    @Override
    String read() {
        return eingabe.read();
    }

}



public class WriteOnly {

    IOStream<String> ausgabe;

    WriteOnly() {
        ausgabe = new IOStream<>();
    }
    
    WriteOnly(File f){
        ausgabe = new IOStream<>(f);
    }
    
    @Override
    void write(String s) {
        ausgabe.write(s);
    }
}

 

[mrBrown]

Und wenn IOStream nur den Konstruktor private IOStream(int i, float f, boolean b, List<String> strings, Void v) hat?
Hint: ein Konstruktor, den du nicht kennt, kannst du nicht aufrufen - und in der Aufgabe wird keiner vorgegeben Oder hast du das unterschlagen?

 

[ocsme]

Ich könnte WEINEN wieso denke ich nie an so etwas?

Und wenn IOStream nur den Konstruktor private IOStream(int i, float f, boolean b, List<String> strings, Void v) hat?

Natürlich hast du vollkommen recht.

Darf man davon ausgehen das das Interface wie die Klasse hier:

ReadStream

www.cs.williams.edu

benutzt werden kann.
Dann wäre ReadStream<T> ja mit InputStream überladen und man könnten diesen nutzen?
Oder ist das nun auch wieder ein Denkfehler

Wie behält man nur der Durchblick bei so vielen Klassen? Und dabei habe ich noch nicht mal angefangen mit GUI / JavaFX. Das sind dann ja gleich wieder ca. 1000 Klassen dazu

LG

 

[mrBrown]

Darf man davon ausgehen das das Interface wie die Klasse hier:
ReadStream benutzt werden kann.
Dann wäre ReadStream<T> ja mit InputStream überladen und man könnten diesen nutzen?
Oder ist das nun auch wieder ein Denkfehler

Ja, ist ein Denkfehler. Du darfst nur von dem Code ausgehen, der oben steht.

Und deine Lösung von oben war sehr nah an der Richtgen Lösung.

Wie behält man nur der Durchblick bei so vielen Klassen? Und dabei habe ich noch nicht mal angefangen mit GUI / JavaFX. Das sind dann ja gleich wieder ca. 1000 Klassen dazu

Von denen man im Endeffekt nur ein paar weniger Klassen im alltäglichen Gebrauch nutzt - und die Doku gibts ja nicht ohne Grund.


Viel wichtiger ist, die Konzepte dahinter zu verstehen, so wie in diesem Fall mit grad mal drei vorgegebenen Klassen.

 

[temi]

Ein Tipp von mir: Verwende beim Überschreiben/Implementieren von Methoden immer "@Override". Damit stellst du sicher, dass du auch tatsächlich die korrekte Signatur geschrieben hast. Im Fehlerfall würdest du eine Meldung vom Compiler erhalten. Außerdem zeigt es sofort, dass man hier eine Methode vor sich hat die überschrieben wird/ein Interface implementiert.

Ich muss mich noch einmal zitieren, mit einem Hinweis:

Die beiden Klassen deiner Lösung erweitern ("extends") keine andere Klasse und implementieren auch kein Interface. Damit ist die Methode "read()" einfach nur eine Methode, die mehr oder weniger zufällig so heißt, wie die Methode im Interface. In diesem Fall solltest du vom Compiler einen Fehler erhalten, weil du ihm mitteilst, dass du eine Methode überschreiben möchtest, dies aber tatsächlich nicht der Fall ist.

 

[temi]

IOStream<String> eingabe;

Ist "IOStream" tatsächlich der geeignetste Typ, wenn du nur Lesen möchtest?

Das gilt analog auch für die Klasse WriteOnly...

 

[ocsme]

Mir fällt nichts besseres ein als das von oben.
Hab es mal nur über einen BufferedReader versucht. Dann sollte zwar der Konstruktor stimmen doch dann macht es im Sinne der Aufgabe sicherlich keinen Sinn mehr

import java.io.*;

public class ReadOnly {
    
    BufferedReader eingabe;
    
    ReadOnly() throws IOException  {
        eingabe = new BufferedReader(new FileReader(""));
    }
    
    ReadOnly(String path) throws IOException {
        eingabe =  new BufferedReader(new FileReader(path));
    }
    
    String read() throws IOException {
        return eingabe.readLine();
    }

}

Desweiteren gebe ich ja auch eine ganze Line zurück was nun mit 1em String gemeint ist ?

Danke trozdem nochmals

LG

 

[mrBrown]

An deiner ersten Lösung musst du nur minimal was anpassen, damit die richtig ist.
Du hast drei Typen - ReadStream, WriteStream und IOStream - und du musst nur Lesen: welches ist dann der geeignete Typ?



Die BufferedReader-Variante hat dagegen nichts mit der Aufgabe zu tun.

 

[temi]

Mach es nicht unnötig kompliziert. Die drei Typen aus deinem ersten Beitrag reichen vollkommen aus und die Lösung aus #14 ist fast korrekt.

Spoiler

Du kannst als Typ für eine Variable auch ein Interface angeben.

 

[ocsme]

public class ReadOnly {
    
    ReadStream<String> eingabe;
    
    ReadOnly() {
        eingabe = new IOStream<>();
    }
    
    ReadOnly(File f){
        eingabe = new IOStream<>(f);
    }
    
    @Override
    String read() {
        return eingabe.read();
    }

}

Doch das Problem mit dem Konstruktor bleibt doch gleich. Ich weiß ja immer noch nicht wie IOStream<>() aufgerufen werden sollte.

 

[mrBrown]

Ich weiß ja immer noch nicht wie IOStream<>() aufgerufen werden sollte.

In dieser Klasse? Gar nicht.

Du brauchst einen ReadStream<String>, also lass dir einen ReadStream<Stream> geben.

 

[temi]

Doch das Problem mit dem Konstruktor bleibt doch gleich. Ich weiß ja immer noch nicht wie IOStream<>() aufgerufen werden sollte.

Da keine näheren Angaben vorliegen, würde ich vom parameterlosen Konstruktor ausgehen.

 

[mrBrown]

Da keine näheren Angaben vorliegen, würde ich vom parameterlosen Konstruktor ausgehen.

Ich würde von gar keinem Konstruktor ausgehen...

 

[ocsme]

Also reicht das:

public class ReadOnly {
    
    ReadStream<String> eingabe = new IOStream<>();;
    
    @Override
    String read() {
        return eingabe.read();
    }

}

 

[mrBrown]

Ich würde noch erwarten, dass man auf das Instanzieren des IOStreams verzichten soll...

 

[thecain]

und das @Override ist so falsch

 

[ocsme]

Das soll alles dann sein? :?

public class ReadOnly {
    
    ReadStream<String> eingabe;
    
 
    String read() {
        return eingabe.read();
    }

}

 

[temi]

Ich würde noch erwarten, dass man auf das Instanzieren des IOStreams verzichten soll...

Das soll alles dann sein? :?

Ich hoffe ich liege richtig mit dem was @mrBrown meint. Such mal nach dem Stichwort "Constructor Injection"

Edit: Und mach dir noch kurz Gedanken zum Thema Sichtbarkeit von Feldern und Methoden.