public class TestPerson { public static void main (String args[]) { BufferedReader istdn = new BufferedReader (new InputStreamReader (System.in)); System.out.println("Also hier muss ein name rein"); String ineins = istdn.readLine(); System.out.println("Und hier der nachname"); String inzwei = istdn.readLine();
String vorname; String name; Person schoettle;
schoettle = new Person(); schoettle.setName (ineins); schoettle.setVorname (inzwei);
Guten Tag. Warum hat er ein Problem mit folgender Zeile?
String ineins = istdn.readLine();
mit der übernächsten auch.
[...]
Ich bin mir ganz sicher. Irgendwas mach ich falsch.^^
Schonmal in die Javadoc zur Methode BufferedReader.readLine geguckt? Die kann eine IOException werfen, daher muss der aufruf in einem try/catch Block stehen, wie es redfalcon unten auch gemacht hat. Wenn du Eclipse verwendest produziert dir die IDE den nötigen try/catch Block von selbst.
Im übrigen ist es völlig in Ordnung dort einen BufferedReader zu verwenden, der DataInputStream muss nicht unbedingt sein - im Gegenteil, die Methode
Schonmal in die Javadoc zur Methode BufferedReader.readLine geguckt?
Ja, und sie sagt mir, dass readLine einen String erstellt, der aus einer Zeile gelesen wird.
Is doch richtig oder? Also mehr bekommt man nicht raus.
Bei der Anwendung der API bin ich noch nich so sicher. Also die Aufzeichnungen.
Das kommt wohl hoffentlich noch, wenn man mit dem Programm mehr vertraut ist.
Ja, und sie sagt mir, dass readLine einen String erstellt, der aus einer Zeile gelesen wird.
Is doch richtig oder?
Das ist noch richtig, ja.
Zitat:
Zitat von Greeven
Also mehr bekommt man nicht raus.
Nein, das ist nicht mehr richtig.
Zitat:
Zitat von http://java.sun.com/j2se/1.5.0/docs/api/java/io/BufferedReader.html#readLine()
readLine
public String readLine()
throws IOException
Read a line of text. A line is considered to be terminated by any one of a line feed ('n'), a carriage return ('r'), or a carriage return followed immediately by a linefeed.
Returns:
A String containing the contents of the line, not including any line-termination characters, or null if the end of the stream has been reached
Throws:
IOException - If an I/O error occurs
Wenn eine Methode mit "Throws: ExeptionXYZ" spezifiziert ist, heißt das, sie KÖNNTE eine Exception des angegebenen Typs werfen. Will man also diese Methode verwenden, so muss man den Methodenaufruf in einem try/catch Block notieren.
Wenn du also notierst:
PHP-Code:
BufferedReader istdn = new BufferedReader (new InputStreamReader (System.in));
String ineins = istdn.readLine();
Wird dir eine ordentliche IDE das bemängeln, z.B. mit folgendem Kommentar:
wen man nun auf "surrond with try/catch Block" klickt, wird folgender korrekter Code produziert:
(ich stell mal nur die main() dar)
PHP-Code:
public static void main(String[] args) {
BufferedReader istdn = new BufferedReader (new InputStreamReader (System.in));
System.out.println("Also hier muss ein name rein");
try {
String ineins = istdn.readLine();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
Natürlich sollte man die Deklaration von "ineins" noch außerhalb des try machen, will man die Variable später weiter verwenden. z.B. so:
PHP-Code:
public static void main(String[] args) {
BufferedReader istdn = new BufferedReader (new InputStreamReader (System.in));
System.out.println("Also hier muss ein name rein");
String ineins = "";
try {
ineins = istdn.readLine();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
Wie man genau mit Exceptions und der JavaDoc umgeht, solltest du dir hier erlesen können:
Was bei Teles Ausführungen noch fehlt ist, dass Du mit dem "throws.." die Exeptionbehandlung nur weiter verschiebst.
Wenn Du hinter die Klasse ein "throws ... Exception" schreibst, musst Du diese Exception dann in der Methode abfangen in der Du die Methode aus der entsprechend definierten Klasse aufrufst.
Also wenn Du hast:
Code:
public class Test throws Exeption {
...
public void blubb(int y) {
...
}
}
Dann musst Du beim Aufruf diese trotzdem mit einem try und catch block abfangen:
Code:
...
public static void main(String[] args) {
Test x = new Test();
try {
x.blubb(3);
}
catch (Exception e) {
[Exception hier behandeln]
}
Um das zu vereinfachen kannst Du die Exception gleich in der Methode blubb abfangen:
Code:
public void blubb(int y)= {
try {
...
}
catch (Exception e) {
[Exception hier behandeln]
}
}
try und catch muss ich nicht verwenden. Das Programm von mir aus dem ersten Post funktioniert doch auch. Nur noch das throws Exception ran.
Ich nehme an, dass ich noch nicht genug weiß, um mir dir Frage selbst zu beantworten und es vielleicht sogar in der API nachlesen könnte.
Warum gibt es eigentlich verschiedene Varianten zum Einlesen?
In dem Buch, was ich grad lese habe ich jetzt diese Variante kennengelernt:
Zitat:
Scanner eingabe= new Scanner (System.in);
String NAME = eingabe.next();
try und catch muss ich nicht verwenden. Das Programm von mir aus dem ersten Post funktioniert doch auch. Nur noch das throws Exception ran.
Nein, musst du nicht. Deine main Methode wird ja schließlich von einer anderen Methode gerufen, welche die Fehlerbehandlung macht
Falls du das Kapitel über Exceptions nicht nicht hinreichend studiert hat: Man fängt SPÄTESTENS in der ersten Methode, welche das Programm startet (in diesem Fall die main) alle möglichen Exceptions ab und benahdelt diese entsprechend.
Man muss das nicht tun, man kann auch der aufrufenden Methode sagen "behandel diese Fehler, ich hab keine Lust", allerdings sollte man dort das die Fehlerbehandlung implementieren. Da aber die main selten von einer anderen Java Methode gerufen wird, ist dort Fehlerbehandlung angebracht.
Was passiert wenn man das nicht macht?
1. andere die das Programm lesen werden einen nicht für voll nehmen. Ein Program ohne Fehlerbehandlung (z.b. aussagekräftiges Logging) beenden zu lassen ist "Hello World" Stil von Anfängern.
2. Fehler rauschen an einem vorbei ohne das man eine Ahnung hat, dass diese passiert sind. zumindest ein printStackTrace sollte man schon verwenden, um wenigstens die Fehlerursache bestimmen zu können.
edit: Warum schreib ich das - Eon hat das doch 20 min vor deinem Post korrekt dargestellt. naja ...
Zitat:
Zitat von Greeven
Ich nehme an, dass ich noch nicht genug weiß, um mir dir Frage selbst zu beantworten und es vielleicht sogar in der API nachlesen könnte.
Warum gibt es eigentlich verschiedene Varianten zum Einlesen?
In dem Buch, was ich grad lese habe ich jetzt diese Variante kennengelernt:
import java.util.Scanner; noch dazu
Es gibt nicht in jedem Fall etwas vom stdin zu lesen, eventuell möchtest du andere Datenströme verwenden (z.B. eine named pipe oder was weiß ich den ausgabestrom eines anderen Programms), daher gibt es auch zeichenbasierte Einleseverfahren.
Was mir grad aufgefallen ist: Es heißt "throws IOException". Macht aber wohl keinen Unterschied.
Zitat:
1. andere die das Programm lesen werden einen nicht für voll nehmen. Ein Program ohne Fehlerbehandlung (z.b. aussagekräftiges Logging) beenden zu lassen ist "Hello World" Stil von Anfängern.
2. Fehler rauschen an einem vorbei ohne das man eine Ahnung hat, dass diese passiert sind. zumindest ein printStackTrace sollte man schon verwenden, um wenigstens die Fehlerursache bestimmen zu können.
Und genau diesen Hello World Stil habe ich. So weiß ich nicht, was IOException macht und ich solle es einfach überlesen und mit übernehmen. Wird dann später erklärt.
printStackTrace sagt mir jetz so spontan zum Beispiel gar nichts. Da es nicht von Vorteil ist alles, was man nicht kennt nachzuschlagen, und es wohl in einem späteren Kapitel noch erklärt wird, werde ich dies jetzt nicht tun.
Mein Fehler was, dass ich throws IOException vergessen habe und wenn ich irgendwann etwas über try, cath oder Exception lesen werde, dann habe ich dank (<-- dies ist ein Danke) eurer Erklärungen schon mal ein wenig Vorwissen.
naja - ich weiß ja nicht nach welchem buch du dir Wissen aneignest, aber ein Input/Output Stream Kapitel vor dem Exceptionhandling durchzukauen ist in meinen Augen schlichtweg Blödsinn. Der Grund? Nahezu alle I/O Methoden werfen Exceptions, mit denen man sich ZUMINDEST im Prinzip auskennen sollte.
Meine Emfpehlung daher: überspringe das Kapitel und gehe direkt zu Exceptionhandling.
Zitat:
Da es nicht von Vorteil ist alles, was man nicht kennt nachzuschlagen, und es wohl in einem späteren Kapitel noch erklärt wird, werde ich dies jetzt nicht tun.
Wo auch immer du das her hast, ich würde das nicht so machen.
Meine Empfehlung:
1. In der Javadoc nachschlagen was die Methode/Klasse macht und wofür sie da ist.
2. Das kurz notieren (selbst schreiben ist eine der besten Lernmethoden) was du nachgeschlagen hast
3. für später (das von dir beschriebene Kapitel) weglegen und im aktuellen Text weitermachen.
Man nennt das auch "Scheuklappen ablegen", um derzeit ggf. wichtige Fakten aufnehmen zu können.
Und um es nochmal zu wiederholen: ein "throws" an eine main zu notieren ist nicht nur schlecht, nein es ist grauenhaft, auch wenn der Compiler das erstmal frisst.
Du magst deinen Grund haben, aber als Anfänger scheint es mir gut so.
Man muss ja zugeben, dass Java am Anfang ziemlich trocken ist und man die ganze Zeit Sachen gesagt bekommt, welche man vllt zwar versteht, aber den Sinn so richtig nicht dahinter versteht.
Dass man dabei dann - ohne es zu erklären erstmal - dem Anfänger die Möglichkeit gibt, dass er wenigstens etwas eingeben kann finde ich gut.
(Es geht am Anfang ja erstmal darum zu verstehen, was das Programm macht)
So schreibt man erst Sachen wie
Zitat:
String str;
str = new String ("blabla");
und erst später dann:
Zitat:
String str = new String ("immernochblabla");
In Mathe ist es doch auch so, dass man erst einige Jahre später lernt, wie die Formeln für den Weg und die für die Geschwindigkeit zustandekommen und zusammenhängen.
Und alles nachschlagen ist anstrengend und Nerven aufreibend. Vor allem, da man dort dann meistens noch mehr erfährt, was man nicht weiß.
In der Javadoc nachschlagen find ich aber auch gut. (Wenn man sich damit abfindet nicht alles verstehen zu müssen)
Darauf wird auch immer wieder verwiesen.
Das soll es gewesen sein. Noch eine Frage zum Schluss: Kennt jemand Hero Quest?
Wenn das Ziel ist, ein Spiel mit graphischer Oberfläche zu erstellen, dann ist doch "Mensch ärgere dich nicht" für den Anfang gut oder?
"Mensch ärgere dich nicht" ist vielleicht nicht gerade das beste Spiel für den Anfang. Probier dich doch mal an "3 gewinnt" (Feld mit 3x3 Kästchen, Spieler, der 3 Stück nebeneinander bekommt hat gewonnen), das sollte recht einfach sein. Da ist es auch nicht schwer einen Netzwerkmodus hinzuzufügen, da es genügt Strings hin und her zu schicken; man muss nicht zwingend Objekte serialisieren.
Mensch ärgere dich nicht ist auch nicht undebedingt komplexer:
1. man benötigt in keiner Weise Serialisierung (auch nicht bei 3 gewinnt)
2. man benötigt für eine einfache Implementierung keine Netzwerkprogrammierung
Was man braucht:
1. Implementierung eines Würfels (sehr leicht)
2. Implemtneriung der GUI (das reine spielbrett->leicht, Darstellung von dynischen Objekten darauf-> mittel)
3. Implementierung eines Rundensystems mit Zügen (leicht bis mittel)
4. Implementierung des Regelwerkes und der begehbaren Pfade (mittel)
man kann sich das ganze Extrem vereinfachen, wenn man nicht einfach drauf los programmiert, sondern folgende Dinge beachtet:
1. Entwurf des groben Klassenaufbaus
2. Entwurf einer Ablaufsequenz (z.B. mittels Sequenzdiagrammen)
3. Definition aller nicht zu implementierenden Features (Schutz vor Ablenkung)
Hilfreich kann zudem sein, die Entwürfe einer erfahrenen Person zum Review zu geben, um frühzeitig "Fehlerkorrektur" betreiben zu können.
Darf ich mal drauf losbrainstormen? Danke sage jetzt nichts.
...
ok.
Zuerst stellt sich mir die Frage, was in der main-Methode alles reinkommt.
So wie ich das bis jetzt kenne, würde ich wie folgt anfangen:
Ich habe eine Klasse "Spieler" die Anzahl der maximal vier Spieler wird am Anfang gewählt (das Wählen findet in der main Methode statt). In der Klasse befindet sich die Farbe und sie erstellt vier Objekte der Klasse "Spielstein". Diese haben als Daten, die Nummer des Feldes auf, dem sie grad stehen. (Am Anfang ist das immer der gleiche Wert.)
Ach, zu den Feldern... das gibt es doch bestimmt einige Varianten, oder.
Eine Klasse "Feld". durchgehend nummeriert.
Für jeden Spieler müsste es eine Kette von Feldern geben. Beginnend dort, wo er anfängt und endend da, wo es aufhört. (Was für ein Satz)
Einige Felder überschneiden sich ja und einige wiederum nich.
Nachdem gewürfelt wurde, wird der Wert des Wurfes genommen und zu dem aktuellen Feld dazu addiert. Anschließend wird das Feld "angeschrieben" (wie nennt man das? aufgerufen?) und es gibt zurück, ob man drauf kann oder nich. (Spielsteine, die nicht dieselbe Farbe besitzen werden auf das Anfangsfeld zurückgesetzt)
Es ist also auf einem Feld, neben der Nummer, nur gespeichert, ob und wenn, dann welcher Spielstein draufsteht.
Also:
class Spielstein (Farbe, aktuelles Feld)
class Spieler (Farbe, welchen Spieler als nächstes aufrufen,die entsprechende Felderkette ,zugehörige Spielsteine)
class Felder (Nummer des Feldes, besetzt oder nicht besetzt)
GUI... davon hab ich noch keine Ahnung. Eine Vorstellung, aber bevor ich damit anfange, warte ich erstmal auf das Feedback.
Es gibt natürlcih noch einiges anderes, aber der Kern ist erstmal dargestellt.
Gruß Christian
PS.: Für den Würfel gibt es doch bestimmt eine Methode, welche einen zufälligen Wert von 1-6 zurückgibt oder?
Zuerst stellt sich mir die Frage, was in der main-Methode alles reinkommt.
je nachdem wie du es schreibst. Bei meinen GUI anwendungen stand meist nur der konstrierende Aufruf für das ganze GUI Geraffel drin, also ein Java typischer 3-4 Zeiler.
Zitat:
Zitat von Greeven
Ich habe eine Klasse "Spieler" die Anzahl der maximal vier Spieler wird am Anfang gewählt (das Wählen findet in der main Methode statt). In der Klasse befindet sich die Farbe und sie erstellt vier Objekte der Klasse "Spielstein". Diese haben als Daten, die Nummer des Feldes auf, dem sie grad stehen. (Am Anfang ist das immer der gleiche Wert.)
Die Objekte haben bei dir derzeit nur Attribute. Es fehlen noch ein paar Methoden, was man mit den so machen kann, z.B.
Spieler: würfle()
Spielstein: zieheVor(int Felder)
Spielstein: werdeGeschlagen()
Spielstein: schlage(Spielstein spielstein) [wobei so eine MEthode verdammt cheat-anfällig ist, besser wäre etwas unsichtbares aus sicht des schlagenden Spielteinst, also eher Spielstein au Feld -> Feld merkt Doppeltbesetzung und löst Schlagen von altem Stein aus]
Zitat:
Zitat von Greeven
Ach, zu den Feldern... das gibt es doch bestimmt einige Varianten, oder.
Eine Klasse "Feld". durchgehend nummeriert.
Für jeden Spieler müsste es eine Kette von Feldern geben. Beginnend dort, wo er anfängt und endend da, wo es aufhört. (Was für ein Satz)
Einige Felder überschneiden sich ja und einige wiederum nich.
Das wäre eine Möglichkeit (eigentlich mal gar nicht so dumm, könnte man auch nett aufmalen, als 4 parallel verlaufende Ketten.
Eine andere Möglichkeit wäre eine einzige Kette, nur dass die Felder unterschiedliche Typen haben (z.b. "normal", "startfeld für Spieler X", "Zielfeld für spieler X", "Kreuzungsfeld für spieler x".
Zitat:
Zitat von Greeven
Nachdem gewürfelt wurde, wird der Wert des Wurfes genommen und zu dem aktuellen Feld dazu addiert. Anschließend wird das Feld "angeschrieben" (wie nennt man das? aufgerufen?) und es gibt zurück, ob man drauf kann oder nich. (Spielsteine, die nicht dieselbe Farbe besitzen werden auf das Anfangsfeld zurückgesetzt)
1. du würdest z.B. eine Methode des Feldes aufrufen, die das macht.
2. Spielsteine, die die GLEICHE Farbe haben, werden nicht versetzt, sonst schlagen.
Zitat:
Zitat von Greeven
Es ist also auf einem Feld, neben der Nummer, nur gespeichert, ob und wenn, dann welcher Spielstein draufsteht.
siehe felddiskussion, man könnte noch zusätzliche Infos hinterlegen.
Zitat:
Zitat von Greeven
GUI... davon hab ich noch keine Ahnung. Eine Vorstellung, aber bevor ich damit anfange, warte ich erstmal auf das Feedback.
Es gibt natürlcih noch einiges anderes, aber der Kern ist erstmal dargestellt.
Das wird nochmal ein schöner Lernhappen. Aber für die logische Implementierung nicht unbedingt notwendig. Notfalls kann man das auch textuell implementieren und dann auf einem plan nachmalen und die gui später stricken.
Meine Empfehlung für GUIs: VE (Visual Editor) für Eclipse oder Netbeans.
Zitat:
Zitat von Greeven
PS.: Für den Würfel gibt es doch bestimmt eine Methode, welche einen zufälligen Wert von 1-6 zurückgibt oder?
Gibt es eigentlich hier ein Tool, mit welchem man das so schön machen kann wie in den Lehrbüchern (Mit Kästen, wo der Name, die Variablen und die Methoden drinstehen... und so ein Flussdiagramm)?
Oder einfach Text?
Was wird eigentlich bevorzugt? NetBeans oder Eclipse? Ich habe unterschiedliches gehört, aber die Personen kannten eigentlich immer nur eins. Das,was sie halt benutzen. Bei java.sun kann man sich Java mit NetBeans herunterladen (was ich auch gemacht habe). Von Eclipse hab ich da noch nichts gesehen.
Was sind die Vor- und Nachteile von den beiden (anscheinend am meisten verbreiteten) Entwicklungsumgebungen?
Tool: gibt es einige, von OOo über MS Visio bis IBM Rational Rose(?), Ich würd dir mal Omondo ans Herz legen. Kostenlos (die free edition) und eingier maßen gut in eine IDE integriert.
IDE: Eclipse ist offen und mit für fast allem mit Plugins ausrüstbar, Netbeans hat schon ne menge integriert, aber darüber hinaus - keine Ahnung.
Aufgrund meiner Anstellung benutze ich Eclipse für fast alles, sei es J2EE, Java, Java + GUI, Perl, PHP, IBM TPM Workflowentwicklung, XML Editor, CVS / Subversion client.
Guck dir einfach mal beide an und nimm für den Anfang was dir besser gefällt.
ich habe Beruflich sowohl mit Eclipse als auch mit Netbeans gearbeitet. Aber welche IDE besser ist, kann man nur selber entscheiden. Im Leistungsumfang unterscheiden sie sich nicht, beide sind kostenlos, für beide gibt es Plugins. Letztendlich ist es eine reine Geschmacksfrage, welche einem besser gefällt. Historisch gesehen hatte Eclipse immer die Nase vorne, aber Netbeans hat da viel Boden gutgemacht in letzter zeit. Gerade der Visuelle Editor ist verdammt geworden.
Gibt es eigentlich hier ein Tool, mit welchem man das so schön machen kann wie in den Lehrbüchern (Mit Kästen, wo der Name, die Variablen und die Methoden drinstehen... und so ein Flussdiagramm)?
Oder einfach Text?
Wenn es dir einfach nur um die Grafik an sich geht, und du keine Codeerzeugung brauchst, dann schau dir mal Dia an. Da gibts auch ein UML-Plugin für, womit du dann Fluss/Sequenz/Klassen/Objekt/whatever-Diagramme machen kannst.
Genau das hab ich die ganzen Zeit gesucht (also der Name vom Programm). Aber wenn man Visio gewöhnt ist bekommt man bei Dia:
Aber wenn man Visio net kennt ist es sicher recht sinnvoll. Der Vorteil von einem visuellen Tool, welches schon in die IDE eingebaut ist, liegt meist in der automat. Codeerzeugung.
![[Java] Was ist an der Zeile falsch?](https://www.tweakpc.de/forum/iconimages/programmiersprachen/java-was-ist-an-zeile-falsch_ltr.gif)
[Java] Was ist an der Zeile falsch? 
naja ...
Linear-Darstellung
