Java IO Applikationen - Brauche Erklärungen :)
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:
nur bin ich mir jetzt nicht ganz so sicher ob ich die Java internen Sachen richtig dokumentiert habe,
/*
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 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 |
Re: Java IO Applikationen - Brauche Erklärungen :)
Hai mika,
ich sehe nicht so recht den Bezug zu Delphi. Darum schiebe ich es mal nach Programmieren-Allgemein. |
Re: Java IO Applikationen - Brauche Erklärungen :)
hups,
hast recht, hab mich im forum vertan, sorry :) |
Re: Java IO Applikationen - Brauche Erklärungen :)
Hallo mika,
Zitat:
Zitat:
Zitat:
Delphi-Quellcode:
myFactor:= Power(10, ADigits);
Result:= Round(myInt*myFactor)/myFactor; |
Re: Java IO Applikationen - Brauche Erklärungen :)
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 :dancer: 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 |
Re: Java IO Applikationen - Brauche Erklärungen :)
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 :dp: mika |
Re: Java IO Applikationen - Brauche Erklärungen :)
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. |
Re: Java IO Applikationen - Brauche Erklärungen :)
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 |
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:25 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz