Martin Häcker/Java Kurs/Allgemeine Lernziele - Versionsgeschichte

77.188.17.195: /* Was der Kurs nicht behandelt */

2009-03-20T11:33:06Z

‎Was der Kurs nicht behandelt

77.188.17.195: /* Allgemeine Ideen (Martin) */

2009-03-20T11:32:38Z

‎Allgemeine Ideen (Martin)

84.191.215.6: /* Allgemeine Ideen (Martin) */

2006-03-20T11:48:39Z

‎Allgemeine Ideen (Martin)

84.191.231.43: /* Allgemeine Ideen (Martin) */

2006-03-03T13:42:31Z

‎Allgemeine Ideen (Martin)

Buchholz am 23. Februar 2006 um 17:16 Uhr

2006-02-23T17:16:30Z

Neue Seite

= Allgemeine Ideen (Martin) =
* Vorgehen nach Ausdrucksmodell? Also Sprachfeatures so einführen wie man sie braucht um Probleme ausdrücken zu können? -- Schwierig, behalte ich aber mal im Hinterkopf.

* Kochrezept....
* Legen immer main -> instanz -> run an, ohne zu verstehen
* Von Opal ausgehen -> bringt nichts weil Opal nicht verstanden?
* Von woanders ausgehen? Von null -> normale Welt
* Von vornherein Objektorientiert -> Langfristig besser? Auch kurzfristig besser?
** Test: Wird das zum Problem wenn wir das mit run() einführen?
* '''Wir wollen, dass die Teilnehmer danach im Semester den anderen erklären können, was sie gelernt haben.'''

= Was der Kurs nicht behandelt =
* :?
* do{}while
* ++i
* switch
* Vererbung
* Interfaces
* Exceptions
* Packages
* Zugriffskontrolle (public, private, ...)

== Was können sie wenn wir fertig sind? (Martin) ==
* Utility Objekt: readFile(aFilename), getUserInput(aPrompt)
** JavaAPI lesen
** Streams verschachteln
** UtilityObjekt -> Reuse
* Objekt / null / Initialisieren
* main -> instanz -> run() (erklären wir später)?
* Programm mit mehreren Dateien
* sehen das das scheiße ist:
class _{static long _
(long __,long ___) {
return __==0 ?___+ 1:
___==0?_(__-1,1):_(__
-1,_(__, ___-1)) ; }
static {int _=2 ,___
= 2;System.out.print(
"a("+_+','+___+ ")="+
_ (_, ___) ) ;System
.exit(1);}}//(C) Ulli
* Lösungsstrategien Top->Down, Bottom->Up
** Aufgaben angehen
** Fehlerlösungsstrategien: NullPointerException, etc.
*** Was sagt denn der Fehler genau? Wie finde ich das raus?
*** Kaputter Code -> Der muss Korrigiert werden
**** n-mal das gleiche -> schleife / methode
** Zu langer code -> kurz machen
* Testen?: von main aufrufen, unittests, debuggen, printf-style
* Was wissen die Leute am Schluss von Objekten?
** Collections, Exceptions, Streams kennen
** Konstruktoren, Instanzvariablen (vielleicht weglassen?)
** Daten mit Methoden aussen herum (vielleicht)

== Erklärungsansätze ==

=== main ===
* Sich selbst am Schopf aus dem Sumpf herausziehen -> Münchhausen
** Am anfang gibts keine Objekte, also brauchts mechanismus um das erste erstellen zu können

== Mehrere Möglichkeiten ein Programm anzufangen ==
* Eclipse Scrapbook Page (File>New>Other>Java>Java Run/Debug>Scrapbook Page)
** geeignet für: Primitive, Zusammengesetzte ausdrücke, variablen, methoden aufrufen
** evtl, sogar main motivieren, indem man erst keinen startpunkt hat und ihn dann von scrapbook nach main migriert
* Static block in der Klassse ''System.exit(0)'' nicht vergessen!
** geeignet für gar nichts?
* Code direkt in main
** startpunkt des programms
* von main aus run() aufrufen
** so wie es in ernsthaften programmen gemacht wird.

= Anforderungen an den Java-Kurs (Robert) =

== Entwicklungsparadigmen ==
Woran sich unser Konzept messen lassen sollte und worin es sich von den anderen Konzepten unterscheidet:
* Zeitliche Kompaktifizierung
* Inhaltliche und zeitliche Trennung zwischen Methodik und Java-Syntax

* Problem: Neben den inhaltlichen Aspekten sollen auch methodische vermittelt werden:
** Herangehensweise an Probleme
** Fehler finden/Fehlermeldungen lesen/Debuggen
** Gutes Softwaredesign (im Kleinen)

* Frage: Wie mischt man das?
** Man kann nicht erst 2 Tage programmieren, ohne dass die Leute wissen, wie sie Fehler in ihren Programmen finden.
** Es geht aber auch nicht, dass erste sinnvolle Programme (Schleifen, Methoden) erst am Ende des zweiten Tages laufen.
** Bei zuviel Mischung verlieren die Leute den Faden.

