Java IO Applikationen - Brauche Erklärungen :)

[mika]

Aloa euch allen

ich habe grade in der Schule einen Java Kurs und habe dazu mal ein paar Fragen:

1.) Wie runde ich Float Zahlen in Java auf eine angebbare Zahl von Nachkommastellen
so wie in delphi zum Beispiel mit dem quick and dirty strtofloat(floattostrf(VAR, ffFixed,15,2));

2.) wir schreiben zur zeit kleine programme nach dem EVA Prinzip und ich habe mir gedacht ich mache
mir eine kleine Vorlage wie diese

Delphi-Quellcode:

/*

  Standard Konstrukt um ein Programm zu erstellen das eine Eingabe entgegen-
  nimmt, eine Berechnung anstellt und eine Ausgabe veranlasst. Frei nach dem
  EVA Prinzip.
  
  Author:
  Datum der Erstellung:
  Zweck dieses Programms:

*/

// Die Klassen und Bibliotheken zur Ein- und Ausgabe implementieren
import java.io.*;

// Unsere Superklasse für unser Programm
public class /* Hier Name des Programms einsetzen */
{
  // Unsere Hauptprozedur die nach dem EVA Proinzip arbeitet
  public static void main(String args[]) throws IOException
  {
    // Als erstes erstellen wir einen Inputstreamreader der die
    // Hauptklasse eines Eingabeobjektes darstellt
    InputStreamReader isr = new InputStreamReader(System.in);
    
    // Danach erstellen einen spezifizierten Inputstream der
    // Eingaben der Tastatur entgegennehmen kann
    BufferedReader eingabe = new BufferedReader(isr);
    
    // Jetzt holen wir uns alle erforderlichen Eingaben vom Benutzer
    // wobei wir darauf achten das der Benutzer nur vernünftige
    // Eingaben machen kann.
    
     HIER BENUTZEREINGABEN EINFÜGEN
    
    // Jetzt erstellen wir aufgrund unserer Eingaben vom User eine
    // Berechnung die wir nachher ausgeben werden
    
    HIER BERECHNUNG ANSTELLEN
    
    // Hier unsere Ausgabe damit der User auch sehen kann was dieses
    // Programm alles tolles kann :)
    
    HIER BERECHNETE DATEN AUSGEBEN

  }  // Ende der Hauptprozedur unseres Programms
}  // Ende unserer Superklasse

nur bin ich mir jetzt nicht ganz so sicher ob ich die Java internen Sachen richtig dokumentiert habe,
nicht das ich nachher in der Klausur da Blödsinn drinstehen habe Ist das Richtig das ich das Hauptkonstrukt
Superklasse genannt habe und bei dem Inputreader was ich da drüber geschrieben habe und so?


3.) Gibt es eine gute Hilfe zu Java so wie die OH in Delphi??



Danke im voraus,
mika

[Sharky]

Hai mika,

ich sehe nicht so recht den Bezug zu Delphi.
Darum schiebe ich es mal nach Programmieren-Allgemein.

[mika]

hups,

hast recht, hab mich im forum vertan, sorry

[choose]

Hallo mika,

Zitat:

Ist das Richtig [...] was ich da drüber geschrieben habe [...]?

ich fände es etwas mühsam, Deinen Code Zeile für Zeile zu kommentieren. Deshalb werde ich hier einfach ein paar Stichworte aufführen, bei Sun oder im Netz allg findest Du mit Sicherheit ausreichend Infos.

• Packages werden importiert,
• Superklasse (eq Oberklasse) ist Begriff aus Vererbung nicht textueller Ersetzung,
• Klassenname vs. Programmname,
• Prozedur vs. Methode,
• BufferedReader dekoriert (siehe Stream-Tut bei Sun und Decorator Pattern im Gang of Four-Buch, GoF) Inputstream.

