Ja, das ist richtig: Beispiel aus dem wirklichen Leben sind sehr wichtig, z.B. die Datenzugriffe. Hier ist halt SQL angesagt, d.h. wir kommen vom "Listenanfang bei" wieder zurück zum guten alten "Matchcode".

Meine Devise: Erst mal in die Technologien hineinschnuppern - losgelöst von der Vergangenheit - und mit dem gewonnenen Vokabular und Verständnis anschließend die Analogien zu RPG suchen.

Schön ist in Java halt, dass ich viele Dinge verstecken kann. Deswegen ist es u.U. auch vorteilhaft, nicht nur in Techniken zu denken, sondern auch in Aufgabenstellungen. Beispiel: Ich hatte in RPG eine Parameterverwaltung, die sah so und so aus. Wie kriege ich das in Java geregelt.

Auf mich übt der Open-Source-Gedanke einen großen Reiz aus. Wenn wir eine Aufgabenstellung beim Namen nennen können, dann besteht auch eine gute Chance, dass wir miteinander Komponenten austauschen können, die uns diese Aufgabenstellung sehr schnell lösen lassen.

Und das steht fest: Bzgl. Aufgabenstellungen kann jeder mitreden und sofort seine Berufserfahrung mit einbringen - unabhängig von seinen Kenntnissen in Objektorientierung. Daher meine Idee, zu Beginn Augabenstellungen zu sammeln und zu gliedern, um darauf aufbauend ein "Wie löse ich was"-Wissensdatenbank aufzubauen.

Chr******