An dieser Stelle möchte ich etwas näher auf den Stoffverteilungsplan eingehen, Besonderheiten aber auch Schwierigkeiten aufzeigen und mögliche Probleme verdeutlichen, aber auch Lösungen anbieten, diese zu vermeiden.
Zunächst sei nochmals darauf hingewiesen, dass der Begriff Objekt und die damit verbundenen Ideen bereits im ersten Halbjahr angesprochen wurden. So könnte man Icons als bildliche Werkzeuge zur Objektmanipulation betrachten, Texte als Objekte, die über Eigenschaften verfügen, denen in bestimmten Programmen aber auch Methoden und Werkzeuge zur Manipulation an die Hand gelegt werden. Dies geht bereits in die Richtung Vererbung und Erweiterung von Objekten. So könnte aus einem simplen Asciitext ein komplexes RTF-Objekt werden.
Die Schüler würden dadurch bereits Erfahrungen mit der Objektidee sammeln, wenn auch nur aus Anwendersicht! Ziel der ersten Stunde der Einheit OOP sollte es daher sein, den Blickwinkel der Schüler zu erweitern. Was ist ein Programm? Je nach Blickwinkel des Anwenders, des Programmierers oder der Maschine finden sich auf diese Frage unterschiedliche Antworten. Hierbei kann sich schnell eine Schülerdiskussion ergeben, beginnt die Einheit doch mit einer fast philosophischen Frage, die vom Lehrer Stück für Stück zu einer Antwort der Informatik gebracht werden kann. Mit dem Begriff Algorithmus kann ähnlich verfahren werden.
Sind sich die Schüler einer neuen Perspektive bewusst, kann eine Einführung in die Grundideen und den Aufbau einer ersten Programmiersprache - in unserem Falle Delphi - erfolgen. An dieser Stelle möchte ich auf das Kapitel Die erste MDI-Anwendung verweisen. Dort wird der Stundenablauf genauer skizziert und an Beispielen verdeutlicht. Die Quellcodes befinden sich im Anhang.
Bereits zu diesem frühen Zeitpunkt werden zwei Probleme der Delphikonzeption deutlich, welche den meisten Schülern nicht bewusst werden, in Informatiker- und insbesondere Lehrerkreisen aber zu einigen Diskussion führten und führen.
Zunächst geht es um das Verständnis der GUI-Objekte. Diese sind aus technischer Sicht eindeutig wie Objekte zu behandeln, sind aber - gerade aus Sicht eines Anfängers der OOP - nicht leicht vereinbar mit den selbstkonstruierten Objekten, die ein Programmierer selbst implementiert und die ein Problem lösen sollen. Den Punkt der Implementierung kann man einfach dadurch erklären, dass GUI-Objekte der Einfachheit halber automatisch und nicht sichtbar für den Programmierer (zumindest auf den ersten und vielleicht auch zweiten Blick hin) implementiert werden. Zwar hat man die technischen Aspekte des Problems leicht gelöst bzw. vertagt oder schlimmstenfalls ganz verdrängt, doch gibt es immer noch ein Verständnisproblem. Soll man eine Dualität GUI-Objekt und Problembearbeitungs/-lösungs-Objekt (im folgenden kurz PBA/L-Objekt) akzeptieren oder gibt es doch Gemeinsamkeiten? Wissenschaftlich gesehen handelt es sich um zwei unterschiedliche Konzepte, die sich in vielen Punkten unterscheiden. Dennoch möchte ich folgende Lösung anbieten: Auch ein GUI-Objekt könnte als ein PBA/L-Objekt angesehen werden, wenn man lediglich die Aufgabe des Objektes betrachtet. Es bietet einfach eine Lösung für folgendes Problem an: Wie bediene ich ein PBA/L-Objekt bzw. wie stelle ich die Problemlösung eines PBA/L-Objektes dar? Dadurch wird auch ein GUI-Objekt zu einem PBA/L-Objekt. Es liegt lediglich immer eine Hierarchie-Ebene über dem eigentlichen PBA/L-Objekt. Dies wird dadurch deutlich, dass die Formular-Unit meist Methoden beinhaltet, die entweder zur Darstellung oder zur Bedienung eines PBA/L-Objektes verwendet werden. Das PBA/L-Objekt befindet sich dabei in einer Unit, die von der Formular-Unit per uses-Klausel eingebunden wird.
Damit verbunden tritt auch schon das zweite Problem auf. Idealerweise werden die Attribute eine Objektes nur mittels Methoden manipuliert. Leider gilt dies bei Delphi aber für die meisten Attribute der GUI-Objekt nicht. Es existiert keine Methode Button1.setcolor(clRed) . Stattdessen erfolgt eine direkte Zuweisung ohne Methodenaufruf: Button1.color:=clRed . Ob dies jetzt schlechter Stil auf Kosten vermeintlich schnellerer Programmierung, ein Riesen-Bug, aus der Pascal-Tradition geboren oder einfach eine Marotte von Delphi ist, möchte ich nicht diskutieren. Das Problem würde ohnehin bestehen bleiben. Ein Lösungsansatz wäre der, dass alle Attribute, die über Methoden zugewiesen und abgefragt werden, private-Variablen sind, alle Attribute, die direkt zugewiesen werden oder die direkt ausgelesen werden können, sind hingegen public-Variablen. Dies wird für die Schüler in ihrer ersten Programmier-Stunde vermutlich nicht von Bedeutung sein, wenn aber auf OOA eingegangen wird und die korrekte Bildung von Objekten, kann dieses Problem schnell zu Tage treten. Mit public-Variablen lässt sich die Frage beantworten. Eine Folgediskussion kann nun zwar wieder thematisieren, ob man denn überhaupt public-Variablen braucht, doch möchte ich mich auch dieser Diskussion an dieser Stelle nicht stellen. Zur Not muss man sich wohl damit abfinden, dass Delphi das public-Konzept einfach unterstützt. Ob dies jetzt schlechter Stil zu Kosten vermeintlich schnellerer Programmierung, ein Riesen-Bug, aus der Pascal-Tradition geboren oder einfach eine Marotte von Delphi ist, ...
Bevor ich weiter auf den Ablauf im Stoffverteilungsplan eingehe, möchte ich noch auf ein weiteres Problem hinweisen, diesmal aber eher didaktischer Art. Die Anfangsphase wird sehr stark von Lehrergesprächen dominiert, die Methodenvielfalt ist relativ gering. Das mag zunächst sehr nachteilig erscheinen, hat jedoch auch entscheidende Vorteile. Der Anfangsunterricht kann sehr präzise, kompakt und relativ schnell gestaltet werden. Vor allem werden aber viele Fehlinformationen zu Beginn vermieden, wie sie in einem schlecht vorbereiteten Schülerreferat auftreten können. Das präzisere Lenken macht es meiner Einschätzung nach für die Schüler in den ersten drei Stunden leichter. Um dennoch die Methoden zu variieren, bieten sich Arbeitsblätter an, mit Hilfe derer die Schüler schnell Erfolge erzielen und nicht in den Tiefen Delphis verloren gehen.
Nachdem ein erster Eindruck vermittelt wurde und die Schüler sich in die Grundkonzepte hineindenken konnten, werden weitere Erfahrungen gesammelt. So können andere GUI-Objekte eingeführt und das Hilfesystem erkundet werden.
Bevor jetzt die Programmierung vertieft wird, sollten sich die Schüler über die Modellbildung Gedanken machen. Damit wird wildes "Rumtippen" verhindert und ein strukturiertes Arbeiten ermöglicht. Mit dieser Einheit beschäftigt sich auch das Kapital Grundlagen der OOA.
In den nächsten Wochen werden dann die Syntax, das Variablenkonzept und spezielle Befehle unter Delphi behandelt, dazu kommen noch Methoden und Unterprozeduren. Dies ist nötig, um den Schülern ein eigenständiges Programmieren zu ermöglichen. Wie sehr die einzelnen Punkte vertieft werden, hängt sehr stark von den Schülern ab. Auch die Reihenfolge kann an dieser Stelle etwas variiert werden. Um wie im vorgestellten Stoffverteilungsplan vorgesehen das Parameterkonzept mit den Fehlerarten zu kombinieren, ist es aber unablässig, auf Methoden und Unterprozeduren Bezug nehmen zu können.
Wie diese Verknüpfung genau gestaltet werden kann, wird im Kapitel Parameterkonzept und Fehler behandelt. Der Vorteil dieser Themenkombination ist die Verbindung von allgemeinem Konzept (Parameterkonzept), Informatik-Standart-Problem (Fehler in Programmen) und Delphi-spezifischer Syntax. An dieser Stelle wird zudem die Analyse-Fähigkeit der Schüler gefördert. Dies ist insofern sehr erfreulich, als dass in der nächsten Stoffeinheit die Benutzung gegebener Units und Objekte thematisiert wird und genau dabei das Analysieren gegebener Quellcodes unerlässlich ist.
Beispielsweise können den Schülern einfache Grafikobjekte gegeben werden, bei denen sich eine Änderung der Attribute schnell und einfach durch Form- oder Farbwandlungen darstellen lässt. Wichtig ist in dieser Einheit nicht nur der Umgang mit gegebenen Objekten sondern auch deren Analyse. Dementsprechend sollte nicht einfach "drauflosgehackt" werden, sondern vorher Zeit zum Einarbeiten gegeben werden. Je nach Schülerleistung muss dieser Punkt sogar noch besonders vertieft werden.
Kontrollstrukturen und eine Zeit für Übungen und Wiederholungen folgen, bevor wiederum die OOA behandelt wird. Erneut wird das Thema aufgegriffen, diesmal aber weiter vertieft. Hatten die Schüler anfangs noch so gut wie keine Programmierkenntnisse und waren lediglich auf Alltagsbeispiele angewiesen, so haben sie inzwischen tiefergehende Kenntnisse erworben und konnten zudem den Blickwinkel des Programmierers erkunden.
Am Ende des Halbjahres soll schließlich das erste kleinere Projekt erfolgen. Ein Bildschirmschoner bietet sich an, ist er doch relativ leicht realisierbar, erfordert aber dennoch eine gewisse Planung und Einarbeitung. Zudem werden hohe Anforderungen an die Teamfähigkeiten und die Kreativität der Schüler gestellt. Das Kapitel Das erste Projekt: ein Screensaver beschäftigt sich näher mit diesem Punkt.
Abschließend lässt sich sagen, dass der Stoffverteilungsplan einen Weg beschreibt, OOA und OOP mit Delphi einzuführen. Es gibt mit Sicherheit noch andere, Experimentieren und Anpassen an die Schülerbedürfnisse werden auf jeden Fall notwendig werden. Auch sollte der Kursvorschlag nicht als reiner Programmierkurs verstanden werden. Wann immer möglich sollte über den Tellerrand des Delphi-Tellers geschaut werden, um die Themen anzureichern und interessanter zu gestalten. Ansatzpunkte dafür lassen sich mit Sicherheit viele finden.