Java Standard/Archiv
Dies sind Archivierte Diskussionstoffe zum J.SE von Java.
Navigation
BearbeitenHallo - ich schlage vor die Standardnavigation zu benutzen.
- {{Navigation_zurückhochvor_buch| zurücklink =Perl-Programmierung: Das Richtige für mich| zurücktext =Das Richtige für mich?| hochlink =Perl-Programmierung| hochtext =Inhaltsverzeichnis| vorlink =Perl-Programmierung: Geschichte| vortext =Geschichte einer Skriptsprache }}
Als Alternative wären natürlich schöne "Java"-Bilder möglich. Ich hätte es nur gerne in allen Java Büchern gleich. mfg --Bastie 17:55, 16. Mai 2005 (UTC)
- Alles klar - ist jetzt für "Java Standard" erledigt - wie es in den anderen Büchern aussieht weiss ich nicht - vielleicht finde ich ja mal Zeit und lust um es dort auch geradezuziehen. --Lesath 08:55, 20. Jul 2005 (UTC)
Kapitel "Der Einstieg"
BearbeitenIch bin dafür die drei Unterkapitel des ersten Kapitels "Der Einstieg" als eigenständige Kapitel zu gestalten. So wie sich das Inhaltsverzeichnis bisher entwickelt hat, ist es IMO eher sinnvoll.--Aler 16:22, 8. Mai 2005 (UTC)
- Ist ok, auf jeden Fall. Mache ich gleich mal :-) --Underdog 14:14, 9. Mai 2005 (UTC)
Populäre Java Projekte
BearbeitenZusätzlich habe ich noch ein Kapitel namens "populäre Java-Projekte" eingefügt. Hier werden eben bekannte Java-Projekte kurz vorgestellt. So kann der Leser/ Lernende direkt mal in ein großes Projekt reinschauen und sehen, dass alle nur mit Wasser kochen. Ich habe jetzt mal zwei Programme eingefügt, "Art of Illusion" für Grafikinteressierte und "JEdit" fürs Allgemeinwissen. Über die Sinnhaftigkeit des Kapitels bin ich mir selber nicht so sicher?? Würde Euch die Vorstellung von solchen Programmen zum Eigenprogrammieren motivieren? --Aler 18:43, 23. Apr 2005 (UTC)
- Schlage vor den kompletten Absatz zu löschen! Die Links können an geeigneten Stellen gerne untergebracht werden aber als Kapitel IMHO ungeeignet. --Bastie 12:55, 30. Apr 2005 (UTC)
- Ist gemacht. Können wir uns ja ggf. noch überlegen, ob es einen geeigneten Ort gibt --Aler 7:56, 3. Mai 2005 (UTC)
Neues Inhaltsverzeichnis
BearbeitenIch habe jetzt mal eine erste Fassung eines neuen Inhaltsverzeichnisses eingestellt. Es beinhaltet zunächst jedoch nur die ersten grundlegenden Kapitel. Viele bestehende Kapitel sind noch gar nicht drin, weshalb ich das alte Inhaltsverzeichnis zunächst unverändert darunter habe stehen lassen. Ansonsten gehen am Ende noch Kapitel verloren...
Verbesserungen und v.a. Erweiterungen wären jetzt natürlich schnell angebracht, damit wir in Kürze erst mal eine ordentliche Struktur haben. Ich finde das sollten wir möglichst vorab festlegen, bevor schon viel an den einzelnen (neuen) Kapiteln gearbeitet wird. Einige Kapitel aus dem alten "Einstieg" habe ich z.T. noch weggelassen, weil ich mir nicht sicher bin, worunter man sie in dem neuen Inhaltsverzeichnis am besten unterbringen sollte. Ich habe da noch nach einem passenden Namen für ein weiteres "Überkapitel" (entsprechend Einleitung, Grundlagen, OO) gesucht, aber mir ist nix passendes eingefallen. Hat einer 'ne gute Idee? --Underdog 00:57, 22. Apr 2005 (UTC)
- Habe das Inhaltsverzeichnis größtenteils mit den von Bastie in der Diskussion vorgestellten Themen erweitert.
- Habe die noch nicht zugeordneten Kapitel in das neue Verzeichnis eingetragen, wie ich das mal gedacht habe. Mathematik in Java habe ich rausgelassen, dass können wir vielleicht einfach in Operatoren miteinfliessen lassen, oder aber ein ausführlicheres Kapitel daraus machen, welches dann auch auf die Math-Klasse eingeht. --Aler 18:58, 23. Apr 2005 (UTC)
- Nochmals neue Kapitel zusammengesucht:
- Dateiverarbeitung - ist so essentiell, dass ich die bis hier schon vergessen hatte.
- Bilder - sicherlich interessant
- Nützliche Werkzeuge - Die Klasse java.util - Kann Collection Framework, StringTokenizer u.a. enthalten --Aler 19:05, 23. Apr 2005 (UTC)
Aufbau eines Kapitels
BearbeitenIn neuen Lehrbüchern gibt es zu Anfang eines Kapitels meist eine Übersicht der Lehrziele und am Ende ein paar Kontrollfragen. Sollen wir das hier auch einführen? Mich unterstützt es schon ganz gut beim Lernen... --Aler 16:09, 20. Apr 2005 (UTC)
- "Lernziele" ist OK (Begriff finde ich noch unschön) mir wäre eher eine Art "Kapitelüberblick" lieber. Kontrollfragen würde ich eher auslagern wollen in einen separaten Anhang. --Bastie 06:20, 21. Apr 2005 (UTC)
- Meinetwegen kann es auch "Kapitelüberblick" heissen. Die Kontrollfragen sollten jedoch nicht am Ende des Buches stehen, sondern nah an dem Lernstoff. Sonst wird der Leser die Aufgabe sowieso nicht machen--Aler 08:50, 21. Apr 2005 (UTC)
Verantwortlichkeiten
BearbeitenVerantwortlichkeit heist nicht, dass derjenige einen Abschnitt allein schreibt sondern nur dass je nach Interessenlage ein bisschen intensiver über den Inhalt geschaut wird. Wenn DU also irgendwo einen Beitrag hast dann schreibe Ihn hin!!!
Hi, sollen wir mal klare Verantwortlichkeiten für die verschiedenen kapitel verteilen? Ich weiss zwar noch welche ich geschrieben habe, und somit auch dafür verantworlich bin, aber vielleicht sollten wir es trotzdem mal aufteilen. Dann können wir vielleicht auch besser Fortschritte erkennen. Denn wenn ich so in das Buch reingucke, bin ich mir nie so ganz sicher was neu ist. --Aler 16:08, 20. Apr 2005 (UTC)
Dementsprechend also
- Einleitung
- Einrichten der Programmierumgebung
- Erste Schritte
- Schlüsselwörter
- Operatoren - Aler
- Objekte
- Fehlerbehandlung
- Einfache Mathematik in Java
- Das ist ein Kapitel was ich sowieso eher verwerfen würde. Wenn wir ein Spezialthema Mathematische Algorthmen in Java hätten OK aber so ... --Bastie 06:26, 21. Apr 2005 (UTC)
- Das könnte man eventuell noch mit bei den Operatoren (die zur Zeit sowieso nur rudimentär vorhanden sind mit verwursten... Nur so eine Idee... --Lesath 08:59, 20. Jul 2005 (UTC)
- Das ist ein Kapitel was ich sowieso eher verwerfen würde. Wenn wir ein Spezialthema Mathematische Algorthmen in Java hätten OK aber so ... --Bastie 06:26, 21. Apr 2005 (UTC)
- Strings ver- und bearbeiten
- Vererbung - Aler
- Programmierstil -Aler
- Grafische Oberflächen
- Bilder - Wenn dieses "Teilkapitel" noch nicht vergeben ist, würde ich gerne einige Worte über Graphics(2D) resp. über die Java2D verlieren. --Nauron
- Swing
- Muster (engl. Pattern) - Aler
- Singleton
- IMHO grds. fertig --Bastie 06:26, 21. Apr 2005 (UTC)
- Schablonenmethode
- IMHO grds. fertig --Bastie 06:26, 21. Apr 2005 (UTC)
Bei der Umstruktuierung, die ja auch demnächst kommen wird, können die Verantwortlichkeiten nochmal geklärt werden. Auch übernehme ich gerne noch andere Kapitel. Welche würdet Ihr den übernehmen?
Diese Verantwortlichkeit meine ich nicht ausschließlich, ist ja vollkommen gegen das wiki-Prinzip. Aber das so eine rein stilistische Überprüfung eines Themas eben direkt einem Redakteur (kann man uns so nennen) zugewiesen wird. --Aler 16:30, 20. Apr 2005 (UTC)
- Wäre dafür, erst mal ein neues Inhaltsverzeichnis so weit wie möglich festzuklopfen, sonst muss das alles zweimal gemacht werden. Grundsätzlich ist das aber ne prima Idee, finde ich. --Underdog 00:57, 22. Apr 2005 (UTC)
Name des Buches
BearbeitenHallo,
mal eine Frage: Was soll der Name "Programmierkurs" Java. IMHO unterscheidet sich ein Programmierkurs doch sehr von einem Buch. Schon der Aufbau ist m.E. anders geartet, da ein Kurs (meistens) von vorn nach hinten durchgearbeitet wird, während ein Buch aus in sich abgeschlossenen Kapiteln besteht. Ich rege daher an dass ganze auf Java zu beschränken und Programmierkurs wegfallen zu lassen. --Bastie 07:13, 12. Mär 2005 (UTC)
- Kann mich da nur anschließen --Underdog 01:28, 9. Apr 2005 (UTC)
- is auch für mich in ordnung --Ale 19:04, 12. Apr 2005 (UTC)
- Da nichts gegenteiliges kam werde ich dann mal anfangen... --Bastie 14:32, 9. Mai 2005 (UTC)
- Ich habe das Buch jetzt so weit umgestellt, dass wir hier nur noch "Java Standard" haben (ausser Verweise natürlich ;-) ) - die letzten Kapitel aus dem Buch sollten auch noch mit in die ensprechenden Unterkapitel einsortiert werden - mal sehen wann ich es schaffe. --Lesath 09:05, 20. Jul 2005 (UTC)
- Da nichts gegenteiliges kam werde ich dann mal anfangen... --Bastie 14:32, 9. Mai 2005 (UTC)
- is auch für mich in ordnung --Ale 19:04, 12. Apr 2005 (UTC)
Struktur Inhaltsverzeichnis
BearbeitenWie ich schon mal an anderer Stelle angedeutet hatte, müsste das Inhaltsverzeichnis IMO dringend mal überdacht werden. Ich sehe da momentan keine vernünftige Struktur drin und hätte daher folgende Anmerkungen bzw. Vorschläge:
- Anfangen würde ich mit Änderungen am Kapitel "Erste Schritte". Das Hello World-Beispiel passt gut, allerdings sind Dinge wie packages und Klassenbibliotheken dort viel zu früh. Das Hello World-Beispiel zum Laufen zu bringen und (nur sehr grob) zu erklären reicht hier, finde ich.
- Die darauf folgenden Kapitel sollten erst mal verschiedene Grundlagen erläutern, die mit Objektorientierung noch nichts zu tun haben. Dadurch könnte schon mal eine gewisse Basis zur Programmierung gelegt werden, die ganz besonders für Programmieranfänger wichtig ist. Programmierer, die bereits andere Sprachen beherrschen, können diese Kapitel dann evtl. überspringen oder nur überfliegen. Alle Beispiele zu diesen Themen sollten sich m.E. jeweils nur einer einfachen Klasse mit nichts außer der main()-Methode bedienen - also möglichst noch keinen Gebrauch von packages, Methoden oder Attributen machen (Mal abgesehen von System.out.println()). Kontrollstrukturen wie try/catch würde ich hier übrigens noch nicht oder nur am Rande ansprechen, da hierfür schon Wissen über Objekte vorhanden sein muss. Ich denke hierbei z.B. an folgende Themen (nur was mir gerade einfällt; ist bestimmt nicht vollständig):
- Beschreibung und Erklärung aller primitiven Datentypen, inklusive Arrays
- Variablen: Regeln für Bezeichner, Deklaration, Definition, Sichtbarkeit
- Operatoren, Typumwandlungen bei Operationen, ...
- Kontrollstrukturen
- Wenn dann diese elementaren Grundlagen geschaffen wurden, kann auf Objektorientierung eingegangen werden. Dazu könnte es z.B. folgende Themen geben:
- Sinn und Zweck
- Klassen
- Attribute
- Konstruktoren
- Methoden
- Für Methoden und Konstruktoren: Parameter, Rückgabewerte, call-by-value/call-by-reference
- Objekte
- Erzeugen von Objekten
- Benutzung, Aufruf von Methoden bzw. Zugriff auf Attribute
- this, super
- Vererbung
- Ableiten
- abstrakte Methoden, abstrakte Klassen, Schnittstellen
- Implementieren / überschreiben von Methoden
- Polymorphie (insb. praktisches Beispiel)
- Anschließend sollten dann Themen behandelt werden, die auf diesem Basiswissen verwenden, wie etwa:
- Fehlerbehandlung
- Packages
- Übersicht der Klassenbibliothek
- Garbage Collection
- Programmierstil / -konventionen
- [...]
Ja, soweit meine Vorstellung einer (groben und sicher unvollständigen) neuen Übersicht der ersten Kapitel zur Java-Einführung. Meinungen dazu? --Underdog 01:47, 9. Apr 2005 (UTC)
- Ich bin beruhigt, dass ich nicht als einziger die Auffassungen vertrete - habe mir nur bisher nicht die Arbeit gemacht dies so schön (!) aufzuschreiben.
Außerdem schlage ich im folgenden vor dann Spezialthemen in eigene ggf. große Kapitel zusammenzufassen. Hier wären wohl in ungeordneter Reihenfolge...
- Grafische Oberflächen
- Das Graphics Object, seine Erweiterungen und deren Verwendung
- AWT
- Swing
- SWT
- 3D Programmierung
- Spezialthemen
- Nutzung von java.awt.Robot (siehe auch Test)
- Applets
- [...]
- Test, Trace und Logging
- Logging API von Java 1.4
- Testen grafischer Oberflächen mit java.awt.Robot
- Netzwerkprogrammierung
- Socket, ServerSocket (java.net) UDP und TCP / IP
- RMI
- Corba
- Datenbankzugriff
- JDBC
- SQL
IMHO sollte diese oder eine schönere Verzeichnisstruktur einfach mal "hingeklatscht werden". Der wesentliche Vorteil wäre sicher dass man gleich sieht wo sind noch Baustellen. --Bastie 06:46, 10. Apr 2005 (UTC)
- Ja, finde ich auch. Dann weiß man beim Schreiben auch schon etwas besser, auf welches Wissen man schon zurückgreifen kann. Deine erweiterte Auswahl möglicher Spezialthemen sieht zudem auch schon sehr gut aus, finde ich.--Underdog 23:14, 10. Apr 2005 (UTC)
- Ich denke, dass man auch in den ersten Kapiteln schon objektorientierte Elemente miteinbringen muss. Und gerade im ersten Programm wäre es durchaus sinnvoll, dem Leser zu zeigen, wie ein "richtiges" Programm aussieht. Das er das nicht sofort versteht, dass ist klar. Ist ja auch nicht Sinn der Sache. In den ersten Zeilen soll er ja Appetit auf den Rest des Buches kriegen. Damit meine ich natürlich nicht den Leser zu überlasten, aber ihn mit trivialen Sachen durch die ersten Kapitel zu ziehen macht vielleicht auch keinen Spass. Wenn der Leser sieht wie z.B. Variablen eingesetzt werden, dann wird er schon darüber hinwegsehen, dass er zuerst die für Anfänger kryptischen Schreibweisen nicht versteht.
- Also da bin ich stark dagegen, denn irgendwo muss man ja mal anfangen, dem (programmierunerfahrenen) Benutzer von Grund auf Dinge zu erklären müssen, die kein anderes Vorwissen benötigen. Und ich denke, dass wir ansonsten viel zu oft Dinge erklären, die ihrerseits wieder andere Dinge voraussetzen, welche aber erst später erklärt werden. Das heißt jetzt nicht, dass man gar nichts über Objektorientierung sagen kann. Aber meiner Meinung nach zunächst nur ganz am Rande. Vielleicht könnte man im Kapitel Erste Schritte neben dem Hello World-Beispiel auch noch ein komplexeres Beispiel bringen, wie wäre das? Damit könnte ich leben, sofern man etwas findet was den Benutzer nicht von vorneherein total verwirrt. Aber danach sollten IMO die Grundlagen erst mal losgelöst von sonstiger Objektorientierung erklärt werden. Zumal diese Grundlagen meiner Meinung nach sicher nicht trivial sind, insb. für den Programmieranfänger nicht. --Underdog 22:33, 12. Apr 2005 (UTC)
- Du meinst beispielsweise HelloWorld zweimal zu schreiben (?)... etwa wie hier [HelloWorld http://www.bastie.de/index.html?/java/howto/start/helloworld.html] --Bastie 07:41, 13. Apr 2005 (UTC)
- Das Beispiel von basti find ich ganz in Ordnung. Vielleicht zum Anfang des Buches ein "komplexes" Programm zeigen. Und auch dabei erwähnen, dass der Leser dies sicher nicht verstehen kann. Aber wenn er die ersten Kapitel liest, wird er das verstehen. Das komplexe Programm wäre dann ja so eine Art Zielsetzung... - Aler 17:02, 13.4.5
- Ja, geht für mich in Ordnung. Allerdings dachte ich als "komplexes" Beispiel eher an ein Programm, das eine etwas sinnvollere Aufgabe erledigt als dieses erwähnte Hello World-Beispiel. Denn ich könnte mir vorstellen, dass sich ein Leser dabei fragt, was denn die Objektorientierung überhaupt soll - schließlich macht das einfachere nicht objektorientierte Programm ja genau dasselbe; d.h. die Objektorientierung ist dort scheinbar überflüssiger Ballast... Kurz gesagt: Ich bin nicht prinzipiell gegen dieses Beispiel, fände aber ein anderes besser, das sinnvolleren Gebrauch von OO macht und vielleicht eine etwas interessante Aufgabe löst (zugegeben, wobei mir da auf Anhieb auch nichts kurzes einfällt) --Underdog 11:22, 15. Apr 2005 (UTC)
- Zu dem Begriff "trivial" - wenn ein Anfänger erklärt bekomme was eine Variable ist und wie man sie z. B. bei einem Iterator anwendet, dann empfindet er das schon trivial (habe ich damals) - Weil er den Gesamtzusammenhang nicht kennt. Wenn ich jetzt in einem größeren Zusammenhang eine Kleinigkeit erklärt bekomme, verstehe ich nicht nur die Kleinigkeit, sondern schon ein Stück des Ganzen. Was ja letztlich auch der Grund für diesen Abschnitt ist- Ich denke man sollte keine losgelösten Stücke präsentieren. - Aler 17:04, 13.4.5
- Gut, aber die Beschreibung der Grundlagen bzgl. Variablen, Operatoren, Kontrollstrukturen etc. muss ja aber trotzdem nicht gleich Gebrauch von Objektorientierung machen - das würde m.E. an der Stelle einfach nichts bringen, sondern höchstens das Verständnis erschweren. --Underdog 11:29, 15. Apr 2005 (UTC)
- Das Beispiel von basti find ich ganz in Ordnung. Vielleicht zum Anfang des Buches ein "komplexes" Programm zeigen. Und auch dabei erwähnen, dass der Leser dies sicher nicht verstehen kann. Aber wenn er die ersten Kapitel liest, wird er das verstehen. Das komplexe Programm wäre dann ja so eine Art Zielsetzung... - Aler 17:02, 13.4.5
- Du meinst beispielsweise HelloWorld zweimal zu schreiben (?)... etwa wie hier [HelloWorld http://www.bastie.de/index.html?/java/howto/start/helloworld.html] --Bastie 07:41, 13. Apr 2005 (UTC)
- Also da bin ich stark dagegen, denn irgendwo muss man ja mal anfangen, dem (programmierunerfahrenen) Benutzer von Grund auf Dinge zu erklären müssen, die kein anderes Vorwissen benötigen. Und ich denke, dass wir ansonsten viel zu oft Dinge erklären, die ihrerseits wieder andere Dinge voraussetzen, welche aber erst später erklärt werden. Das heißt jetzt nicht, dass man gar nichts über Objektorientierung sagen kann. Aber meiner Meinung nach zunächst nur ganz am Rande. Vielleicht könnte man im Kapitel Erste Schritte neben dem Hello World-Beispiel auch noch ein komplexeres Beispiel bringen, wie wäre das? Damit könnte ich leben, sofern man etwas findet was den Benutzer nicht von vorneherein total verwirrt. Aber danach sollten IMO die Grundlagen erst mal losgelöst von sonstiger Objektorientierung erklärt werden. Zumal diese Grundlagen meiner Meinung nach sicher nicht trivial sind, insb. für den Programmieranfänger nicht. --Underdog 22:33, 12. Apr 2005 (UTC)
- Ich denke, dass wir für die tiefergehenden Themen ein eigenes Buch aufmachen sollten, oder aber den Namen dieses hier verändern - so interessant die Themen auch (ja viel besser als die Einsteigersachen) sind, so ist der Titel noch "Java Einführung mit der Standard Edition". Also in dieses Buch die Liste von Underdog rein. Und in eine weiterführendes Buch die Liste von Basti, sowie die Themen, die jetzt in "Weiterführende Themen" drin stehen. -- Aler, 19:27, 12.4.05
- Fände ich auch ok das in mehrere Bücher aufzuteilen. Solange jetzt nicht viele verschiedene Bücher zu allen möglichen weiterführenden Themen erstellt werden... Dafür sind momentan IMO nämlich noch zuwenige Grundlagen vorhanden... --Underdog 22:33, 12. Apr 2005 (UTC)
- Bin ich (fast) dagegen. 1.) Das Buch heißt noch Programmierkurs Java - ich habe lediglich mal den Link geändert um den Inhalt besser darzustellen insbesondere auch in Abgrenzung zu J2EE was ich noch ein bisschen bearbeite. 2.) Ich wäre eher für den umgekehrten Weg ein Buch "Java für Programmieranfänger" zu machen. In diesem würde ich dann allerdings nur wirklich rudimentär an Java rangehen bis dem Leser soviel Wissen zuzutrauhen ist umd hier einzusteigen. Im Gegenzug würde ich hier zu "Java mit der Standard Edition" wechseln und die grundlegenden Sprachkonstrukte voraussetzen. Dies würde dann aber auch den kompletten OO Teil einschließen... - das ganze muss IMHO sehr genau überlegt werden, da sonst entweder zwei konkurenz-bücher entstehen oder keines der Bücher für Java Anfänger geeignet ist <grübel...> --Bastie 07:41, 13. Apr 2005 (UTC)
- Also Konkurrenz sollte sowieso nicht entstehen - dazu sind wir zuwenige, um die Konkurrenz produktiv auf unser Schreiben wirken zu lassen. (Mich überrascht sowieso, dass bei dem Thema Java so wenige schreiben ???) Vielleicht sollte man wirklich ein großes Buch machen, fast schon ein Kompendium. Wo alle Elemente der J2SE erklärt sind. Je mehr Bücher im Regal stehen, desto verwirrender wird es sowieso. Und wenn wir die Kapitelanzahl innerhalb dieses Buches - sage ich mal - nicht über 10 ansteigen lassen, dann bleibt es doch auch übersichtlich? was sagt ihr, wieviel kapitel (und unterkapitel) darf ein buch haben? - Aler 17:12, 12.April 05
- Ich kenne Bücher die haben 20 und sind gut lesbar, da Sie abgeschlossene Themen behandeln. Ich denke "runterschreiben" und wenn es soweit ist machen wir uns Gedanken über eine Auslagerung der Teile. Wenns soweit ist werden die grafischen Oberflächen sicher ein Kandidat sein. Bastie 08:02, 14. Apr 2005 (UTC)
- Bin ich auch dafür. Ich denke auch dass eine größere Anzahl von Kapiteln nicht generell hinderlich sein muss - das Inhaltsverzeichnis muss dann einfach nur entsprechend übersichtlich und verständlich gegliedert sein. --Underdog 11:22, 15. Apr 2005 (UTC)
- Ich kenne Bücher die haben 20 und sind gut lesbar, da Sie abgeschlossene Themen behandeln. Ich denke "runterschreiben" und wenn es soweit ist machen wir uns Gedanken über eine Auslagerung der Teile. Wenns soweit ist werden die grafischen Oberflächen sicher ein Kandidat sein. Bastie 08:02, 14. Apr 2005 (UTC)
- Also Konkurrenz sollte sowieso nicht entstehen - dazu sind wir zuwenige, um die Konkurrenz produktiv auf unser Schreiben wirken zu lassen. (Mich überrascht sowieso, dass bei dem Thema Java so wenige schreiben ???) Vielleicht sollte man wirklich ein großes Buch machen, fast schon ein Kompendium. Wo alle Elemente der J2SE erklärt sind. Je mehr Bücher im Regal stehen, desto verwirrender wird es sowieso. Und wenn wir die Kapitelanzahl innerhalb dieses Buches - sage ich mal - nicht über 10 ansteigen lassen, dann bleibt es doch auch übersichtlich? was sagt ihr, wieviel kapitel (und unterkapitel) darf ein buch haben? - Aler 17:12, 12.April 05
- Bin ich (fast) dagegen. 1.) Das Buch heißt noch Programmierkurs Java - ich habe lediglich mal den Link geändert um den Inhalt besser darzustellen insbesondere auch in Abgrenzung zu J2EE was ich noch ein bisschen bearbeite. 2.) Ich wäre eher für den umgekehrten Weg ein Buch "Java für Programmieranfänger" zu machen. In diesem würde ich dann allerdings nur wirklich rudimentär an Java rangehen bis dem Leser soviel Wissen zuzutrauhen ist umd hier einzusteigen. Im Gegenzug würde ich hier zu "Java mit der Standard Edition" wechseln und die grundlegenden Sprachkonstrukte voraussetzen. Dies würde dann aber auch den kompletten OO Teil einschließen... - das ganze muss IMHO sehr genau überlegt werden, da sonst entweder zwei konkurenz-bücher entstehen oder keines der Bücher für Java Anfänger geeignet ist <grübel...> --Bastie 07:41, 13. Apr 2005 (UTC)
- Fände ich auch ok das in mehrere Bücher aufzuteilen. Solange jetzt nicht viele verschiedene Bücher zu allen möglichen weiterführenden Themen erstellt werden... Dafür sind momentan IMO nämlich noch zuwenige Grundlagen vorhanden... --Underdog 22:33, 12. Apr 2005 (UTC)
- Ich denke, dass man auch in den ersten Kapiteln schon objektorientierte Elemente miteinbringen muss. Und gerade im ersten Programm wäre es durchaus sinnvoll, dem Leser zu zeigen, wie ein "richtiges" Programm aussieht. Das er das nicht sofort versteht, dass ist klar. Ist ja auch nicht Sinn der Sache. In den ersten Zeilen soll er ja Appetit auf den Rest des Buches kriegen. Damit meine ich natürlich nicht den Leser zu überlasten, aber ihn mit trivialen Sachen durch die ersten Kapitel zu ziehen macht vielleicht auch keinen Spass. Wenn der Leser sieht wie z.B. Variablen eingesetzt werden, dann wird er schon darüber hinwegsehen, dass er zuerst die für Anfänger kryptischen Schreibweisen nicht versteht.
Stil von Quelltexten
BearbeitenIch fände es gut, mal ein paar Kleinigkeiten zu klären, was den Stil dieses Buches angeht. Insbesondere denke ich dabei momentan an Formatierungen von Quelltexten, die einheitlich sein sollten. Drei Punkte fallen mir dabei ein, wobei ich meine eigene Meinung dazu direkt dazu schreibe. Wäre sicher nicht schlecht, wenn wir uns da auf etwas einigen könnten.
- Klammersetzung: Ich persönlich bevorzuge es (entgegen dem Stil von Sun), wenn die öffnende Klammer bei Methoden und Blöcken in eine neue Zeile kommt. Ich kann mich auch problemlos mit dem vielgenutzten Stil arrangieren, die öffnende Klammer ans Ende z.B. einer if-Zeile usw. zu stellen, finde die andere Variante aber insbesondere für Anfänger viel übersichtlicher. Auch wenn sie natürlich mehr Platz benötigt.
- Nun ich verwende die Klammer eher hinten und finde dies ausreichend übersichtlich. Wichtiger erscheint mir die Einrückung. --Bastie 06:33, 10. Apr 2005 (UTC)
- Hmmm, also die Art der Klammernutzung finde ich für die Verständlichkeit eigentlich wichtiger als die Einrückung. Ich denke zwar auch dass es für Leser, die schon irgendeine Programmiersprache kennen, keinen riesigen Unterschied macht - aber für völlige Anfänger finde ich das nicht ganz unerheblich. Zumindest kann ich das aus eigener Erfahrung sagen, ich hatte anfangs schon Schwierigkeiten mich an das Lesen solchen Codes zu gewöhnen. --Underdog 23:05, 10. Apr 2005 (UTC)
- Ob die Klammern nun in einer neuen Zeile stehen oder noch in der alten ist für mich eher nebensächlich. Daher entscheidet mal was ihr für wichtiger haltet. Ich denke, das der "Kapiermoment" beim Leser eher unabhängig von der Klammersschreibweise ist. Für eher problematisch halte, wenn bei einer if-Schleife für eine einzelne Zeile keine Klammer benutzt wird. Dass könnte zu Verwirrung führen. -- Aler 19:11, 12.April 2005
- Ja, das mit den Klammern auch für einzelne Anweisungen in Kontrollstrukturen könnte man zumindest für die einleitenden Kapitel als Regel festhalten, denke ich. Aber ohne zu kleinlich wirken zu wollen: Eine if-Anweisung ist keine Schleife! ;-) --Underdog 22:20, 12. Apr 2005 (UTC)
- umph, *schäm*, da hast du mich auf dem falschen fuss erwischt.... wohl ein bißchen schnell geschrieben mit der "if-schleife" :-) -- Aler 17:00, 13.4.05
- Ja, das mit den Klammern auch für einzelne Anweisungen in Kontrollstrukturen könnte man zumindest für die einleitenden Kapitel als Regel festhalten, denke ich. Aber ohne zu kleinlich wirken zu wollen: Eine if-Anweisung ist keine Schleife! ;-) --Underdog 22:20, 12. Apr 2005 (UTC)
- Ob die Klammern nun in einer neuen Zeile stehen oder noch in der alten ist für mich eher nebensächlich. Daher entscheidet mal was ihr für wichtiger haltet. Ich denke, das der "Kapiermoment" beim Leser eher unabhängig von der Klammersschreibweise ist. Für eher problematisch halte, wenn bei einer if-Schleife für eine einzelne Zeile keine Klammer benutzt wird. Dass könnte zu Verwirrung führen. -- Aler 19:11, 12.April 2005
- Hmmm, also die Art der Klammernutzung finde ich für die Verständlichkeit eigentlich wichtiger als die Einrückung. Ich denke zwar auch dass es für Leser, die schon irgendeine Programmiersprache kennen, keinen riesigen Unterschied macht - aber für völlige Anfänger finde ich das nicht ganz unerheblich. Zumindest kann ich das aus eigener Erfahrung sagen, ich hatte anfangs schon Schwierigkeiten mich an das Lesen solchen Codes zu gewöhnen. --Underdog 23:05, 10. Apr 2005 (UTC)
- Nun ich verwende die Klammer eher hinten und finde dies ausreichend übersichtlich. Wichtiger erscheint mir die Einrückung. --Bastie 06:33, 10. Apr 2005 (UTC)
- Einrückung: Ich bin für eine Einrückung von 2 Leerzeichen pro Einrückungsstufe. Die wurde bei den meisten bisherigen Beispielen hier auch verwendet, glaube ich.
- Volle Zustimmung --Bastie 06:33, 10. Apr 2005 (UTC)
- Also auf jeden Fall ist überhaupt eine Einrückung wichtig - ob das jetzt zwei oder fünf Leerzeichen sind, finde ich nicht so wichtig -- Aler 19:07, 12.April 2005
- Ist es auch nicht, stimmt. Sollte halt nur einheitlich sein, also dann halten wir fest: durchgängig mit 2 Leerzeichen. --Underdog 22:20, 12. Apr 2005 (UTC)
- Also auf jeden Fall ist überhaupt eine Einrückung wichtig - ob das jetzt zwei oder fünf Leerzeichen sind, finde ich nicht so wichtig -- Aler 19:07, 12.April 2005
- Volle Zustimmung --Bastie 06:33, 10. Apr 2005 (UTC)
- Nummerierung: Hier stellt sich die Frage, ob Beispiele mit Zeilennummern versehen werden sollten. So ist es natürlich einfacher, im erklärenden Text auf bestimmte Stellen Bezug zu nehmen. Andererseits wird es für die Leser dadurch sehr erschwert, ein Beispielprogramm einfach mal per Copy/Paste zu übernehmen und selbst auszuprobieren bzw. zu verändern. Letzteres Argument wiegt meiner Meinung nach recht schwer, weswegen ich dafür bin, Zeilennummern i.d.R. nicht zu verwenden. Für die Erklärung eines Programms kann man m.E. ja bei Bedarf auch mal eine Zeile wiederholen, um klarzumachen, welche Stelle man meint.
--Underdog 01:30, 9. Apr 2005 (UTC)
- Ebenfalls volle Zustimmung --Bastie 06:33, 10. Apr 2005 (UTC)
- Eindeutig gegen Nummerierung - ich denke in den meisten Java-Tools werden doch eh automatisch die Zeilen gezählt, so dass beim Copy&Paste die vorgegebene Zeilennummern doppelt wären. Und unsere Beispiele sind doch alle nicht lang. Das muss der Leser ja auch lernen, sich in so kleinen Programmen zurecht zu finden. - Aler 19:13, 12.April 2005
- Ebenfalls volle Zustimmung --Bastie 06:33, 10. Apr 2005 (UTC)