Darüber hinaus solltest Du, wenn Du eine "Vorlage" erstellst, die zu ändernden Teile, in Methoden auslagern, damit der grundlegende Teil "statisch" bleibt. In diesem Fall könntest Du wirklich Vererbung und das Template Methode Pattern (siehe GoF) verwenden.

Zitat:

Gibt es eine gute Hilfe zu Java so wie die OH in Delphi??

Ja, die API-Referenz bei Sun.

Zitat:

Wie runde ich Float Zahlen in Java auf eine angebbare Zahl von Nachkommastellen
so wie in delphi zum Beispiel mit dem quick and dirty strtofloat(floattostrf(VAR, ffFixed,15,2));

Sieh in der Referenz unter der Klasse Math nach und verwende ein ähnliches Konstrukt wie unter Delphi

Delphi-Quellcode:

  myFactor:= Power(10, ADigits);
  Result:= Round(myInt*myFactor)/myFactor;

[mika]

danke für die erklärungen, die tipps und den link

ich werde mir das ganze heute nachmittag mal ausführlich ansehen und mich
wieder hier melden, da ich grade noch in der schule bin

die änderungen an den kommentaren werde ich eintragen (und was dekoriert da genau bedeutet
werde ich mir nachher erstmal anlesen müssen da ich es zur zeit nicht verstehe). allerdings
kann ich mir dafür kein wirkliches template erstellen da das ganze ja nur für die schule ist
und unser lehrer uns erlaubt alle sourcen und dokus in der arbeit zu benutzen

und weil wir zur zeit immer das gleiche machen, nämlich das EVA Prinzip hab ich mir gedacht
ich mach mir n standard source den ich in der arbeit benutzen kann in dem ich nur noch die
aufgaben-spezifischen dinge einfügen muss


so ich meld mich heute nachmittag wieder



mfg, mika

[mika]

olla

so die api habe ich mir mal ein wenig angesehen und das scheint das zu sein was ich gesucht habe.
da ich leider kein download link gefunden habe hoffe ich mal das httrack die seite vernünftig runterlädt.

könntet ihr mir bitte trotzdem erklären was dekorieren bedeutet?




danke im voraus

mika

[choose]

Das Dekorierer-Muster (Decorator) stammt nicht von mir. Ich habe es in dem DesignPattern-Buch der Gang of Four (GoF) kennengelernt und versuche es hier in meinen Worten in Anlehnung an Dein Bsp zu beschreiben:

Häufig sollen Klassen um gewisse Funktionen erweitert werden. Recht häufig wird zu diesem Zweck die Vererbung von Klassen eingesetzt: Methoden werden überschrieben, in ihrer Sichtbarkeit verändert oder neue Methoden und Eigenschaften hinzugefügt.
Im Bsp der Streams gibt es nun für die Eingabe zB einen FileInputStream, mit dessen Hilfe Dateien eingelesen werden können.
Liest man aus ihm Byte für Byte, sollte eine Art Puffer implementiert werden, damit die Performance, gedrosselt durch den langsamen Zugriff auf den tertiären Datenspeicher, erträglich bleibt. Der unbedarfte OOP-Entwickler, könnte nun auf die Idee kommen, eine neue Funktionalität für die Pufferung zu implementieren, die er vielleicht über eine neue Eigenschaft (BufSize) zugänglich macht.

Nach einiger Zeit stellt man fest, das man von Zeit zu Zeit mit komprimierten Dateien arbeitet. Der Stream konnte erweitert werden, allerdings nur unter Zuhilfenahme einer Bibliothek von dritten, die das Programm vergrößert und in vielen Fällen nicht erwünscht ist, also: Neue Klasse, sagt der unbedarfte OOP-Entwickler. Man könnte nun die Klasse FileInputStream ableiten und die neue Funktionalität in den Erben FileInputDecompressStream implementieren, der den bisherigen Puffer und das Lesen aus Dateien erbt. Je nachdem, ob das Dekomprimieren gewünscht ist, wird die eine oder andere Klasse benutzt (siehe: Farbrik-Muster).
Die plötzliche Forderung, das auch mit Verschlüsselungen gearbeitet werden soll, ist weiter kein Problem, zwar binden wir hierzu erneut eine Bibliothek ein, was ebenfalls mitunter nicht gewollt ist, aber durch das Anlegen der weiteren Erben FileInputDecryptStream (entschlüssendes gepuffertes Lesen aus Dateien) und FileInputDecompressDecryptStream (entschlüsselndes gepuffertes Lesen aus Dateien, die komprimiert sind) bekommen wir auch das in den Griff.