* Ziele:
** Praktische Orientierung, d.h. schnelle Erfolge, damit die Leute am Ball bleiben und sehen, was sie machen können.
** Eine Prise mehr Stoff, als jeder versteht -- das ist wichtiger als Langeweile!

* Ideen:
** In der ersten Vorlesung sollten mögliche Probleme angesprochen werden: Wie interpretiere ich die Fehlermeldungen richtig. Sonst haben 80% der Leute keine Ahnung, wie sie die Fehler in ihren ersten Hello-World's finden.
** Syntax+Konstrukte und Methodik trennen. In der ersten Vorlesung einen Misch fahren, danach trennen.
** Sprachkonstrukte schneller durchziehen.

* Keine Hausaufgaben. Bei 8 Stunden Anwesenheit setzt sich niemnand um 22 Uhr noch hin und will die machen.
* Ist der Kurs nicht auch geeignet für Leute mit Kenntnissen in imperativer Programmierung? (Falls der Ansturm doch nicht so groß sein sollte)
* Dann: Trennung in "Leute ohne imperative-Kenntnisse" und "Leute mit imp. Kenntnissen, aber ohne Plan von Java"
* Eclipse intro muss mit rein

== Begründung zur Zeiteinteilung ==
Wieviel Zeit ist '''angemessen''' für so einen Einführungskurs?

Ich meine: 2-3 Tage. Warum?

* Bedenkt man, wieviel 5x8 Stunden sind, so sieht man: Das sind 4SWS! So viel wie eine gesamte Lehrveranstaltung mit Vorlesung und Tutorium (z.B. TheGI3).
* Jeder der Veranstalter sollte sich fragen: Was würde ich von einem Seminar erwarten, in das ich als Teilnehmer 40 Stunden Zeitaufwand an Anwesenheit hereinstecke. Und das Ergebnis sollte dann damit verglichen werden, was in diesem Kurs 'rüber kommt.
* Der Stoff ist einfach zu wenig, um damit auf einem gewissen Niveau mehr als 3 Tage zu füllen, das sind immerhin 24 Stunden. Das ist wirklich '''richtig viel Zeit'''.
* Prinzipiell ist ein gestraffter Kurs auch nicht uninteressant für diejenigen, die schon Java-Erfahrung haben.
* Man verschreckt sonst diejenigen, die Interesse an dem Kurs haben, aber ggf. auch nicht soviel Zeit investieren wollen, ebenso wie Helfer, die gern an einem 2-3-Tage-Projekt mitwirken würden.
* Selbst für Java-Anfänger ist ein Kurs mit dem Zeitaufwand einer gesamten Woche abschreckend!
* Der Kurs richtet sich an Teilnehmer, die noch keine Erfahrung in der imperativen Programmierung haben. Sicher sind darunter auch Lernschwache, aber man kann auch die Massen nicht langweilen. Wenn man sich nur am Leistungsminimum orientiert, dann leiden alle darunter. Wählt man einen Mittelweg, so langweilt sich keiner und die Schwächeren haben die Chance, etwas mitzunehmen, danach Fragen zu stellen und selbst Werkzeuge in der Hand zu haben, um nach Lösungen für ihre Probleme zu suchen (Buch-Referenz, Doku)

@@ Zeile 18: / Zeile 18: @@
 * ++i
 * switch
 * Interfaces
 * Exceptions
@@ Zeile 75: / Zeile 72: @@
 * von main aus run() aufrufen
 ** so wie es in ernsthaften programmen gemacht wird.
 = Anforderungen an den Java-Kurs (Robert) =

@@ Zeile 1: / Zeile 1: @@
 = Allgemeine Ideen (Martin) =
 * Vorgehen nach Ausdrucksmodell? Also Sprachfeatures so einführen wie man sie braucht um Probleme ausdrücken zu können? -- Schwierig, behalte ich aber mal im Hinterkopf.
+* Ist es am Anfang nicht besser nich-Fachwoerter zu benutzten um weniger zu verwirren?
 * Kochrezept....
 * Legen immer main -> instanz -> run an, ohne zu verstehen
 * Von Opal ausgehen -> bringt nichts weil Opal nicht verstanden?
 * Von woanders ausgehen? Von null -> normale Welt
 * Von vornherein Objektorientiert -> Langfristig besser? Auch kurzfristig besser?
 ** Test: Wird das zum Problem wenn wir das mit run() einführen?

@@ Zeile 10: / Zeile 10: @@
 * '''Wir wollen, dass die Teilnehmer danach im Semester den anderen erklären können, was sie gelernt haben.'''
 * Wir sollten noch eine website erstellen auf der die folien und die übungsaufgaben etc verlinkt sind, das wiki ist imo dafür zu offen. Die seite muss ja nicht groß was enthalten und auch nicht schick sein. Sie könnte auch einfach auf dem user-account von einem von uns sein und auf files user-accounts der jeweiligen organisatoren zeigen...? (Sven)
 = Was der Kurs nicht behandelt =