Problem mit BufferedReader.

[math.iso@live.de]

hallo liebe java-programmierer

ich bin heute auf was merkwürdiges ( für mich ) zugestoßen.

Ich hab vorher Konstruktoren kennen gelernt mit

String konstruktor = new String();

nun lerne ich ein Konstruktor : BufferedReader mit

BufferedReader file=new BufferedReader(new FileReader("Filet.txt"))

das hat mich irgendwie sehr verblüfft und würde gern so ein Konstruktor verstehen ,


Habt ihr paar Beispiele wie die Klasse ausehen muss ,damit ich ein Konstruktor dieses Schema:

new Konstruktor (new neuesKonstruktor ())

; mir klar machen kann ???

 

[Schandro]

anstatt

BufferedReader file=new BufferedReader(new FileReader("Filet.txt"))

kannst du auch

FileReader fr = new FileReader("Filet.txt")
BufferedReader file=new BufferedReader(fr);

schreiben. Macht genau dasselbe.

Erklärung: Der Konstruktor von BufferedReader erwartet ein Object von FileReader.[/code]

EDIT:

Zwei Beispielklassen:

class A{
   B myB;

   public A(B myB){
      this.myB = myB;
   }

   public void machWasMitDeinenVariablen(){
      myB.print();
   } 


}

class B{
   
   public B(){}

   public void print(){System.out.println("Hi");}
}

Erstellen würdest du A folgerichtig so:

new A( new B() );

 

[0x7F800000]

Ein Konstruktor der Klasse A konstruiert dir eine instanz der Klasse A.

Dafür kann dieser Konstruktor:
-eine instanz der Klasse B
-17 verschiedene double werte
-ein vierdimensionales array von doppeltverketteten listen mit instanzen der elemente C
...
-HashMap für elemete X auf Y
...
-5 kilo crack
-waffen
-fluchtfahrzeug
-und zu guter letzt nutten

verlangen.

Dann baust du dir diesen Konstruktor entsprechend:

public class A{
   // konstruktor mit vielen ansprüchen
   public A(B b, double[] siebzehnStueck, List<C>[][][][] array, ..., HashMap<X,Y> map, ... , Crack c, Waffe[] waffen, Fluchtfahrzeug fahrzeug, Nutte[] nutten){
      ...
   }
}

Der Konstruktor für der BufferedReader ist zum glück nicht so anspruchsvoll: da reicht schon eine einzige referenz auf irgendeinen InputStreamReader oder irgendsowas (siehe API...).

Wenn du dir dagegen einen Konstruktor für ein GridBagConstraints anschaust, dann stellst du fest: woohooo, was'n glück dass das Ding kein Fluchtfahrzeug verlangt: da werden tatsächlich 11-13 Parameter benötigt (deswegen benutzt es kein mensch^^)

 

[math.iso@live.de]

danke Schandro erst mal

@Andrey: ich hab nur chinesich verstanden ...


ich hätte noch eine frage ..

ich hab unter http://www.dpunkt.de/java/Referenz/Das_Paket_java.io/4.html (Java-Dokumentation API)

gelesen dass BufferedReader (Reader in) ,dass der Parameter ein Typ von Reader ist ,

was ich nicht verstehe ist warum klappt dieses Beispiel BufferedReader (new FileReader (...)) ,und FileReader ist total ein anderer Typ zum Vergleich Reader..?

 

[Schandro]

hehe,

das is das tolle an OOP:

Dein FileReader ist ein Reader. Er ist auch ein InputStreamReader und ein Object. Das liegt an der Vererbungskette:

java.lang.Object
extended by java.io.Reader
extended by java.io.InputStreamReader
extended by java.io.FileReader

(aus der API unter "Class FileReader" rauskopiert...)


FileReader kann also alles was ein Reader kann, und noch viel mehr. Deswegen akzeptiert der Konstruktor den FileReader auch als Reader, weil der FileReader eben alles kann was auch ein Reader können muss (natürlich in abgewandelter Form, wenn z.b. einige Methoden von Reader überschrieben werden)

EDIT:
Was dir Andrey mit seinen Post sagen wollte:
Ein Konstruktor kann verlangen was er will, und der Benutzer muss sich drum kümmern. Außerdem sind GridBagConstraints böse. (nicht ernst nehmen^^)

 

[0x7F800000]

Außerdem sind GridBagConstraints böse. (nicht ernst nehmen^^)

Doch doch, das ist sehr ernstzunehmen: die SIND böse!

 

[L-ectron-X]

Iwo, halb so wild.

 

[math.iso@live.de]

aber Der Filereader der im Parameter von Buffereader sich befindet ,kann nur die Datenfelder und die Methoden anwenden die durch das erben der Klasse Reader nicht verändert worden ist ,richtig ?

 

[Landei]

Richtig. BufferedReader erwartet "irgendeinen" Reader als Konstruktor-Argument, kann also nur die üblichen Reader-Methoden (und nichts zusätzliches von FileReader) verwenden. Man kann aber durchaus "schummeln":

//fiktiver BufferedReader-Konstruktor
BufferedReader(Reader reader) {
  if(reader instanceof FileReader) {
     FileReader fileReader = (FileReader) reader;
     //verwende FileReader 
  } else {
     //verwende Reader
  }
}

 

[math.iso@live.de]

das heißt dann aber auch Landei , dass das Programm an Stelle

BufferedReader file=new BufferedReader(new FileReader("Filet.txt"))

auch

 BufferedReader file=new BufferedReader(Reader "Filet.txt")

stehen könnte und somit den gleichen Effekt bzw



Sinn erzielen würde oder..?

 

[Landei]

Nein. Reader sagt nur aus, dass die Klasse bestimmte Methoden - hier z.B. read() - implementieren muss. Wie sie die implementiert, ist Sache der jeweiligen konkreten Klasse (FileReader, StringReader), d.h. wen du ein FileReader.read aufrufst, komm etwas anderes heraus als bei StringReader.read. Im Übrigen kann Reader gar nicht konstruiert werden, es ist nur ein Interface, hat also keinen Konstruktor.

BufferReader interessiert sich nicht dafür, wie read im übergebenen Reader implementiert ist, es benutzt es einfach für seinen eigenen Zwecke (Bereitstellung eines Lese-Puffers). OO funktioniert nach dem BlackBox-Prinzip: "Ich weiß, was das Ding macht, mir ist völlig egal, wie es das macht".

So eine ähnliche Diskussion hatten wir grade: http://www.java-forum.org/de/viewtopic.php?t=80220&highlight=mammal