Hier erkennt man vielleicht schon das Dilemma... Aber was passiert erst, wenn der Stream morgen zunächst Entschlüsselt und anschließend entpackt werden soll? Was, wenn die Quelle vom Dateizugriff in einen Netzwerkzugriff geändert werden soll? Was ist, wenn wir eine Protokollfunktion implementieren wollen? Und wie bekommen wir alle Bugs aus den immer komplizierter werdenden Klassen heraus?
Wollte man jede denkbare Kombination implementieren, würde die Anzahl der Klassen explodieren!

Eine gängige Lösung ist hier das Dekorierer-Muster (Quelle: GoF), das die Absicht hat, eine flexible Alternative zur Unterklassenbildung anzubieten, um Klassen zu erweitern.
Das Konzept stützt sich auf die in der OOP gängigen Ideen des Geheimnisprinzips und der Zuständigkeit:
Es gibt eine abstrakte Oberklasse, den InputStream, die lediglich abstrakte Methoden zum Lesen anbietet. Ein konkreter Erbe, zB der FileInputStream implementiert diese Methoden so, dass aus Dateien, ein anderer, zB der NetworkInputStream, realisiert sie, indem aus einer Netzwerkverbindung gelesen wird.
Die vorhin angesprochene Pufferung der Daten, ist für beide Streams interessant und ist im Wesentlichen nicht deren Aufgabe. Stattdessen implementieren wir einen BufferedInputStream, der weder aus einer Datei noch von der Tastatur oder dem Netztwerk liest, sondern von einem anderen, beliebigen InputStream (also zB ein FileInputStream, aber auch ein anderer BufferedInputStream selbst), auf den er eine Referenz inne hat. Er "umgibt" (wrapping) ihn sozusagen und "schmückt" oder "dekoriert" (decorates) ihn durch neue Funktionalität (hier: die Pufferung).

Und das ist im Wesentlichen schon das ganze Muster: Das äußere, ausschmückende Objekte heißt "Dekorierer" und hat dieselbe Schnittstelle wie das innere Objekt (weil sie eine gemeinsame Oberklasse haben und sich der Dekorierer ausschließlich auf die dort formulierte Schnittstelle beruft). Der Klient (der Programmierer) kann ihn also so benutzen, wie das dekorierte Objekt selbst (Transparenz).
Ein weiterer Dekorierer (DecompressInputStream) könnte nun einen Stream so dekorieren, dass die enthaltenden Daten entpackt werden. Dabei ist es egal, als welchem konkreten InputStream die Daten tatsächlich bezogen werden...

So ist eine beliebige Schachtelung möglich, während die Handhabung für den Entwickler vollständig transparent bleibt (eine Methode erwartet ein Exemplar von InputStream, der konkrete Typ und die Tatsache, er ggf andere Streams dekoriert, ist irrelevant), die Zuständigkeiten geklärt sind (jede Klasse hat genau eine Aufgabe), und ohne, dass es zu eine Explosion von neuen Unterklassen kommt oder man bei der Entwicklung von mit immer komplexeren "Gott-Klassen" die Nerven verliert.

Puh! Geschafft
Ich hoffe, dass ich Dir mit dieser Erklärung helfen konnte.

[mika]

hallo


danke für die ausführliche erklärung, wirklich sehr nett von dir!
und ich glaub ich habs jetzt auch ungefähr verstanden. ich werd
jetzt mal anfangen mich weiter mit Java und OOP auseinanderzusetzen




mfg, mika