Vorwort

Man möchte meinen, daß, wenn einer mehr als zehn Jahre lang Schülern, Studenten und Lehrern objektorientierte Programmierung beigebracht hat, er nun endlich wissen müßte, wie das geht. Im Prinzip schon. Aber bereits die Fülle der verschiedenen Ansätze und Versuche zeigt, daß es offensichtlich keinen Königsweg gibt, nur bessere oder weniger erfolgreiche Wege.

Auch in unserer Schule, die auf diesem Gebiet ziemlich rührig und produktiv ist, wurden immer wieder neue Ansätze probiert, verworfen, verbessert, meist jedoch in didaktischen Detailfragen, während in den übergeordneten Zielen und Methoden sich ein ordentlicher Stil etabliert hat.

Einigkeit herrscht in der Überzeugung, daß die objektorientierte Denkweise für Schüler kein Problem ist, jedoch die handwerkliche Umsetzung ('das Programmieren') wegen der fehlenden ausreichenden Übungszeit, ohne die es nicht geht, ein große Hürde ist. Dieses wird noch dadurch verschärft, daß sich die Schule für DELPHI als Entwicklungsumgebung entschieden hat. Mich verbindet mit Delphi geradezu eine Hassliebe, wobei ich dennoch glaube, daß am Ende die Vorteile für den Unterricht überwiegen. Das ist an anderer Stelle hinreichend diskutiert worden.

Objektorientierte Programmierung in der Schule ist also weniger ein intellektuelles als ein methodisches Problem.

Ein Programmierstil, dessen Nukleus das Objekt ist, fordert geradezu heraus, die Objekte, die in einem Programm bearbeitet werden, auch auf dem Bildschirm sichtbar zu machen, um eine direkte visuelle Kontrolle der Effekte zu haben, die der Schüler in seinen Anweisungen programmiert. Zu diesem Zweck haben wir die Unterrichtsequenz mit den Grafikobjekten (uGrafik) entwickelt und damit gute Erfolge verzeichnet. Da die Aufgabenstellungen häufig einen mehr oder weniger 'dekorativen' Charakter haben, kommt das Element der Algorithmisierung etwas zu kurz.

Dieses zeigt sich auch häufig bei Programmen, die Aufgabenstellungen aus dem wirtschaftlich-verwaltenden Bereich haben. Registrierende Systeme kommen oft genug mit Set.. und Get-Methoden aus.

Diese Ausgangslage und reichlich Freizeit haben mich bewogen, eine Karel-Lernumgebung zu entwickeln, die mehr ermöglicht als die klassischen Versionen, die mit Mini-Languages im Wesentlichen in Algorithmen und imperative Programmierung einführen, auch wenn Sie in OOP-Sprache und Dot-Notation daher kommen. Diese Lernumgebungen waren mir nur oberflächlich bekannt (weil ich damit nichts im Sinn hatte) und ich habe bewußt auch auf ein genaues Studium dieser Vorlagen verzichtet, um nicht den Blick zu verstellen für das, was IMHO für eine zeitgemäße Lernumgebung wichtig ist. Gleichzeitig ging es mir noch einmal darum, an einem Beispiel zu zeigen, wie mit den Mitteln der objektorientierten Programmierung (Vererbung, Polymorphie) sparsamer Code zustande kommt, Kapselung die Sicherheit erhöht und die Fehlersuche erleichtert. Die Programmierung war insofern eher eine leichte Anstrengung. Das Ergebnis wird hier für die Besichtigung und hoffentlich auch zur Benutzung vorgestellt.

Meinen Kollegen Hartmut Härtl, Johann Penon und Christian Steinbrucker danke ich für Anregungen und Kritik. Richard Pattis (Carnegie Mellon University) gebührt der Dank für die freundliche Genehmigung, den Namen 'Karel' verwenden zu dürfen und Werner Hartmann (ETH Zürich) für richtungweisenden Rat.