|
|
|
Ich bin seit etwa 20 Monaten Referendar und habe seit dem nahezu täglich Schüler beobachtet, die mit der Entwicklungsumgebung Delphi arbeiten. Neben den zahlreichen Vorteilen dieser Umgebung – es ist erstaunlich, wie schnell sich eine Programmoberfläche erzeugen lässt – sind mir dabei auch einige Nachteile aufgefallen, die ich im Folgenden kurz beschreiben möchte.
Man stelle sich etwa die nicht allzu weit hergeholte Situation eines
Schülers vor, der ein Eingabefeld für sein Formular deklarieren möchte,
um Benutzereingaben verarbeiten zu können. Um dies zu erreichen, fügt er
seinem Standardformular mittels der Zeile 'Eingabe : TEdit;'
ein entsprechendes Attribut zu – genau so, wie er es in den
ausgedruckten Musterlösungen seines Lehrers schon mehrfach gesehen hat.
Wenn er das Programm jedoch startet, wird er mit der folgenden
Fehlermeldung konfrontiert:
Delphi hält es offensichtlich für abwegig, dass der Schüler an dieser
Stelle nicht seine obige Deklaration entfernen, sondern stattdessen
lieber eine entsprechende Komponente in sein Formular aufnehmen möchte.
Zugegeben, hätte er eine Eingabefeldkomponente hinzufügen wollen, hätte
er ja einfach seine Maus in die Hand nehmen, den Quelltexteditor per
Klick minimieren, in der Menüleiste unter den (in der Version 7)
33 Reitern denjenigen mit dem Eingabefeldsymbol auffinden und
anklicken, das Startformularfenster per Klick öffnen, auf diesem per
Klick ein Eingabefeld platzieren, im Objektinspektor durch Scrollen nach
der Eigenschaft 'Name' suchen, in das nebenstehende Eingabefeld klicken,
die Tastatur in die Hand nehmen, den Standardnamen 'Edit1' durch einen
sinnvollen Namen (hier: Eingabe) ersetzen, die Maus in die Hand nehmen,
den Quelltexteditor anklicken und die Tastatur zur weiteren Bearbeitung
in die Hand nehmen müssen. Dann hätte er sich die ganze Tipparbeit (die
Textzeile 'Eingabe : TEdit;' wurde inzwischen automatisch
von Delphi eingefügt) und die obige Fehlermeldung erspart.
Die Folgen des obigen Szenarios sind offensichtlich: Erstens sind die Schüler verunsichert, wenn ein und dieselbe Pascal-Datei gleichzeitig funktionieren kann oder auch nicht. Zweitens suchen die Schüler ihre Fehler künftig nicht mehr im eigenen Programmcode, sondern vermuten (erneut) ein rätselhaftes Verhalten der Entwicklungsumgebung. Drittens führt der ständige Wechsel zwischen Maus und Tastatur dazu, dass die Schüler obigen Prozess dahingehend abkürzen, dass sie sich mit den von Delphi vorgeschlagenen Standardnamen für Komponenten (wie z.B. Edit1) zufrieden geben. Nicht selten habe ich erlebt, dass Schüler, die innerhalb eines Programms mehrere Eingabefelder mit den Standardnamen Edit1, Edit2 usw. angelegt haben, die Bedeutung der einzelnen Eingabefelder verwechselt und somit unnötig lange nach den sich daraus ergebenden Laufzeitfehlern gesucht haben.
Es scheint nicht zu den Zielen der Entwickler von Delphi zu zählen, dieses Programm ausschließlich mit der Tastatur bedienen zu können. Als sich ein Schüler einmal aufgrund einer fehlenden Mauskugel auf dieses Experiment einlassen musste, gab er bald auf: es lässt sich nur sehr unkomfortabel in dem Fensterquintett bestehend aus dem Hauptfenster mit seinen zahllosen Menüpunkten und seiner Komponentenpalette, dem Quelltexteditor, dem Objektinspektor, der Objekt-Hierarchie und dem Startformularfenster ohne Hilfe der Maus navigieren.
Über einen weiteren Punkt lässt sich gewiss streiten: Die Unterteilung
des Programmcodes einer Unit in den so genannten Interface- und
Implementation-Bereich mag gewiss vorteilhaft in dem Sinne sein, dass ein
fremder Benutzer der Klasse bereits mittels eines kurzen Blickes auf den
Interface-Bereich erkennt, wie er diese Klasse verwenden kann.
Andererseits hat diese Redundanz bei meinen Schülern immer wieder zu
Fehlermeldungen geführt, weil sie z.B. versehentlich eine Methode
nicht im Interface angegeben oder sie den Methodennamen nachträglich im
Implementation-Bereich verändert haben. Ganz häufig wurde im
Implementation-Bereich vergessen, jedem Methodennamen den Klassennamen
(gefolgt von einem Punkt) voranzustellen. Es wäre wünschenswert, wenn
Delphi lediglich eine Klassendeklaration pro Unit erlauben würde, damit
die Schüler zumindest von dieser Eigenheit befreit würden. Wenn man
darüber hinaus bedenkt, dass die Schülerprogramme in der Regel doch recht
überschaubar bleiben, könnte man die Notwendigkeit des Interface-Bereichs
überhaupt in Frage stellen. Wie oft wurde ich nicht schon gefragt, an
welcher Stelle im Quelltext Variablen und Konstanten deklariert werden
können oder an welcher Stelle andere Klassen mittels 'uses'
eingebunden werden können.
Vergleiche ich abschließend die Fehlermeldungen von Delphi mit denen,
die ich vor etwa zehn Jahren mit Turbo-Pascal in meinem eigenen
Informatikkurs als Schüler beobachtet habe, so komme ich zu dem Ergebnis,
dass die Fehler, die wir Schüler damals gemacht haben (z.B. ein
Semikolon vor einem 'else' oder die Verwendung einer nicht
deklarierten Variable) heute bei Delphi um eine große Anzahl von neuen
Fehlern ergänzt werden, die wir damals gar nicht machen konnten, weil es
sie ganz einfach nicht gab.